Re: [PATCH] Add option for dumping to stderr (issue6190057)

[Sharad Singhai]

Resend to gcc-patches

I have addressed the comments by fixing all the minor issues,
bootstrapped and tested on x86_64. I did the recommended reshuffling
by moving non-tree code from tree-dump.c into a new file dumpfile.c.

I committed two successive revisions
r191883 Main patch with the dump infrastructure changes. However, I
accidentally left out a new file, dumpfile.c.
r191884 Added dumpfile.c, and did the renaming of dump_* functions
from gimple_pretty_print.[ch].

As things stand right now, r191883 is broken because of the missing
file 'dumpfile.c', which the very next commit fixes. Anyone who got
broken revision r191883, please svn update. I am really very sorry
about that.

I have a couple more minor patches which deal with renaming; I plan to
address those later.

Thanks,
Sharad

 On Thu, Sep 27, 2012 at 9:10 AM, Xinliang David Li davi...@google.com
 wrote:

 On Thu, Sep 27, 2012 at 4:35 AM, Sharad Singhai sing...@google.com
 wrote:
  Thanks for the review. A couple of comments inline:
 
  Some minor issues:
 
  * c/c-decl.c (c_write_global_declarations): Use different
  method to
  determine if the dump has ben initialized.
  * cp/decl2.c (cp_write_global_declarations): Ditto.
  * testsuite/gcc.target/i386/vect-double-1.c: Fix test.
 
  these subdirs all have their separate ChangeLog entry from where the
  directory name is omitted.
 
  Index: tree-dump.c
  ===
  --- tree-dump.c (revision 191490)
  +++ tree-dump.c (working copy)
  @@ -24,9 +24,11 @@ along with GCC; see the file COPYING3.  If not see
   #include coretypes.h
   #include tm.h
   #include tree.h
  +#include gimple-pretty-print.h
   #include splay-tree.h
   #include filenames.h
   #include diagnostic-core.h
  +#include rtl.h
 
  what do you need gimple-pretty-print.h and rtl.h for?
 
  +
  +extern void dump_bb (FILE *, basic_block, int, int);
  +
 
  that should be declared in some header
 
  +/* Dump gimple statement GS with SPC indentation spaces and
  +   EXTRA_DUMP_FLAGS on the dump streams if DUMP_KIND is enabled.  */
  +
  +void
  +dump_gimple_stmt (int dump_kind, int extra_dump_flags, gimple gs, int
  spc)
  +{
 
  the gimple stuff really belongs in to gimple-pretty-print.c
 
  This dump_gimple_stmt () is just a dispatcher, which uses internal
  data structure such as dump streams/flags. If I move it into
  gimple-pretty-print.c, then I would have to export those
  streams/flags. I was hoping to avoid it by keeping all dump_* ()
  methods together in dumpfile.c (earlier in tree-dump.c). Thus, later
  one could just make dump_file/dump_flags static when all the passes
  have converted to this scheme.
 

 You can make the flags/streams global but only expose them via inline
 accessors in the header file.

 David

 
  (parts of tree-dump.c should be moved to a new file dumpfile.c)
 
  +/* Dump tree T using EXTRA_DUMP_FLAGS on dump streams if DUMP_KIND is
  +   enabled.  */
  +
  +void
  +dump_generic_expr (int dump_kind, int extra_dump_flags, tree t)
  +{
 
  belongs to tree-pretty-print.c (to where the routines are it calls)
 
  This is again a dispatcher for dump_generic_expr () which writes to
  the appropriate stream depending upon dump_kind.
 
 
  +int
  +dump_start (int phase, int *flag_ptr)
  +{
 
  perfect candidate for dumpfile.c
 
  You can do this re-shuffling as followup, but please try to not include
  rtl.h
  or gimple-pretty-print.h from tree-dump.c.  Thus re-shuffling required
  by that
  do now.  tree-dump.c should only know about dumping 'tree'.
 
  Okay, I have moved relevant methods into dumpfile.c.
 
 
  Index: tree-dump.h
  ===
  --- tree-dump.h (revision 191490)
  +++ tree-dump.h (working copy)
  @@ -22,6 +22,7 @@ along with GCC; see the file COPYING3.  If not see
   #ifndef GCC_TREE_DUMP_H
   #define GCC_TREE_DUMP_H
 
  +#include input.h
 
  probably no longer required.
 
  Index: dumpfile.h
  ===
  --- dumpfile.h  (revision 191490)
  +++ dumpfile.h  (working copy)
  @@ -22,6 +22,9 @@ along with GCC; see the file COPYING3.  If not see
   #ifndef GCC_DUMPFILE_H
   #define GCC_DUMPFILE_H 1
 
  +#include coretypes.h
  +#include input.h
 
  likewise for input.h.
 
  Index: testsuite/gcc.target/i386/vect-double-1.c
  ===
  --- testsuite/gcc.target/i386/vect-double-1.c   (revision 191490)
  +++ testsuite/gcc.target/i386/vect-double-1.c   (working copy)
  @@ -32,5 +32,5 @@ sse2_test (void)
   }
   }
 
  -/* { dg-final { scan-tree-dump-times vectorized 1 loops 1 vect } }
  */
  +/* { dg-final { scan-tree-dump-times Vectorized loops: 1 1 vect }
  } */
   /* { dg-final { cleanup-tree-dump vect } } */
 
  I am sure you need a gazillion more testsuite adjustments?  Thus, did
  you
  really test the patch by a bootstrap and a 

Re: [Patch contrib] check_GNU_style: remove tmp file

[Christophe Lyon]

Ping?

May I commit this small patch?
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00580.html

Thanks,

Christophe.

On 10 September 2012 14:23, Christophe Lyon christophe.l...@linaro.org wrote:
 On 9 September 2012 12:46, Gerald Pfeifer ger...@pfeifer.com wrote:
 On Mon, 3 Sep 2012, Christophe Lyon wrote:
 check_GNU_style.sh currently leaves a temporary file in the current
 directory. This patch removes it upon exit.

 Christophe.

 2012-09-03   Christophe Lyon  christophe.l...@linaro.org

   * check_GNU_style.sh: Remove temporay file upon exit.

 Shouldn't this also be removed upon abort?

 See contrib/warn_summary, for an example,

 Gerald

 Good point. Here is a new version, catching the same signals as warn_summary.

 Christophe.

Re: RFC: LRA for x86/x86-64 [0/9]

[Jakub Jelinek]

On Mon, Oct 01, 2012 at 08:47:13AM +0200, Steven Bosscher wrote:
 The test case compiles just fine at -O2, only VRP has trouble with it.
 Let's try to stick with facts, not speculation.

I was talking about the other PR, PR26854, which from what I remember when
trying it myself and even the latest -O3 time reports from the reduced
testcase show that IRA/reload aren't there very significant (for -O3 IRA
takes ~ 6% and reload ~ 1%).

 I've put a lot of hard work into it to fix almost all scalability problems
 on this PR for gcc 4.8. LRA undoes all of that work. I understand it is
 painful for some people to hear, but I remain of opinion that LRA cannot be
 considered ready if it scales so much worse than everything else in the
 compiler.

Judging the whole implementation from just these corner cases and not how it
performs on other testcases (SPEC, rebuild a distro, ...) is IMHO not the
right thing, if Vlad thinks the corner cases are fixable during stage3; IMHO
we should allow LRA in, worst case it can be disabled by default even for
i?86/x86_64.

Jakub

Re: [rtl] combine a vec_concat of 2 vec_selects from the same vector

[Eric Botcazou]

 2012-09-09  Marc Glisse  marc.gli...@inria.fr
 
 gcc/
   * simplify-rtx.c (simplify_binary_operation_1) VEC_SELECT:
   Detect the identity.
   VEC_CONCAT: Handle VEC_SELECTs from the same vector.
 
 gcc/testsuite/
   * gcc.target/i386/vect-rebuild.c: New testcase.

OK if you adjust the above date and add the missing space at the end of:

/* Try to merge 2 VEC_SELECTs from the same vector into a single one. */ 

-- 
Eric Botcazou

[Ada] Validity checks on subprogram parameters and results

[Arnaud Charlet]

This patch introduces two new validity checks to the GNAT compiler:

1) -gnatVl   Check non-overlapping parameters
When this check is enabled, each subprogram call is preceded by a sequence of
checks that ensure no overlap between actual parameters.

2) -gnatVv   Check proper initialization of scalars on parameters and results
When this check is enabled, each IN, IN OUT and OUT formal parameter along with
a possible function result is checked on entry and exit of a subprogram for
properly initialized scalars.

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

2012-10-01  Hristian Kirtchev  kirtc...@adacore.com

* checks.ads, checks.adb (Apply_Parameter_Aliasing_Checks): New routine.
(Apply_Parameter_Validity_Checks): New routines.
* exp_ch6.adb (Expand_Call): Add aliasing checks to detect
overlapping objects.
* freeze.adb: Add with and use clauses for Checks and Validsw.
(Freeze_Entity): Add checks to detect proper initialization
of scalars.
* sem_ch4.adb: Add with and use clauses for Checks and Validsw.
(Analyze_Call): Add aliasing checks to detect overlapping objects.
* sem_ch13.adb: Add with and use clauses for Validsw.
(Analyze_Aspect_Specifications): Add checks to detect proper
initialization of scalars.
* sem_prag.adb (Chain_PPC): Correct the extraction of the
subprogram name.
* sem_util.adb (Is_Object_Reference): Attribute 'Result now
produces an object.
* usage.adb (Usage): Add usage lines for validity switches 'l',
'L', 'v' and 'V'.
* validsw.adb (Reset_Validity_Check_Options): Include
processing for flags Validity_Check_Non_Overlapping_Params and
Validity_Check_Valid_Scalars_On_Params. Code reformatting.
(Save_Validity_Check_Options): Include processing
for flags Validity_Check_Non_Overlapping_Params
and Validity_Check_Valid_Scalars_On_Params.
(Set_Validity_Check_Options): Add processing for validity switches
'a', 'l', 'L', 'n', 'v' and 'V'. Code reformatting.
* validsw.ads: Add new flags Validity_Check_Non_Overlapping_Params
and Validity_Check_Valid_Scalars_On_Params along with comments
on usage.

Index: usage.adb
===
--- usage.adb   (revision 191888)
+++ usage.adb   (working copy)
@@ -399,6 +399,8 @@
Write_Line (Fturn off checking for floating-point);
Write_Line (iturn on checking for in params);
Write_Line (Iturn off checking for in params);
+   Write_Line (lturn on checking for non-overlapping params);
+   Write_Line (Lturn off checking for non-overlapping params);
Write_Line (mturn on checking for in out params);
Write_Line (Mturn off checking for in out params);
Write_Line (oturn on checking for operators/attributes);
@@ -411,6 +413,8 @@
Write_Line (Sturn off checking for subscripts);
Write_Line (tturn on checking for tests);
Write_Line (Tturn off checking for tests);
+   Write_Line (vturn on checking for 'Valid_Scalars on params);
+   Write_Line (Vturn off checking for 'Valid_Scalars on params);
Write_Line (nturn off all validity checks (including RM));
 
--  Lines for -gnatw switch
Index: checks.adb
===
--- checks.adb  (revision 191888)
+++ checks.adb  (working copy)
@@ -1774,6 +1774,353 @@
 (Ck_Node, Target_Typ, Source_Typ, Do_Static = False);
end Apply_Length_Check;
 
+   -
+   -- Apply_Parameter_Aliasing_Checks --
+   -
+
+   procedure Apply_Parameter_Aliasing_Checks (Call : Node_Id) is
+  Loc: constant Source_Ptr := Sloc (Call);
+  Actual : Node_Id;
+  Actual_Typ : Entity_Id;
+  Check  : Node_Id;
+  Cond   : Node_Id := Empty;
+  Param  : Node_Id;
+  Param_Typ  : Entity_Id;
+
+   begin
+  --  Do not generate the checks in Ada 83, 95 or 05 mode because they
+  --  require an Ada 2012 construct.
+
+  if Ada_Version_Explicit  Ada_2012 then
+ return;
+  end if;
+
+  --  Inspect all pairs of parameters
+
+  Actual := First_Actual (Call);
+  while Present (Actual) loop
+ Actual_Typ := Base_Type (Etype (Actual));
+
+ if Nkind (Actual) = N_Identifier
+   and then Is_Object_Reference (Actual)
+ then
+Param := Next_Actual (Actual);
+while Present (Param) loop
+   Param_Typ := Base_Type (Etype (Param));
+
+   if Nkind (Param) = N_Identifier
+ and then Is_Object_Reference (Param)
+ and then Actual_Typ = Param_Typ
+   then
+  --  

Re: RFC: LRA for x86/x86-64 [0/9]

[Steven Bosscher]

[ Sorry for re-send, it seems that mobile gmail sends text/html and
the sourceware mailer daemon rejects that. ]

On Monday, October 1, 2012, Jakub Jelinek ja...@redhat.com wrote:
 On Sun, Sep 30, 2012 at 06:50:50PM -0400, Vladimir Makarov wrote:

 I think this testcase shouldn't be a show stopper for LRA inclusion into
 4.8, but something to look at for stage3.

 I think a lot of GCC passes have scalability issues on that testcase,
 that is why it must be compiled with -O1 and not higher optimization
 options,

The test case compiles just fine at -O2, only VRP has trouble with it. Let's
try to stick with facts, not speculation.

And the test case is not generated, it is the Eigen template library applied
to mpfr.

I've put a lot of hard work into it to fix almost all scalability problems
on this PR for gcc 4.8. LRA undoes all of that work. I understand it is
painful for some people to hear, but I remain of opinion that LRA cannot be
considered ready if it scales so much worse than everything else in the
compiler.

Ciao!
Steven

[Ada] Detect more cases of possible infinite loops

[Arnaud Charlet]

In cases where GNAT did not detect the possibility of an infinite loop, it now
issues a warning. For example, on the following code:

$ gcc -c bad.adb
bad.adb:9:13: warning: variable Cur is not modified in loop body
bad.adb:9:13: warning: possible infinite loop

 1. package body Bad is
 2.procedure P (Y : Integer) is
 3.begin
 4.   null;
 5.end P;
 6.procedure Q (X : Integer) is
 7.   Cur : Integer := X;
 8.begin
 9.   while Cur /= 0 loop
10.  P (Cur);
11.   end loop;
12.end Q;
13. end Bad;

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

2012-10-01  Yannick Moy  m...@adacore.com

* sem_warn.adb (Check_Infinite_Loop_Warning/Test_Ref): Improve
the detection of modifications to the loop variable by noting
that, if the type of variable is elementary and the condition
does not contain a function call, then the condition cannot be
modified by side-effects from a procedure call.

Index: sem_warn.adb
===
--- sem_warn.adb(revision 191890)
+++ sem_warn.adb(working copy)
@@ -472,32 +472,41 @@
return Abandon;
 end if;
 
---  If we appear in the context of a procedure call, then also
---  abandon, since there may be issues of non-visible side
---  effects going on in the call.
+--  If the condition contains a function call, we consider it may
+--  be modified by side-effects from a procedure call. Otherwise,
+--  we consider the condition may not be modified, although that
+--  might happen if Variable is itself a by-reference parameter,
+--  and the procedure called modifies the global object referred to
+--  by Variable, but we actually prefer to issue a warning in this
+--  odd case. Note that the case where the procedure called has
+--  visibility over Variable is treated in another case below.
 
-declare
-   P : Node_Id;
+if Function_Call_Found then
+   declare
+  P : Node_Id;
 
-begin
-   P := N;
-   loop
-  P := Parent (P);
-  exit when P = Loop_Statement;
+   begin
+  P := N;
+  loop
+ P := Parent (P);
+ exit when P = Loop_Statement;
 
-  --  Abandon if at procedure call, or something strange is
-  --  going on (perhaps a node with no parent that should
-  --  have one but does not?) As always, for a warning we
-  --  prefer to just abandon the warning than get into the
-  --  business of complaining about the tree structure here!
+ --  Abandon if at procedure call, or something strange is
+ --  going on (perhaps a node with no parent that should
+ --  have one but does not?) As always, for a warning we
+ --  prefer to just abandon the warning than get into the
+ --  business of complaining about the tree structure here!
 
-  if No (P) or else Nkind (P) = N_Procedure_Call_Statement then
- return Abandon;
-  end if;
-   end loop;
-end;
+ if No (P)
+   or else Nkind (P) = N_Procedure_Call_Statement
+ then
+return Abandon;
+ end if;
+  end loop;
+   end;
+end if;
 
---  Reference to variable renaming variable in question
+ --  Reference to variable renaming variable in question
 
  elsif Is_Entity_Name (N)
and then Present (Entity (N))
@@ -509,7 +518,7 @@
  then
 return Abandon;
 
---  Call to subprogram
+ --  Call to subprogram
 
  elsif Nkind (N) in N_Subprogram_Call then
 

[Ada] Ada 2012 legality checks on uses of names of protected procedures

[Arnaud Charlet]

Ada 2012 AI05-0225 clarifies that most uses of the  names of protected
procedures and entries require that the target object (explicit or implicit)
be a variable. This applies to calls, generic actuals, and prefixes of 'Access.
It applies in particular to such uses within the body a protected function.

Example is ACATS Test b950001.

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

2012-10-01  Ed Schonberg  schonb...@adacore.com

* sem_util.ads sem_util.adb (Check_Internal_Protected_Use):
reject use of protected procedure or entry within the body of
a protected function of the same protected type, when usage is
a call, an actual in an instantiation, a or prefix of 'Access.
* sem_ch8.adb (Analyze_Subprogram_Renaming): Verify that target
object in renaming of protected procedure is a variable, and
apply Check_Internal_Protected_Use.
* sem_res.adb (Analyze_Call, Analyze_Entry_Call): apply
Check_Internal_Protected_Use rather than on-line code.
* sem_attr.adb (Analyze_Access_Attribute): Verify that target
object in accsss to protected procedure is a variable, and apply
Check_Internal_Protected_Use.

Index: sem_util.adb
===
--- sem_util.adb(revision 191890)
+++ sem_util.adb(working copy)
@@ -1191,6 +1191,50 @@
   end if;
end Check_Implicit_Dereference;
 
+   --
+   -- Check_Internal_Protected_Use --
+   --
+
+   procedure Check_Internal_Protected_Use (N : Node_Id; Nam : Entity_Id) is
+  S: Entity_Id;
+  Prot : Entity_Id;
+
+   begin
+  S := Current_Scope;
+  while Present (S) loop
+ if S = Standard_Standard then
+return;
+
+ elsif Ekind (S) = E_Function
+   and then Ekind (Scope (S)) = E_Protected_Type
+ then
+Prot := Scope (S);
+exit;
+ end if;
+
+ S := Scope (S);
+  end loop;
+
+  if Scope (Nam) = Prot and then Ekind (Nam) /= E_Function then
+ if Nkind (N) = N_Subprogram_Renaming_Declaration then
+Error_Msg_N
+  (within protected function cannot use protected 
+procedure in renaming or as generic actual, N);
+
+ elsif Nkind (N) = N_Attribute_Reference then
+Error_Msg_N
+  (within protected function cannot take access of 
+ protected procedure, N);
+
+ else
+Error_Msg_N
+  (within protected function, protected object is constant, N);
+Error_Msg_N
+  (\cannot call operation that may modify it, N);
+ end if;
+  end if;
+   end Check_Internal_Protected_Use;
+
---
-- Check_Later_Vs_Basic_Declarations --
---
Index: sem_util.ads
===
--- sem_util.ads(revision 191888)
+++ sem_util.ads(working copy)
@@ -170,6 +170,12 @@
--  checks whether T is a reference type, and if so it adds an interprettion
--  to Expr whose type is the designated type of the reference_discriminant.
 
+   procedure Check_Internal_Protected_Use (N : Node_Id; Nam : Entity_Id);
+   --  Within a protected function, the current object is a constant, and
+   --  internal calls to a procedure or entry are illegal. Similarly, other
+   --  uses of a protected procedure in a renaming or a generic instantiation
+   --  in the context of a protected function are illegal (AI05-0225).
+
procedure Check_Later_Vs_Basic_Declarations
  (Decls  : List_Id;
   During_Parsing : Boolean);
Index: sem_res.adb
===
--- sem_res.adb (revision 191888)
+++ sem_res.adb (working copy)
@@ -5314,15 +5314,7 @@
   --  Check that this is not a call to a protected procedure or entry from
   --  within a protected function.
 
-  if Ekind (Current_Scope) = E_Function
-and then Ekind (Scope (Current_Scope)) = E_Protected_Type
-and then Ekind (Nam) /= E_Function
-and then Scope (Nam) = Scope (Current_Scope)
-  then
- Error_Msg_N (within protected function, protected  
-   object is constant, N);
- Error_Msg_N (\cannot call operation that may modify it, N);
-  end if;
+  Check_Internal_Protected_Use (N, Nam);
 
   --  Freeze the subprogram name if not in a spec-expression. Note that we
   --  freeze procedure calls as well as function calls. Procedure calls are
@@ -6732,6 +6724,7 @@
   end if;
 
   Resolve_Actuals (N, Nam);
+  Check_Internal_Protected_Use (N, Nam);
 
   --  Create a call reference to the entry
 
Index: sem_attr.adb
===
--- sem_attr.adb

[Ada] Tagged /= operator in GNAT tree doesn't get fully resolved with -gnatc

[Arnaud Charlet]

When an inequality operator is used for a tagged type, the tree node for
the inequality prior to expansion (such as with -gnatc) reflects /=
operator in Standard rather than being resolved to be a logical negation
of the tagged type's equality function. This is a problem for ASIS in
Corresponding_Equality_Operator. We now ensure that the rewriting of
a tagged inequality happens during analysis rather than being deferred
to expansion.

No simple test available.

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

2012-10-01  Gary Dismukes  dismu...@adacore.com

* sem_ch4.adb (Find_Equality_Types.Try_One_Interp): Exclude the
predefined interpretation from consideration if it's for a /=
operator of a tagged type. This will allow Analyze_Equality_Op to
rewrite the /= as a logical negation of a call to the appropriate
dispatching equality function. This needs to be done during
analysis rather than expansion for the benefit of ASIS, which
otherwise gets the unresolved N_Op_Ne operator from Standard.

Index: sem_ch4.adb
===
--- sem_ch4.adb (revision 191890)
+++ sem_ch4.adb (working copy)
@@ -5612,8 +5612,24 @@
 return;
  end if;
 
+ --  If the right operand has a type compatible with T1, check for an
+ --  acceptable interpretation, unless T1 is limited (no predefined
+ --  equality available), or this is use of a /= for a tagged type.
+ --  In the latter case, possible interpretations of equality need to
+ --  be considered, we don't want the default inequality declared in
+ --  Standard to be chosen, and the /= will be rewritten as a
+ --  negation of = (see the end of Analyze_Equality_Op). This ensures
+ --  that that rewriting happens during analysis rather than being
+ --  delayed until expansion (this is needed for ASIS, which only sees
+ --  the unexpanded tree). Note that if the node is N_Op_Ne, but Op_Id
+ --  is Name_Op_Eq then we still proceed with the interpretation,
+ --  because that indicates the potential rewriting case where the
+ --  interpretation to consider is actually = and the node may be
+ --  about to be rewritten by Analyze_Equality_Op.
+
  if T1 /= Standard_Void_Type
and then Has_Compatible_Type (R, T1)
+
and then
  ((not Is_Limited_Type (T1)
 and then not Is_Limited_Composite (T1))
@@ -5622,6 +5638,11 @@
  (Is_Array_Type (T1)
and then not Is_Limited_Type (Component_Type (T1))
and then Available_Full_View_Of_Component (T1)))
+
+   and then
+ (Nkind (N) /= N_Op_Ne
+   or else not Is_Tagged_Type (T1)
+   or else Chars (Op_Id) = Name_Op_Eq)
  then
 if Found
   and then Base_Type (T1) /= Base_Type (T_F)

[Ada] Next step in implementing extended overflow checking

[Arnaud Charlet]

This patch defines the four modes of overflow handling (SUPPRESSED,
CHECKED, MINIMIZED, ELIMINATED), and adds the Overflow_Checks pragma
and extedned -gnato switch to et them. But for now Checked, Minimized,
and Eliminated are all treated as Checked, so the behavior is unchanged.

The following program:

 1. procedure over2 is
 2.function Ident (X : Integer) return Integer is
 3.begin
 4.   return X;
 5.end;
 6.x : integer := Ident (Integer'Last);
 7.procedure g;
 8.pragma Postcondition (x + 2 = 0);
 9.procedure g is begin null; end;
10. begin
11.g;
12. end;

compiled with -gnata -gnato10 generates

  raised SYSTEM.ASSERTIONS.ASSERT_FAILURE :
   failed postcondition from over2.adb:8

since -gnato10 turns off overflow checking in assertions
resulting in the postcondition giving a result of false.

compiled with -gnata -gnato01 generates

  raised CONSTRAINT_ERROR : over2.adb:8 overflow check failed

since -gnato01 turns on overflow checking in assertions
resulting in the overflow being detected.

The following test program:

 1. pragma Overflow_Checks
 2.   (Suppressed, Assertions = Checked);
 3. procedure over21 is
 4.function Ident (X : Integer) return Integer is
 5.begin return X; end;
 6.x : integer := Ident (Integer'Last);
 7.procedure g;
 8.pragma Postcondition (x + 2 = 0);
 9.procedure g is begin null; end;
10. begin
11.g;
12. end;

compiled with -gnata result in

  raised CONSTRAINT_ERROR : over21.adb:8 overflow check failed

The following test program:

 1. pragma Overflow_Checks
 2.   (Checked, Assertions = Suppressed);
 3. procedure over22 is
 4.function Ident (X : Integer) return Integer is
 5.begin return X; end;
 6.x : integer := Ident (Integer'Last);
 7.procedure g;
 8.pragma Postcondition (x + 2 = 0);
 9.procedure g is begin null; end;
10. begin
11.g;
12. end;

compiled with -gnata generates

  raised SYSTEM.ASSERTIONS.ASSERT_FAILURE :
   failed postcondition from over22.adb:8

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

2012-10-01  Robert Dewar  de...@adacore.com

* checks.adb: Remove reference to Enable_Overflow_Checks Use
Suppress_Options rather than Scope_Suppress.
* gnat1drv.adb (Adjust_Global_Switches): Handle new overflow
settings (Adjust_Global_Switches): Initialize Scope_Suppress
from Suppress_Options.
* opt.adb: Remove Enable_Overflow_Checks (use Suppress_Options
instead).
* opt.ads: Remove Overflow_Checks_Unsuppressed (not used)
Remove Enable_Overflow_Checks (use Suppress_Options instead)
Suppress_Options is now current setting (replaces Scope_Suppress).
* osint.adb (Initialize): Deal with initializing overflow
checking.
* par-prag.adb: Add dummy entry for pragma Overflow_Checks.
* sem.adb (Semantics): Save and restore In_Assertion_Expr Use
Suppress_Options instead of Scope_Suppress.
* sem.ads (In_Assertion_Expr): New flag (Scope_Suppress):
Removed, use Suppress_Options instead.
* sem_eval.adb (Compile_Time_Compare): Return Unknown in
preanalysis mode.
* sem_prag.adb (Process_Suppress_Unsuppress): Setting of
Overflow_Checks_Unsuppressed removed (not used anywhere!)
(Analyze_Pragma, case Check): Set In_Assertion_Expression
(Analyze_Pragma, case Overflow_Checks): Implement new pragma
* snames.ads-tmpl: Add names needed for handling pragma
Overflow_Checks
* switch-c.adb (Scan_Front_End_Switches) Handle -gnato? and
-gnato?? where ? is 0-3
* types.ads: Updates and fixes to comment on Suppress_Record.

Index: switch-c.adb
===
--- switch-c.adb(revision 191888)
+++ switch-c.adb(working copy)
@@ -128,9 +128,8 @@
 
   --  Handle switches that do not start with -gnat
 
-  if Ptr + 3  Max
-or else Switch_Chars (Ptr .. Ptr + 3) /= gnat
-  then
+  if Ptr + 3  Max or else Switch_Chars (Ptr .. Ptr + 3) /= gnat then
+
  --  There are two front-end switches that do not start with -gnat:
  --  -I, --RTS
 
@@ -755,11 +754,78 @@
 
 when 'o' =
Ptr := Ptr + 1;
-   Suppress_Options.Suppress (Overflow_Check) := False;
-   Suppress_Options.Overflow_Checks_General := Check_All;
-   Suppress_Options.Overflow_Checks_Assertions := Check_All;
-   Opt.Enable_Overflow_Checks := True;
 
+   --  Case of no digits after the -gnato
+
+   if Ptr  Max or else Switch_Chars (Ptr) not in '0' .. '3' then
+  Suppress_Options.Overflow_Checks_General:= Checked;
+  Suppress_Options.Overflow_Checks_Assertions := 

Re: [rtl] combine a vec_concat of 2 vec_selects from the same vector

[Eric Botcazou]

  /* Try to merge 2 VEC_SELECTs from the same vector into a single one. */
 
 I was trying to avoid splitting in 2 lines, but ok I'll split.

Indeed.  Then you can remove the '2' above, it doesn't add much.

-- 
Eric Botcazou

[Ada] Checks on aliasing and initialization of scalars for parameters

[Arnaud Charlet]

This patch reimplements the checks related to aliasing and initialization of
scalars for subprogram parameters and ties them to compilation flags -gnateA
and -gnateV respectively.

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

2012-10-01  Hristian Kirtchev  kirtc...@adacore.com

* checks.adb (Apply_Parameter_Aliasing_Checks): Removed.
(Apply_Parameter_Aliasing_And_Validity_Checks): New routine.
(Apply_Parameter_Validity_Checks): Removed.
* checks.ads (Apply_Parameter_Aliasing_Checks): Removed.
(Apply_Parameter_Aliasing_And_Validity_Checks): New routine.
(Apply_Parameter_Validity_Checks): Removed.
* exp_ch6.adb (Expand_Call): Remove the generation of parameter
aliasing checks.
* freeze.adb: Remove with and use clauses for Validsw.
(Freeze_Entity): Update the guard and generation of aliasing
and scalar initialization checks for subprogram parameters.
* opt.ads: Add new flags Check_Aliasing_Of_Parameters and
Check_Validity_Of_Parameters along with comments on usage.
* sem_attr.adb (Analyze_Attribute): Pragma Overlaps_Storage is
no longer an Ada 2012 feature.
* sem_ch4.adb: Remove with and use clauses for Checks and Validsw.
(Analyze_Call): Remove the generation of aliasing checks for
subprogram parameters.
* sem_ch13.adb: Remove with and use clauses for Validsw.
(Analyze_Aspect_Specifications): Remove the generation of scalar
initialization checks.
* switch-c.adb (Scan_Front_End_Switches): Add processing for
-gnateA and -gnateV.
* usage.adb (Usage): Add information on switches -gnateA and
-gnateV. Remove information on validity switches 'l', 'L',
'v' and 'V'.
* validsw.adb (Reset_Validity_Check_Options): Remove the
reset of flags Validity_Check_Non_Overlapping_Params
and Validity_Check_Valid_Scalars_On_Params.
(Save_Validity_Check_Options): Remove the processing
for flags Validity_Check_Non_Overlapping_Params
and Validity_Check_Valid_Scalars_On_Params.
(Set_Validity_Check_Options): Remove the processing
for flags Validity_Check_Non_Overlapping_Params and
Validity_Check_Valid_Scalars_On_Params.
* validsw.ads: Remove flags Validity_Check_Non_Overlapping_Params
and Validity_Check_Valid_Scalars_On_Params along with their
comments on usage.

Index: switch-c.adb
===
--- switch-c.adb(revision 191895)
+++ switch-c.adb(working copy)
@@ -380,6 +380,12 @@
  Enable_Switch_Storing;
  Ptr := Ptr + 1;
 
+  --  -gnateA (aliasing checks on parameters)
+
+  when 'A' =
+ Ptr := Ptr + 1;
+ Check_Aliasing_Of_Parameters := True;
+
   --  -gnatec (configuration pragmas)
 
   when 'c' =
@@ -566,6 +572,22 @@
   when 'P' =
  Treat_Categorization_Errors_As_Warnings := True;
 
+  --  -gnateS (generate SCO information)
+
+  --  Include Source Coverage Obligation information in ALI
+  --  files for the benefit of source coverage analysis tools
+  --  (xcov).
+
+  when 'S' =
+ Generate_SCO := True;
+ Ptr := Ptr + 1;
+
+  --  -gnateV (validity checks on parameters)
+
+  when 'V' =
+ Ptr := Ptr + 1;
+ Check_Validity_Of_Parameters := True;
+
   --  -gnatez (final delimiter of explicit switches)
 
   --  All switches that come after -gnatez have been added by
@@ -577,16 +599,6 @@
  Disable_Switch_Storing;
  Ptr := Ptr + 1;
 
-  --  -gnateS (generate SCO information)
-
-  --  Include Source Coverage Obligation information in ALI
-  --  files for the benefit of source coverage analysis tools
-  --  (xcov).
-
-  when 'S' =
- Generate_SCO := True;
- Ptr := Ptr + 1;
-
   --  All other -gnate? switches are unassigned
 
   when others =
Index: usage.adb
===
--- usage.adb   (revision 191890)
+++ usage.adb   (working copy)
@@ -167,6 +167,11 @@
Write_Switch_Char (Dnn);
Write_Line (Debug expanded generated code (max line length = nn));
 
+   --  Line for -gnateA switch
+
+   Write_Switch_Char (eA);
+   Write_Line (Aliasing checks on subprogram parameters);
+
--  Line for -gnatec switch
 
Write_Switch_Char (ec=?);
@@ -227,6 +232,11 @@
Write_Switch_Char (eS);
Write_Line (Generate SCO (Source Coverage 

[Ada] Ada 2012 invariant checks on subcomponents

[Arnaud Charlet]

If a record has a subvomponent whose type has a defined invariant, then there
must be a invariant check on that component whenever a value of the record type
is created or modified by a visible primitive operation of the type.

The command:

gnatmake -q -gnat12 -gnata main
main

must yield:

CHECK
CHECK
CHECK
CHECK
OK
CHECK
CHECK
CHECK
CHECK
CHECK
CHECK

---
with Text_IO; use Text_IO;
with Ada.Assertions; use Ada.Assertions;
with P;
procedure Main is
   V : P.R2; -- Check on the T default initialization? NOK
   Table : P.A2 (1..3);
begin
   begin
  P.P3 (Table);
   exception
  when Assertion_Error = Put_Line (OK);
   end;
   P.Prim (V.V.V); -- Check on the T reference? OK
   P.P1 (V.V); -- Check on the part? NOK
   P.P2 (V); -- Check on the part? NOK
   declare
 Thing1 : P.R3 := P.F3 (True);
 Thing2 : P.R3 := P.F3 (False);
   begin
  null;
   end;
end Main;
--
package P is

   type T is private with Type_Invariant = Check (T);

   procedure Prim (V : in out T);

   function Check (V : in T) return Boolean;

   type R1 is record
  V : T;
   end record;

   type R2 is record
  V : R1;
   end record;

   type R3 (D : Boolean) is record
  V1 : T;
  case D is
 when True = V2 : T;
 when False = Zero : Integer := 0;
  end case;
   end record;

   type A2 is array (integer range ) of T;
   procedure P1 (V : in out R1);

   procedure P2 (V : in out R2);
   procedure P3 (T : in out A2);
   function F3 (Yes: Boolean) return R3;

private
   type T is record
  Val : Integer := 17;
   end record;
end P;
---
with Ada.Text_IO; use Ada.Text_IO;
package body P is

   ---
   -- Check --
   ---

   function Check (V : in T) return Boolean is
   begin
  Put_Line (CHECK);
  return V.Val = 17;
   end Check;

   procedure Prim (V : in out T) is
   begin
  null;
   end Prim;

   procedure P1 (V : in out R1) is
   begin
  null;
   end P1;

   procedure P2 (V : in out R2) is
   begin
  null;
   end P2;

   procedure P3 (T : in out A2) is
   begin
  T (T'Last).Val := 18;
  null;
   end P3;

   function F3 (Yes : Boolean) return R3 is
  Result : R3 (Yes);
   begin
  return Result;
   end;
end P;

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

2012-10-01  Ed Schonberg  schonb...@adacore.com

* exp_ch3.adb (Build_Record_Invariant_Proc): new procedure to
generate a checking procedure for record types that may have
components whose types have type invariants declared.

Index: exp_ch3.adb
===
--- exp_ch3.adb (revision 191894)
+++ exp_ch3.adb (working copy)
@@ -118,6 +118,10 @@
--  Build record initialization procedure. N is the type declaration
--  node, and Rec_Ent is the corresponding entity for the record type.
 
+   procedure Build_Record_Invariant_Proc (R_Type : Entity_Id; Nod : Node_Id);
+   --  If the record type has components whose types have invariant, build
+   --  an invariant procedure for the record type itself.
+
procedure Build_Slice_Assignment (Typ : Entity_Id);
--  Build assignment procedure for one-dimensional arrays of controlled
--  types. Other array and slice assignments are expanded in-line, but
@@ -3611,6 +3615,174 @@
   end if;
end Build_Record_Init_Proc;
 
+   
+   -- Build_Record_Invariant_Proc --
+   
+
+   procedure Build_Record_Invariant_Proc (R_Type : Entity_Id; Nod : Node_Id) is
+  Loc : constant Source_Ptr := Sloc (Nod);
+
+  Object_Name : constant Name_Id := New_Internal_Name ('I');
+  --  Name for argument of invariant procedure
+
+  Object_Entity : constant Node_Id :=
+Make_Defining_Identifier (Loc, Object_Name);
+  --  The procedure declaration entity for the argument
+
+  Invariant_Found : Boolean;
+  --  Set if any component needs an invariant check.
+
+  Proc_Id   : Entity_Id;
+  Proc_Body : Node_Id;
+  Stmts : List_Id;
+  Type_Def  : Node_Id;
+
+  function Build_Invariant_Checks (Comp_List : Node_Id) return List_Id;
+  --  Recursive procedure that generates a list of checks for components
+  --  that need it, and recurses through variant parts when present.
+
+  function Build_Component_Invariant_Call (Comp : Entity_Id)
+  return Node_Id;
+  --  Build call to invariant procedure for a record component.
+
+  
+  -- Build_Component_Invariant_Call --
+  
+
+  function Build_Component_Invariant_Call (Comp : Entity_Id)
+  return Node_Id
+  is
+ Sel_Comp : Node_Id;
+
+  begin
+ Invariant_Found := True;
+ Sel_Comp :=
+   Make_Selected_Component (Loc,
+ Prefix  = New_Occurrence_Of (Object_Entity, Loc),
+ Selector_Name = New_Occurrence_Of (Comp, Loc));
+
+  

[Ada] Additional invariant checks on composite types

[Arnaud Charlet]

If a composite type has a declared invariant, and some of its compoents are of
types that have their own invariants, the invariant checks on those compoents
must be added to the invariant checks for the enclosing type.

The command;

   gnatmake -q -gnat12 -gnata test_bars
   test_bars

must yield:

   chart invariant violation detected
   value invariant violation detected

with Ada.Assertions; use Ada.Assertions;
with Bars; use Bars;
with Text_IO; use Text_IO;
procedure Test_Bars is
   B : Bar_chart := Bare_Bar (5);
   D : Data (1 .. 5) := (20, 20, 20, 20, 19);
begin
   begin
  Assemble (D, B);
   exception
  when Assertion_Error = Put_Line (chart invariant violation detected);
   end;

   declare
  D : Data (1 .. 5) := (30, 30, 30, 30, -20);
   begin
  Assemble (D, B);
   exception
  when Assertion_Error = Put_Line (value invariant violation detected);
   end;
end;
---
package Bars is
   type Value is private
 with Invariant = Legal (Value);

   type Bar_Chart () is private
 with Invariant = Complete (Bar_Chart);

   type Data is array (positive range ) of Integer;

   function Legal (It : Value) return Boolean;
   function Complete (It : Bar_Chart) return Boolean;
   function Bare_Bar (N : Positive) return Bar_Chart;
   procedure Assemble (From : Data; Result : out Bar_Chart);
private
   type Value is new Integer;
   type Bar_Chart is array (positive range ) of Value;
end;
--- 
package body  Bars is
   --  type Value is private
   --with Invariant = Legal (Value);

   --  type Bar_Chart is private
   --with Invariant = Complete (Bar_Chart);

   function Legal (It : Value) return Boolean is
   begin
  return It = 0 and It = 100;
   end;

   function Complete (It : Bar_Chart) return Boolean is
  Total : Value := 0;
   begin
  for B of It loop Total := Total + B; end loop;
  return Total = 100;
   end;
  
   function Bare_Bar (N : Positive) return Bar_Chart is
  Result : Bar_Chart (1 .. N) := (100, others = 0);
   begin
  return Result;
   end;
  
   
   procedure Assemble (From : Data; Result : out Bar_Chart) is
   begin
  for J in From'range loop
 Result (J) := Value (From (J));
  end loop;
   end;
end;

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

2012-10-01  Ed Schonberg  schonb...@adacore.com

* exp_ch3.ads (Build_Array_Invariant_Proc): moved to body.
* exp_ch3.adb (Build_Array_Invariant_Proc,
Build_Record_Invariant_Proc): transform into functions.
(Insert_Component_Invariant_Checks): for composite types that have
components with specified invariants, build a checking procedure,
and make into the invariant procedure of the composite type,
or incorporate it into the user- defined invariant procedure if
one has been created.
* sem_ch3.adb (Array_Type_Declaration): Checking for invariants
on the component type is defered to the expander.

Index: exp_ch3.adb
===
--- exp_ch3.adb (revision 191902)
+++ exp_ch3.adb (working copy)
@@ -88,6 +88,22 @@
--  used for attachment of any actions required in its construction.
--  It also supplies the source location used for the procedure.
 
+   function Build_Array_Invariant_Proc
+ (A_Type : Entity_Id;
+  Nod: Node_Id) return Node_Id;
+   --  If the component of type of array type has invariants, build procedure
+   --  that checks invariant on all components of the array. Ada 2012 specifies
+   --  that an invariant on some type T must be applied to in-out parameters
+   --  and return values that include a part of type T. If the array type has
+   --  an otherwise specified invariant, the component check procedure is
+   --  called from within the user-specified invariant. Otherwise this becomes
+   --  the invariant procedure for the array type.
+
+   function Build_Record_Invariant_Proc
+ (R_Type : Entity_Id;
+  Nod: Node_Id) return Node_Id;
+   --  Ditto for record types.
+
function Build_Discriminant_Formals
  (Rec_Id : Entity_Id;
   Use_Dl : Boolean) return List_Id;
@@ -118,10 +134,6 @@
--  Build record initialization procedure. N is the type declaration
--  node, and Rec_Ent is the corresponding entity for the record type.
 
-   procedure Build_Record_Invariant_Proc (R_Type : Entity_Id; Nod : Node_Id);
-   --  If the record type has components whose types have invariant, build
-   --  an invariant procedure for the record type itself.
-
procedure Build_Slice_Assignment (Typ : Entity_Id);
--  Build assignment procedure for one-dimensional arrays of controlled
--  types. Other array and slice assignments are expanded in-line, but
@@ -184,6 +196,14 @@
--  Treat user-defined stream operations as renaming_as_body if the
--  subprogram they rename is not frozen when the type is frozen.
 
+   procedure Insert_Component_Invariant_Checks
+ (N   : Node_Id;
+ 

Profile housekeeping 5/n (make RTL loop optimizers to use loop bounds better)

[Jan Hubicka]

Hi,
this patch commonizes the maximal iteration estimate logic in between SCEV and
loop-iv.  Both are now using loop-nb_iterations_upper_bound.  I decided to
keep same API for SCEV code as for RTL code, so I made
estimated_loop_iterations and max_loop_iterations to not try to recompute
bounds and ICE when invoked without SCEV fired on.

The patch updates RTL optimizers to use the estimated_loop_iterations and
max_loop_iterations. This has few advantages:
  1) loop unroller can now take into account estimates stored into
 loop structure by earlier pass (I think none exist though)
 It is however better then using expected_loop_iterations since
 profile might get out of date with expansion.

  2) loop peeling code now use max iterations bounds. This makes it i.e.
 to peel vectorizer prologues/epilogues/scalar loops so -fpeel-loops
 now improves my low iteration count testcase by about 10%

  3) Same for loop unswithcing.

I am not really friend with the new double_int API. I copied some existing
examples but find it ugly.  Why do we miss operators for comparsions and
division? Why from_*/to_* can't be a cast at least for basic integer types?

Regtested/bootstrapped x86_64-linux, seems sane?

I also wonder if loop vectorizer should not update the estimates after
loop iteration count is reduced by vectorizing.

Honza
* loop-unswitch.c (unswitch_single_loop): Use
estimated_loop_iterations_int to prevent unswitching when loop
is known to not roll.
* tree-ssa-loop-niter.c (estimated_loop_iterations): Do not segfault
when SCEV is not initialized.
(max_loop_iterations): Likewise.
* tree-ssa-loop-unswitch.c (tree_ssa_unswitch_loops): Use
estimated_loop_iterations_int to prevent unswithcing when
loop is known to not roll.
* tree-scalar-evolution.c (scev_initialized_p): New function.
* tree-scalar-evolution.h (scev_initialized_p): Likewise.
* loop-unroll.c (decide_peel_once_rolling): Use
max_loop_iterations_int.
(unroll_loop_constant_iterations): Update
nb_iterations_upper_bound and nb_iterations_estimate.
(decide_unroll_runtime_iterations): Use
estimated_loop_iterations or max_loop_iterations;
(unroll_loop_runtime_iterations): fix profile updating.
(decide_peel_simple): Use estimated_loop_iterations
and max_loop_iterations.
(decide_unroll_stupid): Use estimated_loop_iterations
ad max_loop_iterations.
* loop-doloop.c (doloop_modify): Use max_loop_iterations_int.
(doloop_optimize): Likewise.
* loop-iv.c (iv_number_of_iterations): Use record_niter_bound.
(find_simple_exit): Likewise.
* cfgloop.h (struct niter_desc): Remove niter_max.

Index: loop-unswitch.c
===
*** loop-unswitch.c (revision 191867)
--- loop-unswitch.c (working copy)
*** unswitch_single_loop (struct loop *loop,
*** 257,262 
--- 257,263 
rtx cond, rcond = NULL_RTX, conds, rconds, acond, cinsn;
int repeat;
edge e;
+   HOST_WIDE_INT iterations;
  
/* Do not unswitch too much.  */
if (num  PARAM_VALUE (PARAM_MAX_UNSWITCH_LEVEL))
*** unswitch_single_loop (struct loop *loop,
*** 299,305 
  }
  
/* Nor if the loop usually does not roll.  */
!   if (expected_loop_iterations (loop)  1)
  {
if (dump_file)
fprintf (dump_file, ;; Not unswitching, loop iterations  1\n);
--- 300,307 
  }
  
/* Nor if the loop usually does not roll.  */
!   iterations = estimated_loop_iterations_int (loop);
!   if (iterations = 0  iterations = 1)
  {
if (dump_file)
fprintf (dump_file, ;; Not unswitching, loop iterations  1\n);
Index: tree-ssa-loop-niter.c
===
*** tree-ssa-loop-niter.c   (revision 191867)
--- tree-ssa-loop-niter.c   (working copy)
*** estimate_numbers_of_iterations_loop (str
*** 3012,3020 
  bool
  estimated_loop_iterations (struct loop *loop, double_int *nit)
  {
!   estimate_numbers_of_iterations_loop (loop);
if (!loop-any_estimate)
! return false;
  
*nit = loop-nb_iterations_estimate;
return true;
--- 3012,3034 
  bool
  estimated_loop_iterations (struct loop *loop, double_int *nit)
  {
!   /* When SCEV information is available, try to update loop iterations
!  estimate.  Otherwise just return whatever we recorded earlier.  */
!   if (scev_initialized_p ())
! estimate_numbers_of_iterations_loop (loop);
! 
!   /* Even if the bound is not recorded, possibly we can derrive one from
!  profile.  */
if (!loop-any_estimate)
! {
!   if (loop-header-count)
!   {
!   *nit = gcov_type_to_double_int
!  (expected_loop_iterations_unbounded (loop) + 1);
! return true;
!   }
!   

Re: [patch] Minor TARGET_MEM_REF cleanup

[Richard Guenther]

On Sat, Sep 29, 2012 at 1:17 PM, Eric Botcazou ebotca...@adacore.com wrote:
 Hi,

 for simple loops like:

 extern int a[];
 extern int b[];

 void foo (int l)
 {
   int i;

   for (i = 0; i  l; i++)
 a[i] = b [i];
 }

 you get in the .lim3 dump:

 Unanalyzed memory reference 0: _5 = MEM[symbol: b, index: ivtmp.3_1, step: 4,
 offset: 0B];
 Memory reference 1: MEM[symbol: a, index: ivtmp.3_1, step: 4, offset: 0B]

 so the pass analyzes the store but not the load, which seems an oversight.
 The patch also folds copy_mem_ref_info into its only user and removes it.

 Tested on x86_64-suse-linux, OK for mainline?

Please take the opportunity to clean up simple_mem_ref_in_stmt some more.
Both loads and stores in assigns require gimple_assign_single_p, thus do

 if (!gimple_assign_single_p (stmt))
  return NULL;

before deciding on store/load.  To decide that the stmt is a load then do

  if (TREE_CODE (*lhs) == SSA_NAME
   gimple_vuse (stmt))

it is a store if

   gimple_vdef (stmt)
(TREE_CODE (*rhs) == SSA_NAME
  || is_gimple_min_invariant (*rhs))

else it may still be an aggregate copy but LIM doesn't handle those
(though they may still be interesting for disambiguation ...)

The tree-ssa-address parts are ok as-is.

Thanks,
Richard.



 2012-09-29  Eric Botcazou  ebotca...@adacore.com

 * tree.h (copy_mem_ref_info): Delete.
 * tree-ssa-address.c (copy_mem_ref_info): Likewise.
 (maybe_fold_tmr): Copy flags manually.
 * tree-ssa-loop-im.c (simple_mem_ref_in_stmt): Accept TARGET_MEM_REF
 on the RHS as well.


 --
 Eric Botcazou

Re: [PATCH RFA] Implement register pressure directed hoist pass

[Steven Bosscher]

On Sat, Sep 29, 2012 at 8:37 AM, Bin Cheng bin.ch...@arm.com wrote:
 This is the updated patch according to your comments. Please review.
 I also re-collected code size data and found it is improved by about 0.24%
 for mips, which is better than previous data. I believe this should be
 caused by recent changes in trunk, rather than by using DF caches to
 calculate register pressure.

Hello,

Thanks for the update. The first look wasn't a very thorough review,
so I have more comments now. Sorry for that, I should have taken the
time for this the first time round...


First, as a general note: Please add a fat comment somewhere before
the code of the pass to explain how the register pressure driven
hoisting pass works. The existing implementation used to be an almost
one-to-one copy from Muchnick's book, but lately the code has moved
away from that (e.g. with Maxim's patches from last year) and it gets
a bit hard to follow without some explanation. You should at least
document your own algorithm, but I'd really appreciate if you could
also spend some time writing down how things work in general and/or
how the GCC implementation differs from Muchnick's original algorithm.


 +Use IRA to evaluate register pressure in hoist pass for decisions to hoist

the code hoisting pass (brownie points for an xref to the flag for
code hoisting).


 -   - do rough calc of how many regs are needed in each block, and a rough
 - calc of how many regs are available in each class and use that to
 - throttle back the code in cases where RTX_COST is minimal.

This comment still applies to LCM.


 +/* Record all regs that are set in any one insn.  Communication from
 +   mark_reg_{store,clobber} and global_conflicts.  Asm can refer to
 +   all hard-registers.  */
 +static rtx regs_set[(FIRST_PSEUDO_REGISTER  MAX_RECOG_OPERANDS
 +  ? FIRST_PSEUDO_REGISTER : MAX_RECOG_OPERANDS) * 2];
 +/* Number of regs stored in the previous array.  */
 +static int n_regs_set;

You can use DF_INSN_DEFS for this in calculate_bb_reg_pressure.

But then again...

 +   while (n_regs_set--  0)
 + {
 +   rtx note = find_regno_note (insn, REG_UNUSED,
 +   REGNO (regs_set[n_regs_set]));
 +   if (! note)
 + continue;
 +
 +   mark_reg_death (XEXP (note, 0));
 + }

Why not just mark all registers mentioned in REG_UNUSED notes as death, i.e.:

for (note = REG_NOTES (insn); note; note = XEXP (note, 1))
  if ((REG_NOTE_KIND (note) == REG_UNUSED)
mark_reg_death (XEXP (note, 0));

?


 +static int hoist_expr_reaches_here_p (basic_block, struct expr*, basic_block,

space between struct expr and *.


 +   int *, bitmap_head *);

bitmap_head * = bitmap.
Likewise here:

 /* Basic blocks that have occurrences reachable from BB.  */
 bitmap_head _from_bbs, *from_bbs = _from_bbs;
+/* Basic blocks through which expr is hoisted.  */
+bitmap_head _hoisted_bbs, *hoisted_bbs = _hoisted_bbs;

And using BITMAP_ALLOC here:
 bitmap_initialize (from_bbs, 0);
 +   if (flag_ira_hoist_pressure == 1)
 + bitmap_initialize (hoisted_bbs, 0);

(Some older code uses the bitmap_head * form, but that pre-dates
coretypes.h. Newer code that uses the old form should really be
fixed also.)

Please also use an obstack for the hoisted_bbs and from_bbs bitmaps.
They're currently allocated in GC space but that's completely
unnecessary for objects with such a clearly identifiable life time.
You can even allocate these bitmaps outside the loop, you're already
calling bitmap_clear on them.


 EXPR_BB. Stop

Two spaces after a period in comments.


 @@ -2863,7 +2909,8 @@ static int
if (visited == NULL)
  {
visited_allocated_locally = 1;
 -  visited = XCNEWVEC (char, last_basic_block);
 +  visited = sbitmap_alloc (last_basic_block);
 +  sbitmap_zero (visited);
  }

Can you please submit this as a separate patch? I'd go ahead and
commit it as obvious, but it's always good to have one change per
patch and this bit is independent of the reg-pressure dependent
hoisting.


 +fira-hoist-pressure
 +Common Report Var(flag_ira_hoist_pressure) Init(-1)
 +Use IRA based register pressure calculation
 +in hoist optimizations.

Please add the Optimization marker. Why initialize to -1? The
default initialization is 0, and if the flag is set it takes a value
1. If you follow that common behavior, you can replace all occurrences
of if (flag_ira_hoist_pressure == 1) with just if
(flag_ira_hoist_pressure).


 +  /* Enable register pressure hoist when optimizing for size on Thumb1 set.  
 */
 +  if (TARGET_THUMB1  optimize_function_for_size_p (cfun)
 +   flag_ira_hoist_pressure == -1)
 +flag_ira_hoist_pressure = 1;

One would expect this to be a win on all targets, but you probably
looked at this (at least Thumb2 and plain ARM). Did your patch not
help 

Re: [PATCH] Fix PR middle-end/54759

[Richard Guenther]

On Sun, Sep 30, 2012 at 9:03 PM, Dehao Chen de...@google.com wrote:
 Hi,

 This patch fixes the bug when comparing location to UNKNOWN_LOC.

 Bootstrapped and passed gcc regression test.

 Okay for trunk?

Ok.

Thanks,
Richard.

 Thanks,
 Dehao

 2012-09-30  Dehao Chen  de...@google.com

 PR middle-end/54759
 * gcc/tree-vect-loop-manip.c (slpeel_make_loop_iterate_ntimes): Use
 LOCATION_LOCUS to compare with UNKNOWN_LOCATION.
 (slpeel_tree_peel_loop_to_edge): Likewise.
 * gcc/tree-vectorizer.c (vectorize_loops): Likewise.

Re: RFC: LRA for x86/x86-64 [0/9]

[Richard Guenther]

On Mon, Oct 1, 2012 at 7:48 AM, Jakub Jelinek ja...@redhat.com wrote:
 On Sun, Sep 30, 2012 at 06:50:50PM -0400, Vladimir Makarov wrote:
   But I think that LRA cpu time problem for this test can be fixed.
 But I don't think I can fix it for 2 weeks.  So if people believe
 that current LRA behaviour on this PR is a stopper to include it
 into gcc4.8 than we should postpone its inclusion until gcc4.9 when
 I hope to fix it.

 I think this testcase shouldn't be a show stopper for LRA inclusion into
 4.8, but something to look at for stage3.

I agree here.

 I think a lot of GCC passes have scalability issues on that testcase,
 that is why it must be compiled with -O1 and not higher optimization
 options, so perhaps it would be enough to choose a faster algorithm
 generating worse code for the huge functions and -O1.

Yes, we spent quite some time in making basic optimization work for
insane testcases (basically avoid quadratic or bigger complexity in any
IL size variable (number of basic-blocks, edges, instructions, pseudos, etc.)).

And indeed if you use -O2 we do have issues with existing passes (and even
at -O1 points-to analysis can wreck things, or even profile guessing - see
existing bugs for that).  Basically I would tune -O1 towards being able to
compile and optimize insane testcases with memory and compile-time
requirements that are linear in any of the above complexity measures.

Thus, falling back to the -O0 register allocating strathegy at certain
thresholds for the above complexity measures is fine (existing IRA
for example has really bad scaling on the number of loops in the function,
but you can tweak with flags to make it not consider that).

 And I agree it is primarily a bug in the generator that it creates such huge
 functions, that can't perform very well.

Well, not for -O2+, yes, but at least we should try(!) hard.

Thanks,
Richard.

 Jakub

Re: [Patch,avr]: Ad PR rtl-optimization/52543: Undo the MEM-UNSPEC hack

[Denis Chertykov]

2012/9/30 Georg-Johann Lay a...@gjlay.de:
 Denis Chertykov wrote:
 I have tried to use secondary a few years ago (may be 5 or 7).
 I have definitely remember only one thing: secondary reload should be
 avoided as long as possible.


 Currently each mov has to be decorated with moving the segment to RAMPZ and
 (depending on target) restoring RAMPZ afterwards.

 GCC has no concept of a segmented layout and there is no way to describe
 that.

 One way is to hack with UNSPEC and bypass ira/reload altogether but IMO that
 is no good solution.  Besides that is only works because the mov insns have
 special constraints (there will be writes to flash, flash does not change
 after load time, etc.)


 The better way to got a knowledge about it is a GDB ;-)


 I think reload.c:push_secondary_reload() should be the right place but it
 does not call targetm.secondary_reload so that no secondary is generated.

 It's hard to tell where the place is that is responsible for the bypassing
 of calling the hook.


 From the internals I don't see why it is skipped and the responsiveness
 in
 the gcc-help@ list on such topics is zero :-(


 IMHO  it's a question to gcc@ not to gcc-help@


 Ok, I will try my luck again.

 Do you have an idea for a better approach, i.e. not set RAMPZ over and over
 again?

May be it's a question similar to addressing with infinite
displacement optimization that we discuss in
long long thread - [Patch, AVR]: Fix PR46779
Generally, the answer is here:
http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01281.html
and here:
 The biggest problem that I see, from the 950612-1.c test case
 with the current handling of the infinite displacement frame
 pointer, is that the adjustments to the frame pointer are
 never exposed as separate instructions, so there's never a
 chance to optimize them.

You can set RAMPZ over and over but you can give GCC a chance to
optimize it out in cse or cse-postreload passes.

Denis.

PS: as you know GCC has no concept of a segmented layout may be
better just drop it.

Re: RFC: LRA for x86/x86-64 [0/9]

[Steven Bosscher]

On Mon, Oct 1, 2012 at 9:16 AM, Jakub Jelinek ja...@redhat.com wrote:
 On Mon, Oct 01, 2012 at 08:47:13AM +0200, Steven Bosscher wrote:
 The test case compiles just fine at -O2, only VRP has trouble with it.
 Let's try to stick with facts, not speculation.

 I was talking about the other PR, PR26854, which from what I remember when
 trying it myself and even the latest -O3 time reports from the reduced
 testcase show that IRA/reload aren't there very significant (for -O3 IRA
 takes ~ 6% and reload ~ 1%).

OK, but what does LRA take? Vlad's numbers for 64-bits and looking at user time:

Reload: 503.26user
LRA: 598.70user

So if reload is ~1% of 503s then that'd be ~5s. And the only
difference between the two timings is LRA instead of reload, so LRA
takes ~100s, or 20%.


 I've put a lot of hard work into it to fix almost all scalability problems
 on this PR for gcc 4.8. LRA undoes all of that work. I understand it is
 painful for some people to hear, but I remain of opinion that LRA cannot be
 considered ready if it scales so much worse than everything else in the
 compiler.

 Judging the whole implementation from just these corner cases and not how it
 performs on other testcases (SPEC, rebuild a distro, ...) is IMHO not the
 right thing, if Vlad thinks the corner cases are fixable during stage3; IMHO
 we should allow LRA in, worst case it can be disabled by default even for
 i?86/x86_64.

I'd be asked to do a guest lecture on compiler construction (to be
clear: I'd be highly surprised if anyone would ask me to, but for sake
of argument, bear with me ;-) then I'd start by stating that
algorithms should be designed for the corner cases, because the
devil's always in the details.

But more to the point regarding stage3: It will already be a busy
stage3 if the other, probably even more significant, scalability
issues have to be fixed, i.e. var-tracking and macro expansion. And
there's also the symtab work that's bound to cause some interesting
bugs still to be shaken out. With all due respect to Vlad, and,
seriously, hats off to Vlad for tacking reload and coming up with a
much easier to understand and nicely phase-split replacement, I just
don't believe that these scalability issues can be addressed in
stage3.

It's now very late stage1, and LRA was originally scheduled for GCC
4.9. Why the sudden hurrying? Did I miss the 2 minute warning?

Ciao!
Steven

Re: Profile housekeeping 5/n (make RTL loop optimizers to use loop bounds better)

[Richard Guenther]

On Mon, Oct 1, 2012 at 11:37 AM, Jan Hubicka hubi...@ucw.cz wrote:
 Hi,
 this patch commonizes the maximal iteration estimate logic in between SCEV and
 loop-iv.  Both are now using loop-nb_iterations_upper_bound.  I decided to
 keep same API for SCEV code as for RTL code, so I made
 estimated_loop_iterations and max_loop_iterations to not try to recompute
 bounds and ICE when invoked without SCEV fired on.

 The patch updates RTL optimizers to use the estimated_loop_iterations and
 max_loop_iterations. This has few advantages:
   1) loop unroller can now take into account estimates stored into
  loop structure by earlier pass (I think none exist though)
  It is however better then using expected_loop_iterations since
  profile might get out of date with expansion.

   2) loop peeling code now use max iterations bounds. This makes it i.e.
  to peel vectorizer prologues/epilogues/scalar loops so -fpeel-loops
  now improves my low iteration count testcase by about 10%

   3) Same for loop unswithcing.

 I am not really friend with the new double_int API. I copied some existing
 examples but find it ugly.  Why do we miss operators for comparsions and
 division? Why from_*/to_* can't be a cast at least for basic integer types?

 Regtested/bootstrapped x86_64-linux, seems sane?

Yes.  Can you add a testcase or two?  I tweaked RTL unroll/peel after preserving
loops to not blindly unroll/peel everything 8 times (not sure if _I_
added testcases ...).

 I also wonder if loop vectorizer should not update the estimates after
 loop iteration count is reduced by vectorizing.

Probably yes.

Thanks,
Richard.

 Honza
 * loop-unswitch.c (unswitch_single_loop): Use
 estimated_loop_iterations_int to prevent unswitching when loop
 is known to not roll.
 * tree-ssa-loop-niter.c (estimated_loop_iterations): Do not segfault
 when SCEV is not initialized.
 (max_loop_iterations): Likewise.
 * tree-ssa-loop-unswitch.c (tree_ssa_unswitch_loops): Use
 estimated_loop_iterations_int to prevent unswithcing when
 loop is known to not roll.
 * tree-scalar-evolution.c (scev_initialized_p): New function.
 * tree-scalar-evolution.h (scev_initialized_p): Likewise.
 * loop-unroll.c (decide_peel_once_rolling): Use
 max_loop_iterations_int.
 (unroll_loop_constant_iterations): Update
 nb_iterations_upper_bound and nb_iterations_estimate.
 (decide_unroll_runtime_iterations): Use
 estimated_loop_iterations or max_loop_iterations;
 (unroll_loop_runtime_iterations): fix profile updating.
 (decide_peel_simple): Use estimated_loop_iterations
 and max_loop_iterations.
 (decide_unroll_stupid): Use estimated_loop_iterations
 ad max_loop_iterations.
 * loop-doloop.c (doloop_modify): Use max_loop_iterations_int.
 (doloop_optimize): Likewise.
 * loop-iv.c (iv_number_of_iterations): Use record_niter_bound.
 (find_simple_exit): Likewise.
 * cfgloop.h (struct niter_desc): Remove niter_max.

 Index: loop-unswitch.c
 ===
 *** loop-unswitch.c (revision 191867)
 --- loop-unswitch.c (working copy)
 *** unswitch_single_loop (struct loop *loop,
 *** 257,262 
 --- 257,263 
 rtx cond, rcond = NULL_RTX, conds, rconds, acond, cinsn;
 int repeat;
 edge e;
 +   HOST_WIDE_INT iterations;

 /* Do not unswitch too much.  */
 if (num  PARAM_VALUE (PARAM_MAX_UNSWITCH_LEVEL))
 *** unswitch_single_loop (struct loop *loop,
 *** 299,305 
   }

 /* Nor if the loop usually does not roll.  */
 !   if (expected_loop_iterations (loop)  1)
   {
 if (dump_file)
 fprintf (dump_file, ;; Not unswitching, loop iterations  1\n);
 --- 300,307 
   }

 /* Nor if the loop usually does not roll.  */
 !   iterations = estimated_loop_iterations_int (loop);
 !   if (iterations = 0  iterations = 1)
   {
 if (dump_file)
 fprintf (dump_file, ;; Not unswitching, loop iterations  1\n);
 Index: tree-ssa-loop-niter.c
 ===
 *** tree-ssa-loop-niter.c   (revision 191867)
 --- tree-ssa-loop-niter.c   (working copy)
 *** estimate_numbers_of_iterations_loop (str
 *** 3012,3020 
   bool
   estimated_loop_iterations (struct loop *loop, double_int *nit)
   {
 !   estimate_numbers_of_iterations_loop (loop);
 if (!loop-any_estimate)
 ! return false;

 *nit = loop-nb_iterations_estimate;
 return true;
 --- 3012,3034 
   bool
   estimated_loop_iterations (struct loop *loop, double_int *nit)
   {
 !   /* When SCEV information is available, try to update loop iterations
 !  estimate.  Otherwise just return whatever we recorded earlier.  */
 !   if (scev_initialized_p ())
 ! 

Re: RFC: LRA for x86/x86-64 [0/9]

[Steven Bosscher]

On Mon, Oct 1, 2012 at 11:52 AM, Richard Guenther
richard.guent...@gmail.com wrote:
 I think this testcase shouldn't be a show stopper for LRA inclusion into
 4.8, but something to look at for stage3.

 I agree here.

I would also agree if it were not for the fact that IRA is already a
scalability bottle-neck and that has been known for a long time, too.
I have no confidence at all that if LRA goes in now, these scalability
problems will be solved in stage3 or at any next release cycle. It's
always the same thing with GCC: Once a patch is in, everyone moves on
to the next fancy new thing dropping the not-quite-broken but also
not-quite-working things on the floor.

Ciao!
Steven

Re: RFC: LRA for x86/x86-64 [0/9]

[Steven Bosscher]

On Sun, Sep 30, 2012 at 7:03 PM, Richard Guenther
richard.guent...@gmail.com wrote:
 On Sun, Sep 30, 2012 at 6:52 PM, Steven Bosscher stevenb@gmail.com 
 wrote:
 Hi,


 To look at it in yet another way:

  integrated RA   : 189.34 (16%) usr
  LRA non-specific:  59.82 ( 5%) usr
  LRA virtuals eliminatenon:  56.79 ( 5%) usr
  LRA create live ranges  : 175.30 (15%) usr
  LRA hard reg assignment : 130.85 (11%) usr

 The IRA pass is slower than the next-slowest pass (tree PRA) by almost
 a factor 2.5.  Each of the individually-measured *phases* of LRA is
 slower than the complete IRA *pass*. These 5 timevars together make up
 for 52% of all compile time.

 That figure indeed makes IRA + LRA look bad.  Did you by chance identify
 anything obvious that can be done to improve the situation?

The  LRA create live range time is mostly spent in merge_live_ranges
walking lists. Perhaps the live ranges can be represented better with
a sorted VEC, so that the start and finish points can be looked up on
log-time instead of linear.

Ciao!
Steven

Re: RFC: LRA for x86/x86-64 [0/9]

[Jakub Jelinek]

On Mon, Oct 01, 2012 at 12:01:36PM +0200, Steven Bosscher wrote:
 I would also agree if it were not for the fact that IRA is already a
 scalability bottle-neck and that has been known for a long time, too.
 I have no confidence at all that if LRA goes in now, these scalability
 problems will be solved in stage3 or at any next release cycle. It's
 always the same thing with GCC: Once a patch is in, everyone moves on
 to the next fancy new thing dropping the not-quite-broken but also
 not-quite-working things on the floor.

If we open a P1 bug for it for 4.8, then it will need to be resolved some
way before branching.  I think Vlad is committed to bugfixing LRA, after
all the intent is for 4.9 to enable it on more (all?) targets, and all the
bugfixing and scalability work on LRA is needed for that anyway.

Jakub

[Ada] Implement extended overflow handling for comparison ops

[Arnaud Charlet]

This patch enables extended overflow handling for comparison ops
so that the comparison can be done in an expanded type, or even
in bignum mode if operating in ELIMINATED overflow check mode.

The following test program:

 1. with Text_IO; use Text_IO;
 2. procedure Overflowm2 is
 3.function r1
 4.  (a, b, c, d : Integer) return Boolean is
 5.begin
 6.   return a + b + c + d = Integer'Last;
 7.end;
 8.function r2
 9.  (a, b, c, d : Integer) return Boolean is
10.begin
11.   return a * b * c * d = Integer'First;
12.end;
13. begin
14.begin
15.   Put_Line
16. (r1 returns  
17.Boolean'Image
18.  (r1 (Integer'Last, Integer'Last,
19.   -Integer'Last, -Integer'Last)));
20.exception
21.   when Constraint_Error =
22.  Put_Line (r1 raises exception);
23.end;
24.
25.begin
26.   Put_Line
27. (r2 returns  
28.Boolean'Image
29.  (r2 (Integer'Last, Integer'Last,
30.   Integer'Last, 0)));
31.exception
32.   when Constraint_Error =
33.  Put_Line (r2 raises exception);
34.end;
35. end Overflowm2;

In CHECKED mode (-gnato1) we get:

r1 raises exception
r2 raises exception

since the first addition in r1 and the first multiplication
in r2 result in values outside the bounds of Integer'Base.

In MINIMIZED mode (-gnato2) we get:

r1 returns TRUE
r2 raises exception

since we can compute the addition result in Long_Long_Integer,
and do the comparison in Long_Long_Integer mode, but the
second multiplication yields a value outside this range,
so that causes an overflow.

In ELIMINATE mode (-gnato3) we get:

r1 returns TRUE
r2 returns TRUE

Because now we use Bignum arithmetic for the intermediate
multiplication results, and the final comparison is also
done in bignum mode.

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

2012-10-01  Robert Dewar  de...@adacore.com

* exp_ch4.adb (Expand_Compare_Minimize_Eliminate_Overflow):
New procedure.

Index: exp_ch4.adb
===
--- exp_ch4.adb (revision 191912)
+++ exp_ch4.adb (working copy)
@@ -140,6 +140,10 @@
procedure Expand_Short_Circuit_Operator (N : Node_Id);
--  Common expansion processing for short-circuit boolean operators
 
+   procedure Expand_Compare_Minimize_Eliminate_Overflow (N : Node_Id);
+   --  Deal with comparison in Minimize/Eliminate overflow mode. This is where
+   --  we allow comparison of out of range values.
+
function Expand_Composite_Equality
  (Nod: Node_Id;
   Typ: Entity_Id;
@@ -2276,6 +2280,237 @@
   end;
end Expand_Boolean_Operator;
 
+   
+   -- Expand_Compare_Minimize_Eliminate_Overflow --
+   
+
+   procedure Expand_Compare_Minimize_Eliminate_Overflow (N : Node_Id) is
+  Loc : constant Source_Ptr := Sloc (N);
+
+  Llo, Lhi : Uint;
+  Rlo, Rhi : Uint;
+
+  LLIB : constant Entity_Id := Base_Type (Standard_Long_Long_Integer);
+  --  Entity for Long_Long_Integer'Base
+
+  Check : constant Overflow_Check_Type := Overflow_Check_Mode (Empty);
+  --  Current checking mode
+
+  procedure Set_True;
+  procedure Set_False;
+  --  These procedures rewrite N with an occurrence of Standard_True or
+  --  Standard_False, and then makes a call to Warn_On_Known_Condition.
+
+  ---
+  -- Set_False --
+  ---
+
+  procedure Set_False is
+  begin
+ Rewrite (N, New_Occurrence_Of (Standard_False, Loc));
+ Warn_On_Known_Condition (N);
+  end Set_False;
+
+  --
+  -- Set_True --
+  --
+
+  procedure Set_True is
+  begin
+ Rewrite (N, New_Occurrence_Of (Standard_True, Loc));
+ Warn_On_Known_Condition (N);
+  end Set_True;
+
+   --  Start of processing for Expand_Compare_Minimize_Eliminate_Overflow
+
+   begin
+  --  Nothing to do unless we have a comparison operator with operands
+  --  that are signed integer types, and we are operating in either
+  --  MINIMIZED or ELIMINATED overflow checking mode.
+
+  if Nkind (N) not in N_Op_Compare
+or else Check not in Minimized_Or_Eliminated
+or else not Is_Signed_Integer_Type (Etype (Left_Opnd (N)))
+  then
+ return;
+  end if;
+
+  --  OK, this is the case we are interested in. First step is to process
+  --  our operands using the Minimize_Eliminate circuitry which applies
+  --  this processing to the two operand subtrees.
+
+  Minimize_Eliminate_Overflow_Checks (Left_Opnd (N),  Llo, Lhi);
+  Minimize_Eliminate_Overflow_Checks (Right_Opnd (N), Rlo, Rhi);
+
+  --  

Re: RFC: LRA for x86/x86-64 [0/9]

[Steven Bosscher]

On Mon, Oct 1, 2012 at 12:14 PM, Jakub Jelinek ja...@redhat.com wrote:
 On Mon, Oct 01, 2012 at 12:01:36PM +0200, Steven Bosscher wrote:
 I would also agree if it were not for the fact that IRA is already a
 scalability bottle-neck and that has been known for a long time, too.
 I have no confidence at all that if LRA goes in now, these scalability
 problems will be solved in stage3 or at any next release cycle. It's
 always the same thing with GCC: Once a patch is in, everyone moves on
 to the next fancy new thing dropping the not-quite-broken but also
 not-quite-working things on the floor.

 If we open a P1 bug for it for 4.8, then it will need to be resolved some
 way before branching.  I think Vlad is committed to bugfixing LRA, after
 all the intent is for 4.9 to enable it on more (all?) targets, and all the
 bugfixing and scalability work on LRA is needed for that anyway.

I don't question Vlad's commitment, but the last time I met him, he
only had two hands just like everyone else.

But I've made my point and it seems that I'm not voting with the majority.

Ciao!
Steven

Re: RFC: LRA for x86/x86-64 [0/9]

[Bernd Schmidt]

On 10/01/2012 12:14 PM, Jakub Jelinek wrote:
 On Mon, Oct 01, 2012 at 12:01:36PM +0200, Steven Bosscher wrote:
 I would also agree if it were not for the fact that IRA is already a
 scalability bottle-neck and that has been known for a long time, too.
 I have no confidence at all that if LRA goes in now, these scalability
 problems will be solved in stage3 or at any next release cycle. It's
 always the same thing with GCC: Once a patch is in, everyone moves on
 to the next fancy new thing dropping the not-quite-broken but also
 not-quite-working things on the floor.
 
 If we open a P1 bug for it for 4.8, then it will need to be resolved some
 way before branching.  I think Vlad is committed to bugfixing LRA, after
 all the intent is for 4.9 to enable it on more (all?) targets, and all the
 bugfixing and scalability work on LRA is needed for that anyway.

Why can't this be done on the branch? We've made the mistake of rushing
things into mainline too early a few times before, we should have
learned by now. And adding more half transitions is not something we
really want either.


Bernd

[Patch, Committed] Fix declared inline after being called warning

[Tom de Vries]

Hi,

I've committed to branch 4.7 as obvious attached patch that fixes a compiler
warning 'declared inline after being called'.

I ran into this warning when building the 4.7 branch with a gcc 4.3 compiler:
...
var-tracking.c:558: warning: 'set_dv_changed' declared inline after being called
var-tracking.c:558: warning: previous declaration of 'set_dv_changed' was here
...

Other instances of this problem are:
- http://gcc.gnu.org/ml/gcc-patches/2011-12/msg00256.html
- http://gcc.gnu.org/ml/gcc-patches/2011-04/msg01426.html

I've fixed this in the 4.7 branch. The problem is not present in the 4.6 branch,
and with trunk the warning doesn't trigger, I suppose because we're using g++ 
now.

Build on i686-pc-linux-gnu.

Thanks,
- Tom

2012-10-01  Tom de Vries  t...@codesourcery.com

* var-tracking.c (set_dv_changed): Add an 'inline' function specifier to
the prototype.
Index: gcc/var-tracking.c
===
--- gcc/var-tracking.c (revision 191792)
+++ gcc/var-tracking.c (working copy)
@@ -570,7 +570,7 @@ static void dump_vars (htab_t);
 static void dump_dataflow_set (dataflow_set *);
 static void dump_dataflow_sets (void);
 
-static void set_dv_changed (decl_or_value, bool);
+static inline void set_dv_changed (decl_or_value, bool);
 static void variable_was_changed (variable, dataflow_set *);
 static void **set_slot_part (dataflow_set *, rtx, void **,
 			 decl_or_value, HOST_WIDE_INT,

[patch][lra] Use XNEWVEC and friends instead of xmalloc/xrealloc, and add some timevars

[Steven Bosscher]

Hello,

This patch uses the libiberty new-like operators instead of using
xmalloc/xrealloc.
It also adds timevars for the main LRA phases, and it fixes a warning
suggesting a space before a ';' in an only-looping for loop.

Bootstrapped (lra-branch, of course) on x86_64-unknown-linux-gnu. OK?

Ciao!
Steven


lra_XALLOC.diff
Description: Binary data

Re: RFC: LRA for x86/x86-64 [0/9]

[Steven Bosscher]

On Mon, Oct 1, 2012 at 12:10 PM, Steven Bosscher stevenb@gmail.com wrote:
 The  LRA create live range time is mostly spent in merge_live_ranges
 walking lists.

Hmm no, that's just gcc17's ancient debugger telling me lies.
lra_live_range_in_p is not even used.

/me upgrades to something newer than gdb 6.8...

Ciao!
Steven

Re: Constant-fold vector comparisons

[Richard Guenther]

On Sat, Sep 29, 2012 at 3:25 PM, Marc Glisse marc.gli...@inria.fr wrote:
 Hello,

 this patch does 2 things (I should have split it in 2, but the questions go
 together):

 1) it handles constant folding of vector comparisons,

 2) it fixes another place where vectors are not expected (I'll probably wait
 to have front-end support and testcases to do more of those, but there is
 something to discuss).

 I wasn't sure what integer_truep should test exactly. For integer: == 1 or
 != 0? For vectors: == -1 or  0? I chose the one that worked best for the
 forwprop case where I used it.

 It seems that before this patch, the middle-end didn't know how comparison
 results were encoded (a good reason for VEC_COND_EXPR to require a
 comparison as its first argument). I am using the OpenCL encoding that what
 matters is the high bit of each vector element. I am not quite sure what
 happens for targets (are there any?) that use a different encoding. When
 expanding vcond, they can do the comparison as they like. When expanding an
 isolated comparison, I expect they have to expand it as vcond(ab,-1,0). So
 it should be ok, but I could easily have missed something.

Comments below


 2012-10-01  Marc Glisse  marc.gli...@inria.fr

 gcc/
 * tree.c (integer_truep): New function.
 * tree.h (integer_truep): Declare.
 * tree-ssa-forwprop.c (forward_propagate_into_cond): Call it.
 Don't use boolean_type_node for vectors.
 * fold-const.c (fold_relational_const): Handle VECTOR_CST.

 gcc/testsuite/
 * gcc.dg/tree-ssa/foldconst-6.c: New testcase.

 --
 Marc Glisse
 Index: gcc/tree.h
 ===
 --- gcc/tree.h  (revision 191850)
 +++ gcc/tree.h  (working copy)
 @@ -5272,20 +5272,25 @@ extern int integer_zerop (const_tree);

  /* integer_onep (tree x) is nonzero if X is an integer constant of value 1.
 */

  extern int integer_onep (const_tree);

  /* integer_all_onesp (tree x) is nonzero if X is an integer constant
 all of whose significant bits are 1.  */

  extern int integer_all_onesp (const_tree);

 +/* integer_truep (tree x) is nonzero if X is an integer constant of value
 1,
 +   or a vector constant of value  0.  */
 +
 +extern bool integer_truep (const_tree);
 +
  /* integer_pow2p (tree x) is nonzero is X is an integer constant with
 exactly one bit 1.  */

  extern int integer_pow2p (const_tree);

  /* integer_nonzerop (tree x) is nonzero if X is an integer constant
 with a nonzero value.  */

  extern int integer_nonzerop (const_tree);

 Index: gcc/tree-ssa-forwprop.c
 ===
 --- gcc/tree-ssa-forwprop.c (revision 191850)
 +++ gcc/tree-ssa-forwprop.c (working copy)
 @@ -564,46 +564,46 @@ forward_propagate_into_cond (gimple_stmt
enum tree_code code;
tree name = cond;
gimple def_stmt = get_prop_source_stmt (name, true, NULL);
if (!def_stmt || !can_propagate_from (def_stmt))
 return 0;

code = gimple_assign_rhs_code (def_stmt);
if (TREE_CODE_CLASS (code) == tcc_comparison)
 tmp = fold_build2_loc (gimple_location (def_stmt),
code,
 -  boolean_type_node,
 +  TREE_TYPE (cond),

That's obvious.

gimple_assign_rhs1 (def_stmt),
gimple_assign_rhs2 (def_stmt));
else if ((code == BIT_NOT_EXPR
  TYPE_PRECISION (TREE_TYPE (cond)) == 1)
|| (code == BIT_XOR_EXPR
 -   integer_onep (gimple_assign_rhs2 (def_stmt
 +   integer_truep (gimple_assign_rhs2 (def_stmt

See below.

 {
   tmp = gimple_assign_rhs1 (def_stmt);
   swap = true;
 }
  }

if (tmp
 is_gimple_condexpr (tmp))
  {
if (dump_file  tmp)
 {
   fprintf (dump_file,   Replaced ');
   print_generic_expr (dump_file, cond, 0);
   fprintf (dump_file, ' with ');
   print_generic_expr (dump_file, tmp, 0);
   fprintf (dump_file, '\n);
 }

 -  if (integer_onep (tmp))
 +  if (integer_truep (tmp))
 gimple_assign_set_rhs_from_tree (gsi_p, gimple_assign_rhs2 (stmt));
else if (integer_zerop (tmp))
 gimple_assign_set_rhs_from_tree (gsi_p, gimple_assign_rhs3 (stmt));
else
 {
   gimple_assign_set_rhs1 (stmt, unshare_expr (tmp));
   if (swap)
 {
   tree t = gimple_assign_rhs2 (stmt);
   gimple_assign_set_rhs2 (stmt, gimple_assign_rhs3 (stmt));
 Index: gcc/testsuite/gcc.dg/tree-ssa/foldconst-6.c
 ===
 --- gcc/testsuite/gcc.dg/tree-ssa/foldconst-6.c (revision 0)
 +++ gcc/testsuite/gcc.dg/tree-ssa/foldconst-6.c (revision 0)
 @@ -0,0 +1,14 @@
 +/* { 

Re: [PATCH] Add option for dumping to stderr (issue6190057)

[H.J. Lu]

On Sun, Sep 30, 2012 at 11:36 PM, Sharad Singhai sing...@google.com wrote:
 Resend to gcc-patches

 I have addressed the comments by fixing all the minor issues,
 bootstrapped and tested on x86_64. I did the recommended reshuffling
 by moving non-tree code from tree-dump.c into a new file dumpfile.c.

 I committed two successive revisions
 r191883 Main patch with the dump infrastructure changes. However, I
 accidentally left out a new file, dumpfile.c.
 r191884 Added dumpfile.c, and did the renaming of dump_* functions
 from gimple_pretty_print.[ch].

 As things stand right now, r191883 is broken because of the missing
 file 'dumpfile.c', which the very next commit fixes. Anyone who got
 broken revision r191883, please svn update. I am really very sorry
 about that.

 I have a couple more minor patches which deal with renaming; I plan to
 address those later.


It caused:

FAIL: gcc.dg/tree-ssa/gen-vect-11.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/gen-vect-11.c scan-tree-dump-times vect
vectorized 1 loops 1
FAIL: gcc.dg/tree-ssa/gen-vect-11a.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/gen-vect-11a.c scan-tree-dump-times vect
vectorized 1 loops 1
FAIL: gcc.dg/tree-ssa/gen-vect-11b.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/gen-vect-11b.c scan-tree-dump-times vect
vectorized 0 loops 1
FAIL: gcc.dg/tree-ssa/gen-vect-11c.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/gen-vect-11c.c scan-tree-dump-times vect
vectorized 0 loops 1
FAIL: gcc.dg/tree-ssa/gen-vect-2.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/gen-vect-2.c scan-tree-dump-times vect
vectorized 1 loops 1
FAIL: gcc.dg/tree-ssa/gen-vect-25.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/gen-vect-25.c scan-tree-dump-times vect
vectorized 2 loops 1
FAIL: gcc.dg/tree-ssa/gen-vect-26.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/gen-vect-26.c scan-tree-dump-times vect
Alignment of access forced using peeling 1
FAIL: gcc.dg/tree-ssa/gen-vect-26.c scan-tree-dump-times vect
vectorized 1 loops 1
FAIL: gcc.dg/tree-ssa/gen-vect-28.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/gen-vect-28.c scan-tree-dump-times vect
Alignment of access forced using peeling 1
FAIL: gcc.dg/tree-ssa/gen-vect-28.c scan-tree-dump-times vect
vectorized 1 loops 1
FAIL: gcc.dg/tree-ssa/gen-vect-32.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/gen-vect-32.c scan-tree-dump-times vect
vectorized 1 loops 1
FAIL: gfortran.dg/vect/O3-pr36119.f90 (test for excess errors)
FAIL: gfortran.dg/vect/O3-pr39595.f (test for excess errors)
FAIL: gfortran.dg/vect/Ofast-pr50414.f90 (test for excess errors)
FAIL: gfortran.dg/vect/cost-model-pr34445.f (test for excess errors)
FAIL: gfortran.dg/vect/cost-model-pr34445a.f (test for excess errors)
FAIL: gfortran.dg/vect/fast-math-pr38968.f90 (test for excess errors)
FAIL: gfortran.dg/vect/fast-math-pr38968.f90 scan-tree-dump vect
vectorized 1 loops
FAIL: gfortran.dg/vect/fast-math-real8-pr40801.f90 (test for excess errors)
FAIL: gfortran.dg/vect/fast-math-real8-pr40801.f90 (test for excess errors)
FAIL: gfortran.dg/vect/fast-math-vect-8.f90 (test for excess errors)
FAIL: gfortran.dg/vect/fast-math-vect-8.f90 scan-tree-dump-times vect
vectorized 1 loops 1
FAIL: gfortran.dg/vect/no-fre-no-copy-prop-O3-pr51704.f90 (test for
excess errors)
FAIL: gfortran.dg/vect/no-vfa-pr32377.f90 (test for excess errors)
FAIL: gfortran.dg/vect/no-vfa-pr32377.f90 scan-tree-dump-times vect
vectorized 2 loops 1
FAIL: gfortran.dg/vect/no-vfa-pr32457.f90 (test for excess errors)
FAIL: gfortran.dg/vect/no-vfa-pr32457.f90 scan-tree-dump-times vect
vectorized 0 loops 1
FAIL: gfortran.dg/vect/pr19049.f90  -O   scan-tree-dump-times vect
complicated access pattern 1
FAIL: gfortran.dg/vect/pr19049.f90  -O  (test for excess errors)
FAIL: gfortran.dg/vect/pr32377.f90  -O   scan-tree-dump-times vect
vectorized 2 loops 1
FAIL: gfortran.dg/vect/pr32377.f90  -O  (test for excess errors)
FAIL: gfortran.dg/vect/pr32380.f  -O   scan-tree-dump-times vect
vectorized 6 loops 1
FAIL: gfortran.dg/vect/pr32380.f  -O  (test for excess errors)
FAIL: gfortran.dg/vect/pr33301.f  -O  (test for excess errors)
FAIL: gfortran.dg/vect/pr50178.f90  -O  (test for excess errors)
FAIL: gfortran.dg/vect/pr50412.f90  -O  (test for excess errors)
FAIL: gfortran.dg/vect/pr51058-2.f90  -O  (test for excess errors)
FAIL: gfortran.dg/vect/pr51058.f90  -O  (test for excess errors)
FAIL: gfortran.dg/vect/pr51285.f90  -O  (test for excess errors)
FAIL: gfortran.dg/vect/vect-1.f90  -O   scan-tree-dump-times vect
vectorized 3 loops 1
FAIL: gfortran.dg/vect/vect-1.f90  -O  (test for excess errors)
FAIL: gfortran.dg/vect/vect-2.f90  -O   scan-tree-dump-times vect
Alignment of access forced using peeling 3
FAIL: gfortran.dg/vect/vect-2.f90  -O   scan-tree-dump-times vect
Vectorizing an unaligned access 2
FAIL: gfortran.dg/vect/vect-2.f90  -O   scan-tree-dump-times vect
vectorized 3 loops 1
FAIL: gfortran.dg/vect/vect-2.f90  -O  (test for excess errors)
FAIL: gfortran.dg/vect/vect-3.f90  -O   

[patch] experimenting with renumbering of pseudos after expand

[Steven Bosscher]

Hello,

For most code, expand creates a lot of pseudos that are cleaned up in
subsequent passes, if they even live long enough to make it there. On
average, for cc1 preprocessed source, the number of holes in
regno_reg_rtx is about half the size of that array, or in other words:
regno_reg_rtx is almost a sparse array.

I've been experimenting with the attached patch to renumber pseudos
just before initializing DF. For the already-notorious test case of
PR54146 on x86_64, the patch reduces max_reg_num from 348404 to 180502
for the largest function. This reduces the memory foot print of the
test case to less than 6GB, an almost 25% reduction, and it speeds up
the DF_LR and DF_LIVE problems a bit (~15% but that's not much on the
total compile time).

I had hopes that it would help for LRA compile times also, but
unfortunately the only significant change is this one:

without patch:
 LRA hard reg assignment : 130.85 (11%) usr   0.20 ( 1%) sys 131.17
(11%) wall   0 kB ( 0%) ggc

with patch:
 LRA hard reg assignment : 108.92 ( 9%) usr   0.07 ( 0%) sys 109.03 (
9%) wall   0 kB ( 0%) ggc

Anyway, putting the patch out there to show that I've done more than
just complaining ;-)

It also would suggest that the scalability challenge for LRA is not
the number of pseudos but something else (number of insns, I guess).

Ciao!
Steven


compact_regno_reg_rtx.diff
Description: Binary data

[PATCH] Fix PR47799 - debug info for early-inlining with LTO

[Richard Guenther]

This tries to emit proper debug information for early-inlined
functions from LTO LTRANS phase (thus, emit DW_TAG_inlined_subroutine
and allow gdb to set breakpoints).  We need to avoid confusing
LTO and dwarf2out with the full abstract block tree, so this
patch flattens the abstract block tree by always using the
ultimate origin for BLOCK_ABSTRACT_ORIGIN on blocks which are
inlined_function_outer_scope_p.  Thus, it tries to output the
minimal info dwarf2out.c needs to emit the desired debug information.

As with LTO all abstract inline instances get generated late for
early inlined functions I had to amend the hack for extern inline
functions to always output dies for decls that come their way
through dwarf2out_abstract_function.  And further down not crash
on a NULL DECL_INITIAL (when LTO decided to output the function
body in another LTRANS unit or if it does not get output at all).

Currently LTO-bootstrapping and testing on x86_64-unknown-linux-gnu.

Jason, are the dwarf2out bits ok with you?

I've sofar toyed with examples like

int x, y;
static inline int foo (int i) { y = i; return y; }
static inline int bar (int i) { x = i; return foo (x); }
int main ()
{
  int k = 0;
  int res = bar (k);
  return res;
}

and debug information with/without LTO is now reasonably the same
and I can set breakpoints on the inlined instances.

Thanks,
Richard.

2012-10-01  Richard Guenther  rguent...@suse.de

PR lto/47788
* tree-streamer-out.c (write_ts_block_tree_pointers): For
inlined functions outer scopes write the ultimate origin
as BLOCK_ABSTRACT_ORIGIN and BLOCK_SOURCE_LOCATION.
Do not stream the fragment chains.
(lto_input_ts_block_tree_pointers): Likewise.
* dwarf2out.c (gen_subprogram_die): Handle NULL DECL_INITIAL.
(dwarf2out_decl): Always output DECL_ABSTRACT function decls.

Index: gcc/tree-streamer-in.c
===
*** gcc/tree-streamer-in.c  (revision 191824)
--- gcc/tree-streamer-in.c  (working copy)
*** static void
*** 789,810 
  lto_input_ts_block_tree_pointers (struct lto_input_block *ib,
  struct data_in *data_in, tree expr)
  {
-   /* Do not stream BLOCK_SOURCE_LOCATION.  We cannot handle debug information
-  for early inlining so drop it on the floor instead of ICEing in
-  dwarf2out.c.  */
BLOCK_VARS (expr) = streamer_read_chain (ib, data_in);
  
-   /* Do not stream BLOCK_NONLOCALIZED_VARS.  We cannot handle debug 
information
-  for early inlining so drop it on the floor instead of ICEing in
-  dwarf2out.c.  */
- 
BLOCK_SUPERCONTEXT (expr) = stream_read_tree (ib, data_in);
  
!   /* Do not stream BLOCK_ABSTRACT_ORIGIN.  We cannot handle debug information
!  for early inlining so drop it on the floor instead of ICEing in
   dwarf2out.c.  */
!   BLOCK_FRAGMENT_ORIGIN (expr) = stream_read_tree (ib, data_in);
!   BLOCK_FRAGMENT_CHAIN (expr) = stream_read_tree (ib, data_in);
  
/* We re-compute BLOCK_SUBBLOCKS of our parent here instead
   of streaming it.  For non-BLOCK BLOCK_SUPERCONTEXTs we still
--- 789,810 
  lto_input_ts_block_tree_pointers (struct lto_input_block *ib,
  struct data_in *data_in, tree expr)
  {
BLOCK_VARS (expr) = streamer_read_chain (ib, data_in);
  
BLOCK_SUPERCONTEXT (expr) = stream_read_tree (ib, data_in);
  
!   /* Stream BLOCK_ABSTRACT_ORIGIN and BLOCK_SOURCE_LOCATION for
!  the limited cases we can handle - those that represent inlined
!  function scopes.  For the rest them on the floor instead of ICEing in
   dwarf2out.c.  */
!   BLOCK_ABSTRACT_ORIGIN (expr) = stream_read_tree (ib, data_in);
!   BLOCK_SOURCE_LOCATION (expr) = lto_input_location (ib, data_in);
!   /* Do not stream BLOCK_NONLOCALIZED_VARS.  We cannot handle debug 
information
!  for early inlined BLOCKs so drop it on the floor instead of ICEing in
!  dwarf2out.c.  */
! 
!   /* BLOCK_FRAGMENT_ORIGIN and BLOCK_FRAGMENT_CHAIN is not live at LTO
!  streaming time.  */
  
/* We re-compute BLOCK_SUBBLOCKS of our parent here instead
   of streaming it.  For non-BLOCK BLOCK_SUPERCONTEXTs we still
Index: gcc/tree-streamer-out.c
===
*** gcc/tree-streamer-out.c (revision 191824)
--- gcc/tree-streamer-out.c (working copy)
*** write_ts_exp_tree_pointers (struct outpu
*** 682,702 
  static void
  write_ts_block_tree_pointers (struct output_block *ob, tree expr, bool ref_p)
  {
-   /* Do not stream BLOCK_SOURCE_LOCATION.  We cannot handle debug information
-  for early inlining so drop it on the floor instead of ICEing in
-  dwarf2out.c.  */
streamer_write_chain (ob, BLOCK_VARS (expr), ref_p);
  
/* Do not stream BLOCK_NONLOCALIZED_VARS.  We cannot handle debug 
information
!  for early inlining so drop it on the floor 

Re: [RFC] Make vectorizer to skip loops with small iteration estimate

[Richard Guenther]

On Sun, 30 Sep 2012, Jan Hubicka wrote:

 Hi,
 the point of the following patch is to make vectorizer to not vectorize the
 following testcase with profile feedback:
 
 int a[1];
 int i=5;
 int k=2;
 int val;
 __attribute__ ((noinline,noclone))
 test()
 {
   int j;
   for(j=0;jk;j++)
 a[j]=val;
 }
 main()
 {
   while (i)
 {
   test ();
   i--;
 }
 }
 
 Here the compiler should work out that the second loop iterates 2 times at the
 average and thus it is not good candidate for vectorizing.
 
 In my first attempt I added the following:
 @@ -1474,6 +1478,18 @@ vect_analyze_loop_operations (loop_vec_i
return false;
  }
  
 +  if ((estimated_niter = estimated_stmt_executions_int (loop)) != -1
 +   (unsigned HOST_WIDE_INT) estimated_niter = th)
 +{
 +  if (vect_print_dump_info (REPORT_UNVECTORIZED_LOCATIONS))
 +fprintf (vect_dump, not vectorized: estimated iteration count too 
 small.);
 +  if (vect_print_dump_info (REPORT_DETAILS))
 +fprintf (vect_dump, not vectorized: estimated iteration count 
 smaller than 
 + user specified loop bound parameter or minimum 
 + profitable iterations (whichever is more conservative).);
 +  return false;
 +}
 +
 
 But to my surprise it does not help.  There are two things:
 
 1) the value of TH is bit low.  In a way the cost model works is that
it finds minimal niters where vectorized loop with all the setup costs
is cheaper than the vector loop with all the setup costs.  I.e.
 
   /* Calculate number of iterations required to make the vector version
  profitable, relative to the loop bodies only.  The following condition
  must hold true:
  SIC * niters + SOC  VIC * ((niters-PL_ITERS-EP_ITERS)/VF) + VOC(A)
  where
  SIC = scalar iteration cost, VIC = vector iteration cost,
  VOC = vector outside cost, VF = vectorization factor,
  PL_ITERS = prologue iterations, EP_ITERS= epilogue iterations
  SOC = scalar outside cost for run time cost model check.  */
 
 This value is used for both
 1) decision if number of iterations is too low (max iterations is known)
 2) decision on runtime whether we want to take the vectorized path
 or the scalar path.
 
 The vectoried loop looks like:
   k.1_10 = k;
   if (k.1_10  0)
   {
 pretmp_2 = val;
 niters.8_4 = (unsigned int) k.1_10;
 bnd.9_13 = niters.8_4  2;
 ratio_mult_vf.10_1 = bnd.9_13  2;
 _18 = niters.8_4 = 3;
 _19 = ratio_mult_vf.10_1 == 0;
 _20 = _19 | _18;
 if (_20 != 0)
   scalar loop
 else
   vector prologue
   }
 
  So the unvectorized cost is
  SIC * niters
 
  The vectorized path is
  SOC + VIC * ((niters-PL_ITERS-EP_ITERS)/VF) + VOC
  The scalar path of vectorizer loop is
  SIC * niters + SOC

Note that 'th' is used for the runtime profitability check which is
done at the time the setup cost has already been taken (yes, we
probably should make it more conservative but then guard the whole
set of loops by the check, not only the vectorized path).
See PR53355 for the general issue.

It makes sense to vectorize if
SIC * niters  SOC + VIC * ((niters-PL_ITERS-EP_ITERS)/VF) + VOC   (B)
That is in the optimal cse where we actually vectorize the overall
speed of vectorized loop including the runtime check is better.
 
It makes sense to take the vector loop if
SIC * niters  VIC * ((niters-PL_ITERS-EP_ITERS)/VF) + VOC (C)
Because the scalar loop is taken.
 
The attached patch implements the formula (C) and uses it to deterine the
decision based on number of iterations estimate (that is usually provided 
 by
the feedback)
 
As a reality check, I tried my testcase.
 
9: Cost model analysis:
  Vector inside of loop cost: 1
  Vector prologue cost: 7
  Vector epilogue cost: 2
  Scalar iteration cost: 1
  Scalar outside cost: 6
  Vector outside cost: 9
  prologue iterations: 0
  epilogue iterations: 2
  Calculated minimum iters for profitability: 4
 
9:   Profitability threshold = 3
 
9:   Profitability estimated iterations threshold = 20
 
This is overrated. The loop starts to be benefical at about 4 iterations in
reality.  I guess the values are kind of wrong.
 
Vector inside of loop cost and Scalar iteration cost seems to ignore the
fact that the loops do contain some control flow that should account at 
 least
one extra cycle.
 
Vector prologue cost seems bit overrated for one pack operation.
 
Of course this is very simple benchmark, in reality the vectorizatoin can 
 be
a lot more harmful by complicating more complex control flows.

So I guess we have two options
 1) go with the new formula and try to make cost model a bit more 
 realistic.
 2) stay with original formula that is quite close to 

Re: [PATCH] Do not mark pseudo-copies decomposable during first lower-subreg pass

[Ulrich Weigand]

   * gcc.dg/lower-subreg-1.c: Disable on arm-*-* targets.

I just noticed that the triple is incomplete; we're supposed to use
arm*-*-* instead of just arm-*-*.

Checked in the the following fix as obvious.

Bye,
Ulrich


2012-10-01  Ulrich Weigand  ulrich.weig...@linaro.org

* gcc.dg/lower-subreg-1.c: Disable on arm*-*-* targets.

Index: gcc/testsuite/gcc.dg/lower-subreg-1.c
===
*** gcc/testsuite/gcc.dg/lower-subreg-1.c   (revision 191805)
--- gcc/testsuite/gcc.dg/lower-subreg-1.c   (working copy)
***
*** 1,4 
! /* { dg-do compile { target { ! { mips64 || { arm-*-* ia64-*-* spu-*-* 
tilegx-*-* } } } } } */
  /* { dg-options -O -fdump-rtl-subreg1 } */
  /* { dg-skip-if  { { i?86-*-* x86_64-*-* }  x32 } { * } {  } } */
  /* { dg-require-effective-target ilp32 } */
--- 1,4 
! /* { dg-do compile { target { ! { mips64 || { arm*-*-* ia64-*-* spu-*-* 
tilegx-*-* } } } } } */
  /* { dg-options -O -fdump-rtl-subreg1 } */
  /* { dg-skip-if  { { i?86-*-* x86_64-*-* }  x32 } { * } {  } } */
  /* { dg-require-effective-target ilp32 } */



-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  ulrich.weig...@de.ibm.com

Re: [PATCH] Fix instability of -fschedule-insn for x86

[Igor Zamyatin]

We also plan to test these changes along with LRA

On Sun, Sep 30, 2012 at 4:33 PM, Uros Bizjak ubiz...@gmail.com wrote:
 On Tue, Sep 18, 2012 at 1:31 PM, Uros Bizjak ubiz...@gmail.com wrote:

 This patch aims to fix all stability issues related to using the first
 scheduler in gcc
 for x86 target (there several reported issues related to this problem).

 Main idea of this activity is mostly to provide user a possibility to
 safely turn on first scheduler for his codes. In some cases this could
 positively affect performance, especially for in-order Atom.

 Below is short description of proposed changes.

 2012-09-18  Yuri Rumyantsev  ysrum...@gmail.com

 * config/i386/i386.c (ix86_dep_by_shift_count_body) : Add
 check on reload_completed since it can be invoked before
 register allocation phase in 1st scheduler.
 (ia32_multipass_dfa_lookahead) : Do not use dfa_lookahead for 1st
 Scheduler to save compile time.
 (ix86_sched_reorder) : Do not perform ready list reordering for 1st
 Scheduler to save compile time.
 (insn_is_function_arg) : New function. Returns true if lhs of insn 
 is
 HW function argument register.
 (add_parameter_dependencies) : New function. Add output dependencies
 for chain of function adjacent arguments if only there is a move to
 likely spilled HW registers. Return first argument if at least one
 dependence was added or NULL otherwise.
 (avoid_func_arg_motion) : New function. Add output or anti 
 dependency
 from insn to first_arg to restrict code motion.
 (add_dependee_for_func_arg) : New function. Avoid cross block 
 motion of
 function argument through adding dependency from the first non-jump
 insn in bb.
 (ix86_dependencies_evaluation_hook) : New function. Hook for 
 schedule1:
 avoid motion of function arguments passed in passed in likely 
 spilled
 HW registers.
 (ix86_adjust_priority) : New function. Hook for schedule1: set 
 priority
 of moves from likely spilled HW registers to maximum to schedule 
 them
 as soon as possible.
 (ix86_sched_init_global): Do not perform multipass scheduling for 
 1st
 Scheduler to save compile time.

 I would kindly ask scheduler expert to review the patch from the
 scheduler functionality POV.

 I have received opinion from Vladimir from off-line discussion, quoted below:

 --quote--
 I think, it is ok.

   Switching off first cycle multipass scheduling is ok.  It is mostly
 useful when the order of insns issued on the same cycle is important
 (mostly VLIW or quasy-VLIW processors).

   Other solutions are necessary to decrease spills and avoid reload
 crash (can not find a register in a class) when the 1st insn
 scheduling is on.  I don't think it fully avoids possibility of the
 reload crashes but it takes into account most of cases resulting in
 the crashes and makes the crash possibility really negligible.
 Register pressure sensitive insn scheduling decreased the possibility.
  This patch will make it negligible.  And LRA will solve all the rest
 cases of the crashes.

   I don't like a bit absence in freedom of moving argument insns with
 likely spilled hard-regs between each other as they are chained in the
 original order but it is debatable because it still decreases the
 possibility of spills.

   In overall, the patch is ok for me.
 --/quote--

 Based on this opinion, the patch is OK for mainline, if there are no
 objections from other x86 maintainers in the next couple of days
 (48h). However, please watch for possible fallout from the patch,
 compile-time ICEs and performance problems. x86 and scheduler didn't
 play well together in the past, but your patch and (in the near
 future) LRA seems to fix all these problems.

 Thanks,
 Uros.

Re: RFC: LRA for x86/x86-64 [0/9]

[Steven Bosscher]

On Sat, Sep 29, 2012 at 10:26 PM, Steven Bosscher stevenb@gmail.com wrote:
  LRA create live ranges  : 175.30 (15%) usr   2.14 (13%) sys 177.44
 (15%) wall2761 kB ( 0%) ggc

I've tried to split this up a bit more:

process_bb_lives ~50%
create_start_finish_chains ~25%
remove_some_program_points_and_update_live_ranges ~25%

The latter two have a common structure with loops that look like this:

  for (i = FIRST_PSEUDO_REGISTER; i  max_regno; i++)
{
  for (r = lra_reg_info[i].live_ranges; r != NULL; r = r-next)

Perhaps it's possible to do some of the work of compress_live_ranges
during process_bb_lives, to create shorter live_ranges chains.

Also, maybe doing something else than a linked list of live_ranges
will help (unfortunately that's not a trivial change, it seems,
because the lra_live_range_t type is used everywhere and there are no
iterators or anything abstracted out like that -- just chain
walks...).

Still it does seem to me that a sorted VEC of lra_live_range objects
probably would speed things up. Question is of course how much... :-)

Ciao!
Steven

[Ada] Membership tests work with extended overflow checks

[Arnaud Charlet]

This patch implements membership tests in which the operands
can be out of range in extended overflow checkig modes.

The following is a test program:

 1. pragma Ada_2012;
 2. with Text_IO; use Text_IO;
 3. procedure Overflowm3 is
 4.subtype Int10 is Integer range 1 .. 5;
 5.subtype IntP is Integer with Predicate = Intp = 0;
 6.
 7.function r1
 8.  (a, b, c, d : Integer) return Boolean is
 9.begin
10.   return a + b + c + d in Integer'First .. Integer'Last
11. and then a + b + c + d in Integer
12. and then a + b + c + d in Intp
13. and then a + b + c + d not in Int10;
14.end;
15.function r2
16.  (a, b, c, d : Integer) return Boolean is
17.begin
18.   return a * b * c * d in Integer'First .. Integer'Last
19. and then a * b * c * d in Integer
20. and then a * b * c * d in Intp
21. and then a * b * c * d not in Int10;
22.end;
23.
24. begin
25.begin
26.   Put_Line
27. (r1 returns  
28.Boolean'Image
29.  (r1 (Integer'Last, Integer'Last,
30.   -Integer'Last, -Integer'Last)));
31.exception
32.   when Constraint_Error =
33.  Put_Line (r1 raises exception);
34.end;
35.
36.begin
37.   Put_Line
38. (r2 returns  
39.Boolean'Image
40.  (r2 (Integer'Last, Integer'Last,
41.   Integer'Last, 0)));
42.exception
43.   when Constraint_Error =
44.  Put_Line (r2 raises exception);
45.end;
46. end Overflowm3;

In CHECKED mode (-gnato1) we get:

r1 raises exception
r2 raises exception

since the first addition in r1 and the first multiplication
in r2 result in values outside the bounds of Integer'Base.

In MINIMIZED mode (-gnato2) we get:

r1 returns TRUE
r2 raises exception

since we can compute the addition result in Long_Long_Integer,
but the second multiplication yields a value outside this
range, so that causes an overflow.

In ELIMINATE mode (-gnato3) we get:

r1 returns TRUE
r2 returns TRUE

Because now we use Bignum arithmetic for the intermediate
multiplication results, and the final result is in range.

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

2012-10-01  Robert Dewar  de...@adacore.com

* checks.adb (Apply_Arithmetic_Overflow_Minimized_Eliminated):
Handle case of appearing in range in membership test.
* exp_ch4.adb (Expand_Membership_Minimize_Eliminate_Overflow):
New procedure (Expand_N_In): Use
Expand_Membership_Minimize_Eliminate_Overflow.
* rtsfind.ads: Add RE_Bignum_In_LLI_Range.
* s-bignum.ads, s-bignum.adb (Bignum_In_LLI_Range): New function.
* sinfo.ads, sinfo.adb (No_Minimize_Eliminate): New flag.

Index: sinfo.adb
===
--- sinfo.adb   (revision 191888)
+++ sinfo.adb   (working copy)
@@ -2235,6 +2235,15 @@
   return Flag13 (N);
end No_Initialization;
 
+   function No_Minimize_Eliminate
+  (N : Node_Id) return Boolean is
+   begin
+  pragma Assert (False
+or else NT (N).Nkind = N_In
+or else NT (N).Nkind = N_Not_In);
+  return Flag17 (N);
+   end No_Minimize_Eliminate;
+
function No_Truncation
   (N : Node_Id) return Boolean is
begin
@@ -5288,6 +5297,15 @@
   Set_Flag13 (N, Val);
end Set_No_Initialization;
 
+   procedure Set_No_Minimize_Eliminate
+  (N : Node_Id; Val : Boolean := True) is
+   begin
+  pragma Assert (False
+or else NT (N).Nkind = N_In
+or else NT (N).Nkind = N_Not_In);
+  Set_Flag17 (N, Val);
+   end Set_No_Minimize_Eliminate;
+
procedure Set_No_Truncation
   (N : Node_Id; Val : Boolean := True) is
begin
Index: sinfo.ads
===
--- sinfo.ads   (revision 191913)
+++ sinfo.ads   (working copy)
@@ -1545,6 +1545,11 @@
--should not be taken into account (needed for in place initialization
--with aggregates).
 
+   --  No_Minimize_Eliminate (Flag17-Sem)
+   --This flag is present in membership operator nodes (N_In/N_Not_In).
+   --It is used to indicate that processing for extended overflow checking
+   --modes is not required (this is used to prevent infinite recursion).
+
--  No_Truncation (Flag17-Sem)
--Present in N_Unchecked_Type_Conversion node. This flag has an effect
--only if the RM_Size of the source is greater than the RM_Size of the
@@ -3675,6 +3680,7 @@
   --  Left_Opnd (Node2)
   --  Right_Opnd (Node3)
   --  Alternatives (List4) (set to No_List if only one set alternative)
+  --  No_Minimize_Eliminate (Flag17)
   --  plus fields for expression
 
   --  N_Not_In
@@ -3682,6 +3688,7 @@
   --  

[Ada] Exponentiation works with extended overflow checks

[Arnaud Charlet]

This patch implements extended overflow checking modes
with the exonentiation operator.

The following is a test program:

 1. with Text_IO; use Text_IO;
 2. procedure Overflowm4 is
 3.function r1 (a, b : Integer) return Boolean is
 4.begin
 5.   return a ** 2 - b ** 2 = Integer'Last;
 6.end;
 7.function r2 (a, b : Integer) return Boolean is
 8.begin
 9.   return a ** 10 - b ** 10 in Integer;
10.end;
11. begin
12.begin
13.   Put_Line
14. (r1 returns  
15.  Boolean'Image (r1 (Integer'Last, Integer'Last)));
16.exception
17.   when Constraint_Error =
18.  Put_Line (r1 raises exception);
19.end;
20.
21.begin
22.   Put_Line
23. (r2 returns  
24.  Boolean'Image (r2 (Integer'Last, Integer'Last)));
25.exception
26.   when Constraint_Error =
27.  Put_Line (r2 raises exception);
28.end;
29. end Overflowm4;

In CHECKED mode (-gnato1) we get:

r1 raises exception
r2 raises exception

since the first exponentiation in both r1 and r2 result
in values outside the bounds of Integer'Base.

In MINIMIZED mode (-gnato2) we get:

r1 returns TRUE
r2 raises exception

since we can compute the exponentiation results in r1 in
Long_Long_Integer mode, but that's not true for r2.

In ELIMINATE mode (-gnato3) we get:

r1 returns TRUE
r2 returns TRUE

Because now we use Bignum arithmetic for the exponentiation
operations in r2.

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

2012-10-01  Robert Dewar  de...@adacore.com

* checks.adb (Minimize_Eliminate_Overflow_Checks): Changes
for exponentiation.
* exp_ch4.adb (Expand_N_Op_Expon): Changes for Minimize/Eliminate
overflow checks.
* s-bignum.adb (Compare): Fix bad precondition.

Index: checks.adb
===
--- checks.adb  (revision 191918)
+++ checks.adb  (working copy)
@@ -6548,7 +6548,7 @@
 
 when N_Op_Abs =
Lo := Uint_0;
-   Hi := UI_Max (UI_Abs (Rlo), UI_Abs (Rhi));
+   Hi := UI_Max (abs Rlo, abs Rhi);
 
 --  Addition
 
@@ -6564,8 +6564,80 @@
 --  Exponentiation
 
 when N_Op_Expon =
-   raise Program_Error;
 
+   --  Discard negative values for the exponent, since they will
+   --  simply result in an exception in any case.
+
+   if Rhi  0 then
+  Rhi := Uint_0;
+   elsif Rlo  0 then
+  Rlo := Uint_0;
+   end if;
+
+   --  Estimate number of bits in result before we go computing
+   --  giant useless bounds. Basically the number of bits in the
+   --  result is the number of bits in the base multiplied by the
+   --  value of the exponent. If this is big enough that the result
+   --  definitely won't fit in Long_Long_Integer, switch to bignum
+   --  mode immediately, and avoid computing giant bounds.
+
+   --  The comparison here is approximate, but conservative, it
+   --  only clicks on cases that are sure to exceed the bounds.
+
+   if Num_Bits (UI_Max (abs Llo, abs Lhi)) * Rhi + 1  100 then
+  Lo := No_Uint;
+  Hi := No_Uint;
+
+   --  If right operand is zero then result is 1
+
+   elsif Rhi = 0 then
+  Lo := Uint_1;
+  Hi := Uint_1;
+
+   else
+  --  High bound comes either from exponentiation of largest
+  --  positive value to largest exponent value, or from the
+  --  exponentiation of most negative value to an odd exponent.
+
+  declare
+ Hi1, Hi2 : Uint;
+
+  begin
+ if Lhi = 0 then
+Hi1 := Lhi ** Rhi;
+ else
+Hi1 := Uint_0;
+ end if;
+
+ if Llo  0 then
+if Rhi mod 2 = 0 then
+   Hi2 := Llo ** (Rhi - 1);
+else
+   Hi2 := Llo ** Rhi;
+end if;
+ else
+Hi2 := Uint_0;
+ end if;
+
+ Hi := UI_Max (Hi1, Hi2);
+  end;
+
+  --  Result can only be negative if base can be negative
+
+  if Llo  0 then
+ if UI_Mod (Rhi, 2) = 0 then
+Lo := Llo ** (Rhi - 1);
+ else
+Lo := Llo ** Rhi;
+ end if;
+
+  --  Otherwise low bound is minimium ** minimum
+
+  else

[Ada] Division/Rem/Mod work with extended overflow checks

[Arnaud Charlet]

This patch implements extended overflow checking modes
with the division, rem, and mod operators. This completes
the work on extended overflow checking.

The following is a test program:

 1. with Text_IO; use Text_IO;
 2. procedure Overflowm5 is
 3.function r1 (a, b, c : Integer)
 4.  return Integer is
 5.begin
 6.   return a / b - c;
 7.end;
 8.function r2 (a, b, c : Long_Long_Integer)
 9.  return Long_Long_Integer is
10.begin
11.   return a / b - c;
12.end;
13. begin
14.begin
15.   Put_Line
16. (r1 returns 
17.Integer'Image
18.(r1 (Integer'First, - 1, Integer'Last)));
19.exception
20.   when Constraint_Error =
21.  Put_Line (r1 raises exception);
22.end;
23.
24.begin
25.   Put_Line
26. (r2 returns 
27.Long_Long_Integer'Image
28.(r2 (Long_Long_Integer'First, -1,
29. Long_Long_Integer'Last)));
30.exception
31.   when Constraint_Error =
32.  Put_Line (r2 raises exception);
33.end;
34. end Overflowm5;

In CHECKED mode (-gnato1) we get:

r1 raises exception
r2 raises exception

since in both cases we are dividing the largest negative integer
by minus one, which generates a value one greater than the
largest positive value.

In MINIMIZED mode (-gnato2) we get:

r1 returns 1
r2 raises exception

since we can now compute the division and subtraction for r1
in Long_Long_Integer mode, but that's not true for r2.

In ELIMINATE mode (-gnato3) we get:

r1 returns 1
r2 returns 1

Because now we use Bignum arithmetic for the division and
subtraction operations in r2.

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

2012-10-01  Robert Dewar  de...@adacore.com

* checks.adb (Apply_Divide_Checks): New name for
Apply_Divide_Check (Minimize_Eliminate_Overflow_Checks):
Add code to handle division (and rem and mod) properly.
(Apply_Division_Check): New procedure (Apply_Divide_Checks):
Use Apply_Division_Check (Apply_Divide_Checks): Use
Apply_Arithmetic_Overflow_Minimized_Eliminated.
* checks.ads (Apply_Divide_Checks): New name for
Apply_Divide_Check, also add clearer documentation for this
routine and put in alfa order.
* exp_ch4.adb (Apply_Divide_Checks): New name for
Apply_Divide_Check.
* s-bignum.adb (To_Bignum): Handle largest negative integer
properly.
* sem.adb (Analyze): Handle overflow suppression correctly
(Analyze_List): Handle overflow suppression correctly
* sem_res.adb (Analyze_And_Resolve): Handle overflow suppression
correctly.

Index: checks.adb
===
--- checks.adb  (revision 191919)
+++ checks.adb  (working copy)
@@ -193,14 +193,6 @@
-- Local Subprograms --
---
 
-   procedure Apply_Float_Conversion_Check
- (Ck_Node: Node_Id;
-  Target_Typ : Entity_Id);
-   --  The checks on a conversion from a floating-point type to an integer
-   --  type are delicate. They have to be performed before conversion, they
-   --  have to raise an exception when the operand is a NaN, and rounding must
-   --  be taken into account to determine the safe bounds of the operand.
-
procedure Apply_Arithmetic_Overflow_Normal (N : Node_Id);
--  Used to apply arithmetic overflow checks for all cases except operators
--  on signed arithmetic types in Minimized/Eliminate case (for which we
@@ -211,6 +203,24 @@
--  checking mode is Minimized or Eliminated (and the Do_Overflow_Check flag
--  is known to be set) and we have an signed integer arithmetic op.
 
+   procedure Apply_Division_Check
+ (N   : Node_Id;
+  Rlo : Uint;
+  Rhi : Uint;
+  ROK : Boolean);
+   --  N is an N_Op_Div, N_Op_Rem, or N_Op_Mod node. This routine applies
+   --  division checks as required if the Do_Division_Check flag is set.
+   --  Rlo and Rhi give the possible range of the right operand, these values
+   --  can be referenced and trusted only if ROK is set True.
+
+   procedure Apply_Float_Conversion_Check
+ (Ck_Node: Node_Id;
+  Target_Typ : Entity_Id);
+   --  The checks on a conversion from a floating-point type to an integer
+   --  type are delicate. They have to be performed before conversion, they
+   --  have to raise an exception when the operand is a NaN, and rounding must
+   --  be taken into account to determine the safe bounds of the operand.
+
procedure Apply_Selected_Length_Checks
  (Ck_Node: Node_Id;
   Target_Typ : Entity_Id;
@@ -1641,52 +1651,69 @@
   Reason= CE_Discriminant_Check_Failed));
end Apply_Discriminant_Check;
 
-   
-   -- Apply_Divide_Check --
-   
+   

[Ada] Static predicate checks on type conversions

[Arnaud Charlet]

In Ada 2012, if a subtype has predicates, a predicate check must be applied to
the expression in a type conversion to the subtype. Furthermore, if the
expression is a scalar static constant, the predicate must be evluated at
compile-time, and the program must be rejected if the predicate is false.

Compiling

   gcc -c -gnat12 -gnata main.adb

must yield:

   main.adb:6:16: static expression fails static predicate check on T

---
procedure Main is
   subtype T is Integer
   with Static_Predicate = T = 10;
   V : T := 10;
begin
   V := 1000 / T (9);
end Main;

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

2012-10-01  Ed Schonberg  schonb...@adacore.com

* checks.adb (Apply_Predicate_Check): If the predicate is a
static one and the operand is static, evaluate the predicate at
compile time.
* sem_eval.ads, sem_eval.adb (Eval_Static_Predicate_Check): new
procedure, to evaluate a static predicate check whenever possible.
* sem_res.adb (Resolve_Type_Conversion): Apply predicate check
on the conversion if the target type has predicates.

Index: checks.adb
===
--- checks.adb  (revision 191920)
+++ checks.adb  (working copy)
@@ -2337,6 +2337,23 @@
  (Sloc (N), Reason = SE_Infinite_Recursion));
 
  else
+
+--  If the predicate is a static predicate and the operand is
+--  static, the predicate must be evaluated statically. If the
+--  evaluation fails this is a static constraint error.
+
+if Is_OK_Static_Expression (N) then
+   if  Present (Static_Predicate (Typ)) then
+  if Eval_Static_Predicate_Check (N, Typ) then
+ return;
+  else
+ Error_Msg_NE
+   (static expression fails static predicate check on,
+  N, Typ);
+  end if;
+   end if;
+end if;
+
 Insert_Action (N,
   Make_Predicate_Check (Typ, Duplicate_Subexpr (N)));
  end if;
Index: sem_res.adb
===
--- sem_res.adb (revision 191920)
+++ sem_res.adb (working copy)
@@ -9713,6 +9713,22 @@
 end if;
  end;
   end if;
+
+  --  Ada 2012: if target type has predicates, the result requires a
+  --  predicate check. If the context is a call to another predicate
+  --  check we must prevent infinite recursion.
+
+  if Has_Predicates (Target_Typ) then
+ if Nkind (Parent (N)) = N_Function_Call
+   and then Present (Name (Parent (N)))
+   and then Has_Predicates (Entity (Name (Parent (N
+ then
+null;
+
+ else
+Apply_Predicate_Check (N, Target_Typ);
+ end if;
+  end if;
end Resolve_Type_Conversion;
 
--
Index: sem_eval.adb
===
--- sem_eval.adb(revision 191895)
+++ sem_eval.adb(working copy)
@@ -3249,6 +3249,37 @@
   end if;
end Eval_Slice;
 
+   -
+   -- Eval_Static_Predicate_Check --
+   -
+
+   function Eval_Static_Predicate_Check
+ (N   : Node_Id;
+  Typ : Entity_Id) return Boolean
+   is
+  Loc  : constant Source_Ptr := Sloc (N);
+  Pred : constant List_Id := Static_Predicate (Typ);
+  Test : Node_Id;
+   begin
+  if No (Pred) then
+ return True;
+  end if;
+
+  --  The static predicate is a list of alternatives in the proper format
+  --  for an Ada 2012 membership test. If the argument is a literal, the
+  --  membership test can be evaluated statically. The caller transforms
+  --  a result of False into a static contraint error.
+
+  Test := Make_In (Loc,
+ Left_Opnd= New_Copy_Tree (N),
+ Right_Opnd   = Empty,
+ Alternatives = Pred);
+  Analyze_And_Resolve (Test, Standard_Boolean);
+
+  return Nkind (Test) = N_Identifier
+and then Entity (Test) = Standard_True;
+   end Eval_Static_Predicate_Check;
+
-
-- Eval_String_Literal --
-
Index: sem_eval.ads
===
--- sem_eval.ads(revision 191888)
+++ sem_eval.ads(working copy)
@@ -317,6 +317,11 @@
procedure Eval_Unary_Op   (N : Node_Id);
procedure Eval_Unchecked_Conversion   (N : Node_Id);
 
+   function Eval_Static_Predicate_Check
+ (N  : Node_Id;
+ Typ : Entity_Id) return Boolean;
+   --  Evaluate a static predicate check applied to a scalar literal.
+
procedure Fold_Str (N : Node_Id; Val : String_Id; Static : Boolean);
--  Rewrite N with a new N_String_Literal node as the result of the compile
--  time 

[Ada] Complain when actual Symbol is present in any dimension output call

[Arnaud Charlet]

This patch prevents the user to provide parameter Symbol (reserved for compiler
use only) in any dimension output call.


-- Source --


with System.Dim.Mks;use System.Dim.Mks;
with System.Dim.Mks_IO; use System.Dim.Mks_IO;

procedure Main is
begin
   Put (8.0**(1 / 3) * m , 1, 2, 0, error);
end Main;

-
-- Compilation  Execution --
-

$ gcc -c -gnat12 main.adb
main.adb:6:37: Symbol parameter should not be provided
main.adb:6:37: reserved for compiler use only

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

2012-10-01  Vincent Pucci  pu...@adacore.com

* sem_dim.adb (Has_Symbols): Complain if parameter Symbol has been
provided by the user in the dimension output call.

Index: sem_dim.adb
===
--- sem_dim.adb (revision 191911)
+++ sem_dim.adb (working copy)
@@ -2703,7 +2703,8 @@
   -
 
   function Has_Symbols return Boolean is
- Actual : Node_Id;
+ Actual : Node_Id;
+ Actual_Str : Node_Id;
 
   begin
  Actual := First (Actuals);
@@ -2711,16 +2712,49 @@
  --  Look for a symbols parameter association in the list of actuals
 
  while Present (Actual) loop
-if Nkind (Actual) = N_Parameter_Association
+--  Positional parameter association case when the actual is a
+--  string literal.
+
+if Nkind (Actual) = N_String_Literal then
+   Actual_Str := Actual;
+
+--  Named parameter association case when the selector name is
+--  Symbol.
+
+elsif Nkind (Actual) = N_Parameter_Association
   and then Chars (Selector_Name (Actual)) = Name_Symbol
 then
+   Actual_Str := Explicit_Actual_Parameter (Actual);
+
+--  Ignore all other cases
+
+else
+   Actual_Str := Empty;
+end if;
+
+if Present (Actual_Str) then
--  Return True if the actual comes from source or if the string
--  of symbols doesn't have the default value (i.e. it is ).
 
-   return Comes_From_Source (Actual)
- or else
-   String_Length
- (Strval (Explicit_Actual_Parameter (Actual))) /= 0;
+   if Comes_From_Source (Actual)
+ or else String_Length (Strval (Actual_Str)) /= 0
+   then
+  --  Complain only if the actual comes from source or if it
+  --  hasn't been fully analyzed yet.
+
+  if Comes_From_Source (Actual)
+or else not Analyzed (Actual)
+  then
+ Error_Msg_N (Symbol parameter should not be provided,
+  Actual);
+ Error_Msg_N (\reserved for compiler use only, Actual);
+  end if;
+
+  return True;
+
+   else
+  return False;
+   end if;
 end if;
 
 Next (Actual);

[PATCH] Fix -frounding-math builtins

[Richard Guenther]

I noticed that we attach the no-vops attribute to -frounding-math
math functions.  That's bogus as can be seen from the testcase

int fesetround(int);
double asinh(double x);

double foo (double x, int b)
{
  double y = 0.0, z;
  if (b)
y = asinh (x);
  fesetround (0x400 /*FE_DOWNWARD*/);
  z = asinh (x);
  return y + z;
}

where PRE rightfully so removes a seeming partial redundancy by
inserting a asinh call into the else block.  That's because
it exactly does _not_ get to see the rounding mode clobbering
fesetround call as asinh does not have a virtual operand.

Fixed as follows.

Bootstrapped and tested on x86_64-unknown-linux-gnu.

Richard.

2012-10-01  Richard Guenther  rguent...@suse.de

* builtins.def (ATTR_MATHFN_FPROUNDING): Do not use no-vops
with -frounding-math.
* builtin-attrs.def (ATTR_PURE_NOTHROW_NOVOPS_LIST): Remove.
(ATTR_PURE_NOTHROW_NOVOPS_LEAF_LIST): Likewise.

Index: gcc/builtins.def
===
*** gcc/builtins.def(revision 191917)
--- gcc/builtins.def(working copy)
*** along with GCC; see the file COPYING3.
*** 163,169 
 memory.  */
  #undef ATTR_MATHFN_FPROUNDING
  #define ATTR_MATHFN_FPROUNDING (flag_rounding_math ? \
!   ATTR_PURE_NOTHROW_NOVOPS_LEAF_LIST : ATTR_CONST_NOTHROW_LEAF_LIST)
  
  /* Define an attribute list for math functions that are normally
 impure because some of them may write into global memory for
--- 163,169 
 memory.  */
  #undef ATTR_MATHFN_FPROUNDING
  #define ATTR_MATHFN_FPROUNDING (flag_rounding_math ? \
!   ATTR_PURE_NOTHROW_LEAF_LIST : ATTR_CONST_NOTHROW_LEAF_LIST)
  
  /* Define an attribute list for math functions that are normally
 impure because some of them may write into global memory for
Index: gcc/builtin-attrs.def
===
*** gcc/builtin-attrs.def   (revision 191917)
--- gcc/builtin-attrs.def   (working copy)
*** DEF_ATTR_TREE_LIST (ATTR_PURE_NOTHROW_LI
*** 127,136 
ATTR_NULL, ATTR_NOTHROW_LIST)
  DEF_ATTR_TREE_LIST (ATTR_PURE_NOTHROW_LEAF_LIST, ATTR_PURE,   \
ATTR_NULL, ATTR_NOTHROW_LEAF_LIST)
- DEF_ATTR_TREE_LIST (ATTR_PURE_NOTHROW_NOVOPS_LIST, ATTR_NOVOPS,   \
-   ATTR_NULL, ATTR_PURE_NOTHROW_LIST)
- DEF_ATTR_TREE_LIST (ATTR_PURE_NOTHROW_NOVOPS_LEAF_LIST, ATTR_NOVOPS,\
-   ATTR_NULL, ATTR_PURE_NOTHROW_LEAF_LIST)
  DEF_ATTR_TREE_LIST (ATTR_NORETURN_NOTHROW_LIST, ATTR_NORETURN,\
ATTR_NULL, ATTR_NOTHROW_LIST)
  DEF_ATTR_TREE_LIST (ATTR_NORETURN_NOTHROW_LEAF_LIST, ATTR_NORETURN,\
--- 127,132 

Re: [PATCH] Add option for dumping to stderr (issue6190057)

[Sharad Singhai]

I am sorry, I didn't enable all the languages. Will fix the fortran
test breakage shortly.

Thanks,
Sharad
Sharad


On Mon, Oct 1, 2012 at 4:50 AM, H.J. Lu hjl.to...@gmail.com wrote:
 On Sun, Sep 30, 2012 at 11:36 PM, Sharad Singhai sing...@google.com wrote:
 Resend to gcc-patches

 I have addressed the comments by fixing all the minor issues,
 bootstrapped and tested on x86_64. I did the recommended reshuffling
 by moving non-tree code from tree-dump.c into a new file dumpfile.c.

 I committed two successive revisions
 r191883 Main patch with the dump infrastructure changes. However, I
 accidentally left out a new file, dumpfile.c.
 r191884 Added dumpfile.c, and did the renaming of dump_* functions
 from gimple_pretty_print.[ch].

 As things stand right now, r191883 is broken because of the missing
 file 'dumpfile.c', which the very next commit fixes. Anyone who got
 broken revision r191883, please svn update. I am really very sorry
 about that.

 I have a couple more minor patches which deal with renaming; I plan to
 address those later.


 It caused:

 FAIL: gcc.dg/tree-ssa/gen-vect-11.c (test for excess errors)
 FAIL: gcc.dg/tree-ssa/gen-vect-11.c scan-tree-dump-times vect
 vectorized 1 loops 1
 FAIL: gcc.dg/tree-ssa/gen-vect-11a.c (test for excess errors)
 FAIL: gcc.dg/tree-ssa/gen-vect-11a.c scan-tree-dump-times vect
 vectorized 1 loops 1
 FAIL: gcc.dg/tree-ssa/gen-vect-11b.c (test for excess errors)
 FAIL: gcc.dg/tree-ssa/gen-vect-11b.c scan-tree-dump-times vect
 vectorized 0 loops 1
 FAIL: gcc.dg/tree-ssa/gen-vect-11c.c (test for excess errors)
 FAIL: gcc.dg/tree-ssa/gen-vect-11c.c scan-tree-dump-times vect
 vectorized 0 loops 1
 FAIL: gcc.dg/tree-ssa/gen-vect-2.c (test for excess errors)
 FAIL: gcc.dg/tree-ssa/gen-vect-2.c scan-tree-dump-times vect
 vectorized 1 loops 1
 FAIL: gcc.dg/tree-ssa/gen-vect-25.c (test for excess errors)
 FAIL: gcc.dg/tree-ssa/gen-vect-25.c scan-tree-dump-times vect
 vectorized 2 loops 1
 FAIL: gcc.dg/tree-ssa/gen-vect-26.c (test for excess errors)
 FAIL: gcc.dg/tree-ssa/gen-vect-26.c scan-tree-dump-times vect
 Alignment of access forced using peeling 1
 FAIL: gcc.dg/tree-ssa/gen-vect-26.c scan-tree-dump-times vect
 vectorized 1 loops 1
 FAIL: gcc.dg/tree-ssa/gen-vect-28.c (test for excess errors)
 FAIL: gcc.dg/tree-ssa/gen-vect-28.c scan-tree-dump-times vect
 Alignment of access forced using peeling 1
 FAIL: gcc.dg/tree-ssa/gen-vect-28.c scan-tree-dump-times vect
 vectorized 1 loops 1
 FAIL: gcc.dg/tree-ssa/gen-vect-32.c (test for excess errors)
 FAIL: gcc.dg/tree-ssa/gen-vect-32.c scan-tree-dump-times vect
 vectorized 1 loops 1
 FAIL: gfortran.dg/vect/O3-pr36119.f90 (test for excess errors)
 FAIL: gfortran.dg/vect/O3-pr39595.f (test for excess errors)
 FAIL: gfortran.dg/vect/Ofast-pr50414.f90 (test for excess errors)
 FAIL: gfortran.dg/vect/cost-model-pr34445.f (test for excess errors)
 FAIL: gfortran.dg/vect/cost-model-pr34445a.f (test for excess errors)
 FAIL: gfortran.dg/vect/fast-math-pr38968.f90 (test for excess errors)
 FAIL: gfortran.dg/vect/fast-math-pr38968.f90 scan-tree-dump vect
 vectorized 1 loops
 FAIL: gfortran.dg/vect/fast-math-real8-pr40801.f90 (test for excess errors)
 FAIL: gfortran.dg/vect/fast-math-real8-pr40801.f90 (test for excess errors)
 FAIL: gfortran.dg/vect/fast-math-vect-8.f90 (test for excess errors)
 FAIL: gfortran.dg/vect/fast-math-vect-8.f90 scan-tree-dump-times vect
 vectorized 1 loops 1
 FAIL: gfortran.dg/vect/no-fre-no-copy-prop-O3-pr51704.f90 (test for
 excess errors)
 FAIL: gfortran.dg/vect/no-vfa-pr32377.f90 (test for excess errors)
 FAIL: gfortran.dg/vect/no-vfa-pr32377.f90 scan-tree-dump-times vect
 vectorized 2 loops 1
 FAIL: gfortran.dg/vect/no-vfa-pr32457.f90 (test for excess errors)
 FAIL: gfortran.dg/vect/no-vfa-pr32457.f90 scan-tree-dump-times vect
 vectorized 0 loops 1
 FAIL: gfortran.dg/vect/pr19049.f90  -O   scan-tree-dump-times vect
 complicated access pattern 1
 FAIL: gfortran.dg/vect/pr19049.f90  -O  (test for excess errors)
 FAIL: gfortran.dg/vect/pr32377.f90  -O   scan-tree-dump-times vect
 vectorized 2 loops 1
 FAIL: gfortran.dg/vect/pr32377.f90  -O  (test for excess errors)
 FAIL: gfortran.dg/vect/pr32380.f  -O   scan-tree-dump-times vect
 vectorized 6 loops 1
 FAIL: gfortran.dg/vect/pr32380.f  -O  (test for excess errors)
 FAIL: gfortran.dg/vect/pr33301.f  -O  (test for excess errors)
 FAIL: gfortran.dg/vect/pr50178.f90  -O  (test for excess errors)
 FAIL: gfortran.dg/vect/pr50412.f90  -O  (test for excess errors)
 FAIL: gfortran.dg/vect/pr51058-2.f90  -O  (test for excess errors)
 FAIL: gfortran.dg/vect/pr51058.f90  -O  (test for excess errors)
 FAIL: gfortran.dg/vect/pr51285.f90  -O  (test for excess errors)
 FAIL: gfortran.dg/vect/vect-1.f90  -O   scan-tree-dump-times vect
 vectorized 3 loops 1
 FAIL: gfortran.dg/vect/vect-1.f90  -O  (test for excess errors)
 FAIL: gfortran.dg/vect/vect-2.f90  -O   scan-tree-dump-times vect
 Alignment of access forced using peeling 3
 FAIL: gfortran.dg/vect/vect-2.f90  -O   

Re: [PATCH] Add option for dumping to stderr (issue6190057)

[H.J. Lu]

On Mon, Oct 1, 2012 at 6:49 AM, Sharad Singhai sing...@google.com wrote:
 I am sorry, I didn't enable all the languages. Will fix the fortran
 test breakage shortly.

It is not just Fortran.  There are some failures in C testcases.

 Thanks,
 Sharad
 Sharad


 On Mon, Oct 1, 2012 at 4:50 AM, H.J. Lu hjl.to...@gmail.com wrote:
 On Sun, Sep 30, 2012 at 11:36 PM, Sharad Singhai sing...@google.com wrote:
 Resend to gcc-patches

 I have addressed the comments by fixing all the minor issues,
 bootstrapped and tested on x86_64. I did the recommended reshuffling
 by moving non-tree code from tree-dump.c into a new file dumpfile.c.

 I committed two successive revisions
 r191883 Main patch with the dump infrastructure changes. However, I
 accidentally left out a new file, dumpfile.c.
 r191884 Added dumpfile.c, and did the renaming of dump_* functions
 from gimple_pretty_print.[ch].

 As things stand right now, r191883 is broken because of the missing
 file 'dumpfile.c', which the very next commit fixes. Anyone who got
 broken revision r191883, please svn update. I am really very sorry
 about that.

 I have a couple more minor patches which deal with renaming; I plan to
 address those later.


 It caused:

 FAIL: gcc.dg/tree-ssa/gen-vect-11.c (test for excess errors)
 FAIL: gcc.dg/tree-ssa/gen-vect-11.c scan-tree-dump-times vect
 vectorized 1 loops 1
 FAIL: gcc.dg/tree-ssa/gen-vect-11a.c (test for excess errors)
 FAIL: gcc.dg/tree-ssa/gen-vect-11a.c scan-tree-dump-times vect
 vectorized 1 loops 1
 FAIL: gcc.dg/tree-ssa/gen-vect-11b.c (test for excess errors)
 FAIL: gcc.dg/tree-ssa/gen-vect-11b.c scan-tree-dump-times vect
 vectorized 0 loops 1
 FAIL: gcc.dg/tree-ssa/gen-vect-11c.c (test for excess errors)
 FAIL: gcc.dg/tree-ssa/gen-vect-11c.c scan-tree-dump-times vect
 vectorized 0 loops 1
 FAIL: gcc.dg/tree-ssa/gen-vect-2.c (test for excess errors)
 FAIL: gcc.dg/tree-ssa/gen-vect-2.c scan-tree-dump-times vect
 vectorized 1 loops 1
 FAIL: gcc.dg/tree-ssa/gen-vect-25.c (test for excess errors)
 FAIL: gcc.dg/tree-ssa/gen-vect-25.c scan-tree-dump-times vect
 vectorized 2 loops 1
 FAIL: gcc.dg/tree-ssa/gen-vect-26.c (test for excess errors)
 FAIL: gcc.dg/tree-ssa/gen-vect-26.c scan-tree-dump-times vect
 Alignment of access forced using peeling 1
 FAIL: gcc.dg/tree-ssa/gen-vect-26.c scan-tree-dump-times vect
 vectorized 1 loops 1
 FAIL: gcc.dg/tree-ssa/gen-vect-28.c (test for excess errors)
 FAIL: gcc.dg/tree-ssa/gen-vect-28.c scan-tree-dump-times vect
 Alignment of access forced using peeling 1
 FAIL: gcc.dg/tree-ssa/gen-vect-28.c scan-tree-dump-times vect
 vectorized 1 loops 1
 FAIL: gcc.dg/tree-ssa/gen-vect-32.c (test for excess errors)
 FAIL: gcc.dg/tree-ssa/gen-vect-32.c scan-tree-dump-times vect
 vectorized 1 loops 1
 FAIL: gfortran.dg/vect/O3-pr36119.f90 (test for excess errors)
 FAIL: gfortran.dg/vect/O3-pr39595.f (test for excess errors)
 FAIL: gfortran.dg/vect/Ofast-pr50414.f90 (test for excess errors)
 FAIL: gfortran.dg/vect/cost-model-pr34445.f (test for excess errors)
 FAIL: gfortran.dg/vect/cost-model-pr34445a.f (test for excess errors)
 FAIL: gfortran.dg/vect/fast-math-pr38968.f90 (test for excess errors)
 FAIL: gfortran.dg/vect/fast-math-pr38968.f90 scan-tree-dump vect
 vectorized 1 loops
 FAIL: gfortran.dg/vect/fast-math-real8-pr40801.f90 (test for excess errors)
 FAIL: gfortran.dg/vect/fast-math-real8-pr40801.f90 (test for excess errors)
 FAIL: gfortran.dg/vect/fast-math-vect-8.f90 (test for excess errors)
 FAIL: gfortran.dg/vect/fast-math-vect-8.f90 scan-tree-dump-times vect
 vectorized 1 loops 1
 FAIL: gfortran.dg/vect/no-fre-no-copy-prop-O3-pr51704.f90 (test for
 excess errors)
 FAIL: gfortran.dg/vect/no-vfa-pr32377.f90 (test for excess errors)
 FAIL: gfortran.dg/vect/no-vfa-pr32377.f90 scan-tree-dump-times vect
 vectorized 2 loops 1
 FAIL: gfortran.dg/vect/no-vfa-pr32457.f90 (test for excess errors)
 FAIL: gfortran.dg/vect/no-vfa-pr32457.f90 scan-tree-dump-times vect
 vectorized 0 loops 1
 FAIL: gfortran.dg/vect/pr19049.f90  -O   scan-tree-dump-times vect
 complicated access pattern 1
 FAIL: gfortran.dg/vect/pr19049.f90  -O  (test for excess errors)
 FAIL: gfortran.dg/vect/pr32377.f90  -O   scan-tree-dump-times vect
 vectorized 2 loops 1
 FAIL: gfortran.dg/vect/pr32377.f90  -O  (test for excess errors)
 FAIL: gfortran.dg/vect/pr32380.f  -O   scan-tree-dump-times vect
 vectorized 6 loops 1
 FAIL: gfortran.dg/vect/pr32380.f  -O  (test for excess errors)
 FAIL: gfortran.dg/vect/pr33301.f  -O  (test for excess errors)
 FAIL: gfortran.dg/vect/pr50178.f90  -O  (test for excess errors)
 FAIL: gfortran.dg/vect/pr50412.f90  -O  (test for excess errors)
 FAIL: gfortran.dg/vect/pr51058-2.f90  -O  (test for excess errors)
 FAIL: gfortran.dg/vect/pr51058.f90  -O  (test for excess errors)
 FAIL: gfortran.dg/vect/pr51285.f90  -O  (test for excess errors)
 FAIL: gfortran.dg/vect/vect-1.f90  -O   scan-tree-dump-times vect
 vectorized 3 loops 1
 FAIL: gfortran.dg/vect/vect-1.f90  -O  (test for excess errors)
 FAIL: 

Re: [PATCH] Add option for dumping to stderr (issue6190057)

[Richard Guenther]

On Mon, Oct 1, 2012 at 3:55 PM, Sharad Singhai sing...@google.com wrote:
 On Mon, Oct 1, 2012 at 6:52 AM, H.J. Lu hjl.to...@gmail.com wrote:
 On Mon, Oct 1, 2012 at 6:49 AM, Sharad Singhai sing...@google.com wrote:
 I am sorry, I didn't enable all the languages. Will fix the fortran
 test breakage shortly.

 It is not just Fortran.  There are some failures in C testcases.

 I checked and those files looked like generator files for Fortran
 tests and thus were not exercised in my configuration. I am really
 sorry about that. I am fixing it.

As I said, you should not enable/disable anything special but
configure with all default languages enabled (no --enable-languages)
and do toplevel make -k check, preferably also excercising
multilibs with RUNTESTFLAGS=--target_board=unix/\{,-m32\}

Richard.

 UNSUPPORTED: gcc.dg/tree-ssa/gen-vect-11.c
 UNSUPPORTED: gcc.dg/tree-ssa/gen-vect-11a.c
 UNSUPPORTED: gcc.dg/tree-ssa/gen-vect-11b.c
 UNSUPPORTED: gcc.dg/tree-ssa/gen-vect-11c.c
 UNSUPPORTED: gcc.dg/tree-ssa/gen-vect-2.c
 UNSUPPORTED: gcc.dg/tree-ssa/gen-vect-25.c
 UNSUPPORTED: gcc.dg/tree-ssa/gen-vect-26.c
 UNSUPPORTED: gcc.dg/tree-ssa/gen-vect-28.c
 UNSUPPORTED: gcc.dg/tree-ssa/gen-vect-32.c

 Thanks,
 Sharad


 Thanks,
 Sharad
 Sharad


 On Mon, Oct 1, 2012 at 4:50 AM, H.J. Lu hjl.to...@gmail.com wrote:
 On Sun, Sep 30, 2012 at 11:36 PM, Sharad Singhai sing...@google.com 
 wrote:
 Resend to gcc-patches

 I have addressed the comments by fixing all the minor issues,
 bootstrapped and tested on x86_64. I did the recommended reshuffling
 by moving non-tree code from tree-dump.c into a new file dumpfile.c.

 I committed two successive revisions
 r191883 Main patch with the dump infrastructure changes. However, I
 accidentally left out a new file, dumpfile.c.
 r191884 Added dumpfile.c, and did the renaming of dump_* functions
 from gimple_pretty_print.[ch].

 As things stand right now, r191883 is broken because of the missing
 file 'dumpfile.c', which the very next commit fixes. Anyone who got
 broken revision r191883, please svn update. I am really very sorry
 about that.

 I have a couple more minor patches which deal with renaming; I plan to
 address those later.


 It caused:

 FAIL: gcc.dg/tree-ssa/gen-vect-11.c (test for excess errors)
 FAIL: gcc.dg/tree-ssa/gen-vect-11.c scan-tree-dump-times vect
 vectorized 1 loops 1
 FAIL: gcc.dg/tree-ssa/gen-vect-11a.c (test for excess errors)
 FAIL: gcc.dg/tree-ssa/gen-vect-11a.c scan-tree-dump-times vect
 vectorized 1 loops 1
 FAIL: gcc.dg/tree-ssa/gen-vect-11b.c (test for excess errors)
 FAIL: gcc.dg/tree-ssa/gen-vect-11b.c scan-tree-dump-times vect
 vectorized 0 loops 1
 FAIL: gcc.dg/tree-ssa/gen-vect-11c.c (test for excess errors)
 FAIL: gcc.dg/tree-ssa/gen-vect-11c.c scan-tree-dump-times vect
 vectorized 0 loops 1
 FAIL: gcc.dg/tree-ssa/gen-vect-2.c (test for excess errors)
 FAIL: gcc.dg/tree-ssa/gen-vect-2.c scan-tree-dump-times vect
 vectorized 1 loops 1
 FAIL: gcc.dg/tree-ssa/gen-vect-25.c (test for excess errors)
 FAIL: gcc.dg/tree-ssa/gen-vect-25.c scan-tree-dump-times vect
 vectorized 2 loops 1
 FAIL: gcc.dg/tree-ssa/gen-vect-26.c (test for excess errors)
 FAIL: gcc.dg/tree-ssa/gen-vect-26.c scan-tree-dump-times vect
 Alignment of access forced using peeling 1
 FAIL: gcc.dg/tree-ssa/gen-vect-26.c scan-tree-dump-times vect
 vectorized 1 loops 1
 FAIL: gcc.dg/tree-ssa/gen-vect-28.c (test for excess errors)
 FAIL: gcc.dg/tree-ssa/gen-vect-28.c scan-tree-dump-times vect
 Alignment of access forced using peeling 1
 FAIL: gcc.dg/tree-ssa/gen-vect-28.c scan-tree-dump-times vect
 vectorized 1 loops 1
 FAIL: gcc.dg/tree-ssa/gen-vect-32.c (test for excess errors)
 FAIL: gcc.dg/tree-ssa/gen-vect-32.c scan-tree-dump-times vect
 vectorized 1 loops 1
 FAIL: gfortran.dg/vect/O3-pr36119.f90 (test for excess errors)
 FAIL: gfortran.dg/vect/O3-pr39595.f (test for excess errors)
 FAIL: gfortran.dg/vect/Ofast-pr50414.f90 (test for excess errors)
 FAIL: gfortran.dg/vect/cost-model-pr34445.f (test for excess errors)
 FAIL: gfortran.dg/vect/cost-model-pr34445a.f (test for excess errors)
 FAIL: gfortran.dg/vect/fast-math-pr38968.f90 (test for excess errors)
 FAIL: gfortran.dg/vect/fast-math-pr38968.f90 scan-tree-dump vect
 vectorized 1 loops
 FAIL: gfortran.dg/vect/fast-math-real8-pr40801.f90 (test for excess errors)
 FAIL: gfortran.dg/vect/fast-math-real8-pr40801.f90 (test for excess errors)
 FAIL: gfortran.dg/vect/fast-math-vect-8.f90 (test for excess errors)
 FAIL: gfortran.dg/vect/fast-math-vect-8.f90 scan-tree-dump-times vect
 vectorized 1 loops 1
 FAIL: gfortran.dg/vect/no-fre-no-copy-prop-O3-pr51704.f90 (test for
 excess errors)
 FAIL: gfortran.dg/vect/no-vfa-pr32377.f90 (test for excess errors)
 FAIL: gfortran.dg/vect/no-vfa-pr32377.f90 scan-tree-dump-times vect
 vectorized 2 loops 1
 FAIL: gfortran.dg/vect/no-vfa-pr32457.f90 (test for excess errors)
 FAIL: gfortran.dg/vect/no-vfa-pr32457.f90 scan-tree-dump-times vect
 vectorized 0 loops 1
 FAIL: gfortran.dg/vect/pr19049.f90  

Re: [PATCH] Add option for dumping to stderr (issue6190057)

[Sharad Singhai]

Okay, I am retesting without any special configs and with multilibs as
you suggested.

Thanks,
Sharad

On Mon, Oct 1, 2012 at 7:00 AM, Richard Guenther
richard.guent...@gmail.com wrote:
 On Mon, Oct 1, 2012 at 3:55 PM, Sharad Singhai sing...@google.com wrote:
 On Mon, Oct 1, 2012 at 6:52 AM, H.J. Lu hjl.to...@gmail.com wrote:
 On Mon, Oct 1, 2012 at 6:49 AM, Sharad Singhai sing...@google.com wrote:
 I am sorry, I didn't enable all the languages. Will fix the fortran
 test breakage shortly.

 It is not just Fortran.  There are some failures in C testcases.

 I checked and those files looked like generator files for Fortran
 tests and thus were not exercised in my configuration. I am really
 sorry about that. I am fixing it.

 As I said, you should not enable/disable anything special but
 configure with all default languages enabled (no --enable-languages)
 and do toplevel make -k check, preferably also excercising
 multilibs with RUNTESTFLAGS=--target_board=unix/\{,-m32\}

 Richard.

 UNSUPPORTED: gcc.dg/tree-ssa/gen-vect-11.c
 UNSUPPORTED: gcc.dg/tree-ssa/gen-vect-11a.c
 UNSUPPORTED: gcc.dg/tree-ssa/gen-vect-11b.c
 UNSUPPORTED: gcc.dg/tree-ssa/gen-vect-11c.c
 UNSUPPORTED: gcc.dg/tree-ssa/gen-vect-2.c
 UNSUPPORTED: gcc.dg/tree-ssa/gen-vect-25.c
 UNSUPPORTED: gcc.dg/tree-ssa/gen-vect-26.c
 UNSUPPORTED: gcc.dg/tree-ssa/gen-vect-28.c
 UNSUPPORTED: gcc.dg/tree-ssa/gen-vect-32.c

 Thanks,
 Sharad


 Thanks,
 Sharad
 Sharad


 On Mon, Oct 1, 2012 at 4:50 AM, H.J. Lu hjl.to...@gmail.com wrote:
 On Sun, Sep 30, 2012 at 11:36 PM, Sharad Singhai sing...@google.com 
 wrote:
 Resend to gcc-patches

 I have addressed the comments by fixing all the minor issues,
 bootstrapped and tested on x86_64. I did the recommended reshuffling
 by moving non-tree code from tree-dump.c into a new file dumpfile.c.

 I committed two successive revisions
 r191883 Main patch with the dump infrastructure changes. However, I
 accidentally left out a new file, dumpfile.c.
 r191884 Added dumpfile.c, and did the renaming of dump_* functions
 from gimple_pretty_print.[ch].

 As things stand right now, r191883 is broken because of the missing
 file 'dumpfile.c', which the very next commit fixes. Anyone who got
 broken revision r191883, please svn update. I am really very sorry
 about that.

 I have a couple more minor patches which deal with renaming; I plan to
 address those later.


 It caused:

 FAIL: gcc.dg/tree-ssa/gen-vect-11.c (test for excess errors)
 FAIL: gcc.dg/tree-ssa/gen-vect-11.c scan-tree-dump-times vect
 vectorized 1 loops 1
 FAIL: gcc.dg/tree-ssa/gen-vect-11a.c (test for excess errors)
 FAIL: gcc.dg/tree-ssa/gen-vect-11a.c scan-tree-dump-times vect
 vectorized 1 loops 1
 FAIL: gcc.dg/tree-ssa/gen-vect-11b.c (test for excess errors)
 FAIL: gcc.dg/tree-ssa/gen-vect-11b.c scan-tree-dump-times vect
 vectorized 0 loops 1
 FAIL: gcc.dg/tree-ssa/gen-vect-11c.c (test for excess errors)
 FAIL: gcc.dg/tree-ssa/gen-vect-11c.c scan-tree-dump-times vect
 vectorized 0 loops 1
 FAIL: gcc.dg/tree-ssa/gen-vect-2.c (test for excess errors)
 FAIL: gcc.dg/tree-ssa/gen-vect-2.c scan-tree-dump-times vect
 vectorized 1 loops 1
 FAIL: gcc.dg/tree-ssa/gen-vect-25.c (test for excess errors)
 FAIL: gcc.dg/tree-ssa/gen-vect-25.c scan-tree-dump-times vect
 vectorized 2 loops 1
 FAIL: gcc.dg/tree-ssa/gen-vect-26.c (test for excess errors)
 FAIL: gcc.dg/tree-ssa/gen-vect-26.c scan-tree-dump-times vect
 Alignment of access forced using peeling 1
 FAIL: gcc.dg/tree-ssa/gen-vect-26.c scan-tree-dump-times vect
 vectorized 1 loops 1
 FAIL: gcc.dg/tree-ssa/gen-vect-28.c (test for excess errors)
 FAIL: gcc.dg/tree-ssa/gen-vect-28.c scan-tree-dump-times vect
 Alignment of access forced using peeling 1
 FAIL: gcc.dg/tree-ssa/gen-vect-28.c scan-tree-dump-times vect
 vectorized 1 loops 1
 FAIL: gcc.dg/tree-ssa/gen-vect-32.c (test for excess errors)
 FAIL: gcc.dg/tree-ssa/gen-vect-32.c scan-tree-dump-times vect
 vectorized 1 loops 1
 FAIL: gfortran.dg/vect/O3-pr36119.f90 (test for excess errors)
 FAIL: gfortran.dg/vect/O3-pr39595.f (test for excess errors)
 FAIL: gfortran.dg/vect/Ofast-pr50414.f90 (test for excess errors)
 FAIL: gfortran.dg/vect/cost-model-pr34445.f (test for excess errors)
 FAIL: gfortran.dg/vect/cost-model-pr34445a.f (test for excess errors)
 FAIL: gfortran.dg/vect/fast-math-pr38968.f90 (test for excess errors)
 FAIL: gfortran.dg/vect/fast-math-pr38968.f90 scan-tree-dump vect
 vectorized 1 loops
 FAIL: gfortran.dg/vect/fast-math-real8-pr40801.f90 (test for excess 
 errors)
 FAIL: gfortran.dg/vect/fast-math-real8-pr40801.f90 (test for excess 
 errors)
 FAIL: gfortran.dg/vect/fast-math-vect-8.f90 (test for excess errors)
 FAIL: gfortran.dg/vect/fast-math-vect-8.f90 scan-tree-dump-times vect
 vectorized 1 loops 1
 FAIL: gfortran.dg/vect/no-fre-no-copy-prop-O3-pr51704.f90 (test for
 excess errors)
 FAIL: gfortran.dg/vect/no-vfa-pr32377.f90 (test for excess errors)
 FAIL: gfortran.dg/vect/no-vfa-pr32377.f90 scan-tree-dump-times vect
 vectorized 2 loops 1
 

Second ping: Re: Add a configure option to disable system header canonicalizations (issue6495088)

[Simon Baldwin]

Ping, again.


On 21 September 2012 12:45, Simon Baldwin sim...@google.com wrote:

 Ping.

 http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00459.html

 Full text of previous message and context at URL above.  No comments
 or code changes since.  Patch description left below for convenience.

 
  Add flags to disable system header canonicalizations.
 
  Libcpp may canonicalize system header paths with lrealpath() for 
  diagnostics,
  dependency output, and similar.  If gcc is held in a symlink farm the
  canonicalized paths may be meaningless to users, and will also conflict with
  build frameworks that (for example) disallow absolute paths to header files.
 
  This change adds -f[no-]canonical-system-headers to the gcc command line, 
  and
  a configure option --[en/dis]able-canonical-system-headers to set default
  behaviour, allowing the user to select whether or not to implement r186991.
  Default is enabled.  See also PR c++/52974.
 
  Tested for regressions with bootstrap builds of C and C++, both with and
  without configure --disable-canonical-system-headers.

 --
 Google UK Limited | Registered Office: Belgrave House, 76 Buckingham
 Palace Road, London SW1W 9TQ | Registered in England Number: 3977902




--
Google UK Limited | Registered Office: Belgrave House, 76 Buckingham
Palace Road, London SW1W 9TQ | Registered in England Number: 3977902

[Patch] Fix PR53397

[venkataramanan.kumar]

Hi, 

The below patch fixes the FFT/Scimark regression caused by useless prefetch
generation.

This fix tries to make prefetch less aggressive by prefetching arrays in the
inner loop, when the step is invariant in the entire loop nest.

GCC currently tries to prefetch invariant steps when they are in the inner
loop. But does not check if the step is variant in outer loops.

In the scimark FFT case, the trip count of the inner loop varies by a non
constant step, which is invariant in the inner loop. 
But the step variable is varying in outer loop. This makes
inner loop trip count small (at run time varies sometimes as small as 1
iteration) 

Prefetching ahead x iteration when the inner loop trip count is smaller than x
leads to useless prefetches. 

Flag used: -O3 -march=amdfam10 

Before 
**  **
** SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark **
** for details. (Results can be submitted to p...@nist.gov) **
**  **
Using   2.00 seconds min time per kenel.
Composite Score:  550.50
FFT Mflops:38.66(N=1024)
SOR Mflops:   617.61(100 x 100)
MonteCarlo: Mflops:   173.74
Sparse matmult  Mflops:   675.63(N=1000, nz=5000)
LU  Mflops:  1246.88(M=100, N=100)


After 
**  **
** SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark **
** for details. (Results can be submitted to p...@nist.gov) **
**  **
Using   2.00 seconds min time per kenel.
Composite Score:  639.20
FFT Mflops:   479.19(N=1024)
SOR Mflops:   617.61(100 x 100)
MonteCarlo: Mflops:   173.18
Sparse matmult  Mflops:   679.13(N=1000, nz=5000)
LU  Mflops:  1246.88(M=100, N=100)

GCC regression make check -k passes with x86_64-unknown-linux-gnu
New tests that PASS:

gcc.dg/pr53397-1.c scan-assembler prefetcht0
gcc.dg/pr53397-1.c scan-tree-dump aprefetch Issued prefetch
gcc.dg/pr53397-1.c (test for excess errors)
gcc.dg/pr53397-2.c scan-tree-dump aprefetch loop variant step
gcc.dg/pr53397-2.c scan-tree-dump aprefetch Not prefetching
gcc.dg/pr53397-2.c (test for excess errors)


Checked CPU2006 and polyhedron on latest AMD processor, no regressions noted.

Ok to commit in trunk?

regards,
Venkat

gcc/ChangeLog
+2012-10-01  Venkataramanan Kumar  venkataramanan.ku...@amd.com
+
+   * tree-ssa-loop-prefetch.c (gather_memory_references_ref):$
+   Perform non constant step prefetching in inner loop, only $
+   when it is invariant in the entire loop nest.  $
+   * testsuite/gcc.dg/pr53397-1.c: New test case $
+   Checks we are prefecthing for loop invariant steps$
+   * testsuite/gcc.dg/pr53397-2.c: New test case$
+   Checks we are not prefecthing for loop variant steps
+


Index: gcc/testsuite/gcc.dg/pr53397-1.c
===
--- gcc/testsuite/gcc.dg/pr53397-1.c(revision 0)
+++ gcc/testsuite/gcc.dg/pr53397-1.c(revision 0)
@@ -0,0 +1,28 @@
+/* Prefetching when the step is loop invariant.  */
+
+/* { dg-do compile } */
+/* { dg-options -O3 -fprefetch-loop-arrays -fdump-tree-aprefetch-details 
--param min-insn-to-prefetch-ratio=3 --param simultaneous-prefetches=10 
-fdump-tree-aprefetch-details } */
+
+
+double data[16384];
+void prefetch_when_non_constant_step_is_invariant(int step, int n)
+{
+ int a;
+ int b;
+ for (a = 1; a  step; a++) {
+for (b = 0; b  n; b += 2 * step) {
+
+  int i = 2*(b + a);
+  int j = 2*(b + a + step);
+
+
+  data[j]   = data[i];
+  data[j+1] = data[i+1];
+}
+ }
+}
+
+/* { dg-final { scan-tree-dump Issued prefetch aprefetch } } */
+/* { dg-final { scan-assembler prefetcht0 } } */
+
+/* { dg-final { cleanup-tree-dump aprefetch } } */
Index: gcc/testsuite/gcc.dg/pr53397-2.c
===
--- gcc/testsuite/gcc.dg/pr53397-2.c(revision 0)
+++ gcc/testsuite/gcc.dg/pr53397-2.c(revision 0)
@@ -0,0 +1,29 @@
+/* Not prefetching when the step is loop variant.  */
+
+/* { dg-do compile } */
+/* { dg-options -O3 -fprefetch-loop-arrays -fdump-tree-aprefetch-details 
--param min-insn-to-prefetch-ratio=3 --param simultaneous-prefetches=10 
-fdump-tree-aprefetch-details } */
+
+
+double data[16384];
+void donot_prefetch_when_non_constant_step_is_variant(int step, int n)
+{ 
+ int a;
+ int b;
+ for (a = 1; a  step; a++,step*=2) {
+for (b = 0; b  n; b += 2 * step) {
+
+  int i = 2*(b + a);
+  int j = 2*(b + a + step);
+
+
+  data[j]   = data[i];
+  data[j+1] = data[i+1];
+}
+ } 
+}
+
+/* { dg-final { scan-tree-dump Not prefetching aprefetch } } */
+/* { dg-final { scan-tree-dump loop variant step aprefetch } } 

Re: [PATCH, i386]: Implement atomic_fetch_sub

[Andrew MacLeod]

On 08/30/2012 05:33 PM, Richard Henderson wrote:

On 08/23/2012 08:59 AM, Andrew MacLeod wrote:

2012-08-23  Andrew MacLeod  amacl...@redhat.com

gcc
PR target/54087
* optabs.c (expand_atomic_fetch_op_no_fallback): New.  Factored code
from expand_atomic_fetch_op.
(expand_atomic_fetch_op):  iTry atomic_{add|sub} operations in terms of
the other one if direct opcode fails.

testsuite
* gcc.dg/pr54087.c:  New testcase for atomic_sub - atomic_add when
atomic_sub fails.

Ok.


Oops, approved but never checked in.Just did so after a new 
bootstrap/test cycle with no issues.


Andrew

Re: [patch, mips] Patch for new mips triplet - mips-mti-elf

[Steve Ellcey]

On Sun, 2012-09-30 at 19:53 +0100, Richard Sandiford wrote:

 Sorry for only noticing now, but this produced:
 
 ERROR: gcc.target/mips/pr37362.c  -O0 : syntax error in target selector 
 target ! mips*-sde-elf mips*-mti-elf for  dg-do 2 compile { target { ! 
 mips*-sde-elf mips*-mti-elf } } 
 ...
 
 We need another set of braces.  Tested on mipsisa64-elf and applied.
 
 Richard

Thanks for fixing this, I am not sure why I didn't notice it in my
testing.

Steve Ellcey
sell...@mips.com

Re: Tweak IRA checks for singleton register classes

[Vladimir Makarov]

On 12-09-30 2:21 PM, Richard Sandiford wrote:

IRA has code to check whether there is only a single acceptable register
for a given operand.  This code uses conditions like:

   ira_class_hard_regs_num[cl] != 0
(ira_class_hard_regs_num[cl] = ira_reg_class_max_nregs[cl][mode])

i.e. the number of registers needed to store the mode is =
the number of alloctable registers in the class.  Then:

   ira_class_hard_regs[cl][0]

gives the register in question.

MIPS has a slightly strange situation in which HI can only be allocated
alongside LO; it can't be allocated independently.  At the moment,
HI and LO have their own register classes (MD0_REG and MD1_REG,
with the mapping depending on endianness) and MD_REGS is used when both
HI and LO are required.  There is also ACC_REGS, which is equivalent to
MD_REGS when the DSP ASE is not being used.  MD_REGS and ACC_REGS are
already mapped to constraints.

Having MD0_REG and MD1_REG leads to some confusing costs and makes
HI and LO irregular WRT the DSP ASE accumulator registers.  I've been
experimenting with patches to remove these classes and just have MD_REGS.
I wanted to get to a situtation where this change has no effect on cc1 .ii
files for -mno-dsp; the patch below is one of those needed to get to that
stage.

MD_REGS has only one SImode register.  As describe above, the same goes
for ACC_REGS unless the DSP ASE is being used.  However, both classes
fail the check above because HI (which doesn't accept SImode) is also
allocatable.  That is, the classes have two allocatable registers,
but only one of them can be used for SImode.

The patch below adds a new array for tracking which class/mode
combinations specify a single register, and for recording which
register that is.  The net effect will be the same on almost all
targets.

I deliberately didn't change:

  for (p2 = reg_class_subclasses[cl2][0];
   *p2 != LIM_REG_CLASSES; p2++)
if (ira_class_hard_regs_num[*p2]  0
 (ira_reg_class_max_nregs[*p2][mode]
= ira_class_hard_regs_num[*p2]))
  cost = MAX (cost, ira_register_move_cost[mode][cl1][*p2]);

  for (p1 = reg_class_subclasses[cl1][0];
   *p1 != LIM_REG_CLASSES; p1++)
if (ira_class_hard_regs_num[*p1]  0
 (ira_reg_class_max_nregs[*p1][mode]
= ira_class_hard_regs_num[*p1]))
  cost = MAX (cost, ira_register_move_cost[mode][*p1][cl2]);

from ira_init_register_move_cost because that had more effect
than I was expecting and wasn't needed for the MIPS patch.
It could be done as a follow-up if I ever find time...

I checked that this produced no difference in assembly output for
a set of x86_64 gcc .ii files (tested with -O2 -march=native on gcc20).
Also tested on x86_64-linux-gnu (including -m32) and mipsisa64-elf.
OK to install?
It is OK for me, Richard.  Although it was hard to me understand 
correctness of the following changes.


Thanks for the patch.

Index: gcc/ira-lives.c
===
--- gcc/ira-lives.c 2012-09-30 12:56:14.344185269 +0100
+++ gcc/ira-lives.c 2012-09-30 17:45:14.962463976 +0100
@@ -849,9 +849,10 @@ single_reg_class (const char *constraint
  next_cl = (c == 'r'
 ? GENERAL_REGS
 : REG_CLASS_FROM_CONSTRAINT (c, constraints));
- if ((cl != NO_REGS  next_cl != cl)
- || (ira_class_hard_regs_num[next_cl]
-  ira_reg_class_max_nregs[next_cl][GET_MODE (op)]))
+ if (cl == NO_REGS
+ ? ira_class_singleton[next_cl][GET_MODE (op)]  0
+ : (ira_class_singleton[cl][GET_MODE (op)]
+!= ira_class_singleton[next_cl][GET_MODE (op)]))
  
  	return NO_REGS;

  cl = next_cl;
  break;
@@ -861,10 +862,10 @@ single_reg_class (const char *constraint
  next_cl
= single_reg_class (recog_data.constraints[c - '0'],
recog_data.operand[c - '0'], NULL_RTX);
- if ((cl != NO_REGS  next_cl != cl)
- || next_cl == NO_REGS
- || (ira_class_hard_regs_num[next_cl]
-  ira_reg_class_max_nregs[next_cl][GET_MODE (op)]))
+ if (cl == NO_REGS
+ ? ira_class_singleton[next_cl][GET_MODE (op)]  0
+ : (ira_class_singleton[cl][GET_MODE (op)]
+!= ira_class_singleton[next_cl][GET_MODE (op)]))
return NO_REGS;
  cl = next_cl;
  break;

Re: [PATCH, i386]: Implement atomic_fetch_sub

[Paolo Bonzini]

Il 03/08/2012 17:08, Richard Henderson ha scritto:
 On 2012-08-03 08:01, Uros Bizjak wrote:
 On Fri, Aug 3, 2012 at 4:40 PM, Richard Henderson r...@redhat.com wrote:
 On 2012-08-03 01:51, Uros Bizjak wrote:
 The same reasoning goes for dynamic negation: for neg %eax,%eax value
 0x8000 stays the same, but we have changed (x)sub to an (x)add in
 the code stream.

 So?  Did you think the xadd will trap?

 No, but can we ignore the fact that we changed xsub -0x8000, mem
 to xadd -0x08000, mem?
 
 Yes, since it'll have the same effect on the bits.

In fact we can even use this trick for xxor...

Paolo

Re: RFC: LRA for x86/x86-64 [0/9]

[Vladimir Makarov]

On 12-10-01 6:30 AM, Bernd Schmidt wrote:

On 10/01/2012 12:14 PM, Jakub Jelinek wrote:

On Mon, Oct 01, 2012 at 12:01:36PM +0200, Steven Bosscher wrote:

I would also agree if it were not for the fact that IRA is already a
scalability bottle-neck and that has been known for a long time, too.
I have no confidence at all that if LRA goes in now, these scalability
problems will be solved in stage3 or at any next release cycle. It's
always the same thing with GCC: Once a patch is in, everyone moves on
to the next fancy new thing dropping the not-quite-broken but also
not-quite-working things on the floor.

If we open a P1 bug for it for 4.8, then it will need to be resolved some
way before branching.  I think Vlad is committed to bugfixing LRA, after
all the intent is for 4.9 to enable it on more (all?) targets, and all the
bugfixing and scalability work on LRA is needed for that anyway.

Why can't this be done on the branch? We've made the mistake of rushing
things into mainline too early a few times before, we should have
learned by now. And adding more half transitions is not something we
really want either.

I should clearly express that the transition will be not happen for 
short time because of the task complexity.  I believe that lra will 
coexist with reload for 1-2 releases.  I only ported LRA for 9 major 
targets.  The transition completion will be dependent on secondary 
target maintainers too because I alone can not do porting LRA for all 
supported targets.  It was discussed with a lot of people on 2012 GNU 
Tools Cauldron.  Maintenance of LRA on the branch is a big burden, even 
x86-64 is sometimes broken after merge with the trunk.


When I proposed merge LRA to gcc4.8, I had in mind that:
  o moving most changes from LRA branch will help LRA maintenance on 
the branch and I'll have more time to work on other targets and problems.
  o the earlier we start the transition, the better it will be for LRA 
because LRA on the trunk will have more feedback and better testing.


I've chosen x86/x86-64 for this because I am confident in this port.  On 
majority of tests, it generates faster, smaller code (even for these two 
extreme tests it generates 15% smaller code) for less time.  IMO, the 
slow compilation of the extreme tests are much less important than what 
I've just mentioned.


But because I got clear objections from at least two people and no clear 
support for the LRA inclusion (there were just no objections to include 
it), I will not insists on LRA merge now.


I believe in the importance of this work as LLVM catches GCC on RA front 
by implementing a new RA for LLVM3.0.  I believe we should get rid off 
reload as outdated, hard to maintain, and preventing implementation of 
new RA optimizations.


In any case submitting the patches was a good thing to do because I got 
a lot of feedback.  I still appreciate any comments on the patches.

Re: [RFC] Make vectorizer to skip loops with small iteration estimate

[Jan Hubicka]

  
   So the unvectorized cost is
   SIC * niters
  
   The vectorized path is
   SOC + VIC * ((niters-PL_ITERS-EP_ITERS)/VF) + VOC
   The scalar path of vectorizer loop is
   SIC * niters + SOC
 
 Note that 'th' is used for the runtime profitability check which is
 done at the time the setup cost has already been taken (yes, we

Yes, I understand that.
 probably should make it more conservative but then guard the whole
 set of loops by the check, not only the vectorized path).
 See PR53355 for the general issue.

Yep, we may reduce the cost of SOC by outputting early guard for non-vectorized
path better than we do now. However...
 Of course this is very simple benchmark, in reality the vectorizatoin 
  can be
 a lot more harmful by complicating more complex control flows.
 
 So I guess we have two options
  1) go with the new formula and try to make cost model a bit more 
  realistic.
  2) stay with original formula that is quite close to reality, but I 
  think
 more by an accident.
 
 I think we need to improve it as whole, thus I'd prefer 2).

... I do not see why.
Even if we make the check cheaper we will only distribute part of SOC to vector
prologues/epilogues.

Still I think the formula is wrong, I.e. accounting SOC where it should not.

The cost of scalar path without vectorization is 
  niters * SIC
while with vectorization we have scalar path
  niters * SIC + SOC
and vector path
  SOC + VIC * ((niters-PL_ITERS-EP_ITERS)/VF) + VOC

So SOC cancels out in the runtime check.
I still think we need two formulas - one determining if vectorization is
profitable, other specifying the threshold for scalar path at runtime (that
will generally give lower values).
  2) Even when loop iterates 2 times, it is estimated to 4 iterations by
 estimated_stmt_executions_int with the profile feedback.
 The reason is loop_ch pass.  Given a rolled loop with exit probability
 30%, proceeds by duplicating the header with original probabilities.
 This makes the loop to be executed with 60% probability.  Because the
 loop body counts remain the same (and they should), the expected number
 of iterations increase by the decrease of entry edge to the header.
  
 I wonder what to do about this.  Obviously without path profiling
 loop_ch can not really do a good job.  We can artifically make
 header to suceed more likely, that is the reality, but that requires
 non-trivial loop profile updating.
  
 We can also simply record the iteration bound into loop structure 
 and ignore that the profile is not realistic
 
 But we don't preserve loop structure from header copying ...

From what time we keep loop structure? In general I would like to eventualy
drop value histograms to loop structure specifying number of iterations with
profile feedback.
 
 Finally we can duplicate loop headers before profilng.  I implemented
 that via early_ch pass executed only with profile generation or feedback.
 I guess it makes sense to do, even if it breaks the assumption that
 we should do strictly -Os generation on paths where
 
 Well, there are CH cases that do not increase code size and I doubt
 that loop header copying is generally bad for -Os ... we are not
 good at handling non-copied loop headers.

There is comment saying 
  /* Loop header copying usually increases size of the code.  This used not to
 be true, since quite often it is possible to verify that the condition is
 satisfied in the first iteration and therefore to eliminate it.  Jump
 threading handles these cases now.  */
  if (optimize_loop_for_size_p (loop))
return false;

I am not sure how much backing it has. Schedule loop_ch as part of early passes
just after profile pass makes optimize_loop_for_size_p to return true 
even for functions that are later found cold by profile feedback.  I do not see
that being big issue.

I tested enabling loop_ch in early passes with -fprofile-feedback and it is SPEC
neutral.  Given that it improves loop count estimates, I would still like 
mainline
doing that.  I do not like these quite important estimates to be wrong most of 
time.

 
 Btw, I added a similar check in vect_analyze_loop_operations:
 
   if ((LOOP_VINFO_NITERS_KNOWN_P (loop_vinfo)
 (LOOP_VINFO_INT_NITERS (loop_vinfo)  vectorization_factor))
   || ((max_niter = max_stmt_executions_int (loop)) != -1
(unsigned HOST_WIDE_INT) max_niter  vectorization_factor))
 {
   if (dump_kind_p (MSG_MISSED_OPTIMIZATION))
 dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
  not vectorized: iteration count too small.);
   if (dump_kind_p (MSG_MISSED_OPTIMIZATION))
 dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
  not vectorized: iteration count smaller than 
  vectorization factor.);
   return false;
 }
 
 maybe you simply 

Re: [PATCH] Add option for dumping to stderr (issue6190057)

[Michael Meissner]

Your change on September 30th, breaks the powerpc port because the
REPORT_DETAILS value in the enumeration is no longer there, and the
rs6000_density_test function was using that.  Please in the future, when you
are making global changes, grep for uses of enum values in all of the machine
dependent directories so we can avoid breakage like this.

-- 
Michael Meissner, IBM
5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA
meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899

Re: [PATCH] Add option for dumping to stderr (issue6190057)

[Michael Meissner]

On Mon, Oct 01, 2012 at 02:02:26PM -0400, Michael Meissner wrote:
 Your change on September 30th, breaks the powerpc port because the
 REPORT_DETAILS value in the enumeration is no longer there, and the
 rs6000_density_test function was using that.  Please in the future, when you
 are making global changes, grep for uses of enum values in all of the machine
 dependent directories so we can avoid breakage like this.

Also, in looking at the changes, given we are already up to 28 TDF_ flags, I
would recommend immediately adding a new type that is the TDF flagword type.
Thus it will be a lot simpler when we add 4 more TDF flags and have to change
the type from int to HOST_WIDE_INT.

-- 
Michael Meissner, IBM
5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA
meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899

Re: [patch, libfortran] Fix PR 54736, memory corruption with GFORTRAN_CONVERT_UNIT

[Thomas Koenig]

Hello world,

the previous version of the patch has an issue that Shane pointed
out in the PR.  This version should work; at least it survived
all the test cases I could come up with.

Regression-tested (again).  OK for trunk?  Also for 4.6 and 4.7?

Thomas

2012-10-01  Thomas König  tkoe...@gcc.gnu.org

PR libfortran/54736
* runtime/environ.c (search_unit):  Correct logic
for binary search.
(mark_single):  Fix index errors.

Index: runtime/environ.c
===
--- runtime/environ.c	(Revision 191857)
+++ runtime/environ.c	(Arbeitskopie)
@@ -459,21 +459,35 @@ search_unit (int unit, int *ip)
 {
   int low, high, mid;
 
-  low = -1;
-  high = n_elist;
-  while (high - low  1)
+  if (n_elist == 0)
 {
+  *ip = 0;
+  return 0;
+}
+
+  low = 0;
+  high = n_elist - 1;
+
+  do 
+{
   mid = (low + high) / 2;
-  if (unit = elist[mid].unit)
-	high = mid;
+  if (unit == elist[mid].unit)
+	{
+	  *ip = mid;
+	  return 1;
+	}
+  else if (unit  elist[mid].unit)
+	low = mid + 1;
   else
-	low = mid;
-}
-  *ip = high;
-  if (elist[high].unit == unit)
-return 1;
+	high = mid - 1;
+} while (low = high);
+
+  if (unit  elist[mid].unit)
+*ip = mid + 1;
   else
-return 0;
+*ip = mid;
+
+  return 0;
 }
 
 /* This matches a keyword.  If it is found, return the token supplied,
@@ -588,13 +602,13 @@ mark_single (int unit)
 }
   if (search_unit (unit, i))
 {
-  elist[unit].conv = endian;
+  elist[i].conv = endian;
 }
   else
 {
-  for (j=n_elist; j=i; j--)
+  for (j=n_elist-1; j=i; j--)
 	elist[j+1] = elist[j];
-
+
   n_elist += 1;
   elist[i].unit = unit;
   elist[i].conv = endian;

Re: [PATCH] Add option for dumping to stderr (issue6190057)

[Gabriel Dos Reis]

On Mon, Oct 1, 2012 at 1:27 PM, Michael Meissner
meiss...@linux.vnet.ibm.com wrote:
 On Mon, Oct 01, 2012 at 02:02:26PM -0400, Michael Meissner wrote:
 Your change on September 30th, breaks the powerpc port because the
 REPORT_DETAILS value in the enumeration is no longer there, and the
 rs6000_density_test function was using that.  Please in the future, when you
 are making global changes, grep for uses of enum values in all of the machine
 dependent directories so we can avoid breakage like this.

 Also, in looking at the changes, given we are already up to 28 TDF_ flags, I
 would recommend immediately adding a new type that is the TDF flagword type.
 Thus it will be a lot simpler when we add 4 more TDF flags and have to change
 the type from int to HOST_WIDE_INT.

Agreed that we need an abstraction here.
-- Gaby

Re: RFC: LRA for x86/x86-64 [4/9]

[Richard Sandiford]

Thanks a lot for doing this.  When you finally get to the stage of
rm reload.c reload1.c, please do it in a screen session and save
the log for posterity.

Vladimir Makarov vmaka...@redhat.com writes:
 +/* Return register bank of given hard regno for the current target.  */
 +DEFHOOK
 +(register_bank,
 + A target hook which returns the register bank number to which the\
 +  register @var{hard_regno} belongs to.  The smaller the number, the\
 +  more preferable the hard register usage (when all other conditions are\
 +  the same).  This hook can be used to prefer some hard register over\
 +  others in LRA.  For example, some x86-64 register usage needs\
 +  additional prefix which makes instructions longer.  The hook can\
 +  return bigger bank number for such registers make them less favorable\
 +  and as result making the generated code smaller.\
 +  \
 +  The default version of this target hook returns always zero.,
 + int, (int),
 + default_register_bank)

This is a horribly bikeshed-level comment, sorry, but I wonder if
something like register_priority would be better.  Register classes
are in some ways an extension of register banks, so it wasn't obvious
from the name why we needed both.

 +/* Return true if maximal address displacement can be different.  */
 +DEFHOOK
 +(different_addr_displacement_p,
 + A target hook which returns true if an address with the same structure\
 +  can have different maximal legitimate displacement.  For example, the\
 +  displacement can depend on memory mode or on operand combinations in\
 +  the insn.\
 +  \
 +  The default version of this target hook returns always false.,
 + bool, (void),
 + default_different_addr_displacement_p)

If I read the patch correctly, this is only used in:

+   if (lra_reg_spill_p || targetm.different_addr_displacement_p ())
+ lra_set_used_insn_alternative (insn, -1);

and so we keep the current alternative when neither spill_class_mode
nor different_addr_displacement_p is defined.  How many targets on the
LRA branch are like that?  I would have expected most targets with limited
address displacements would have to return true for the above hook,
because multiword loads and stores typically have to be split into word
loads and stores.  Same goes for strict-alignment targets, where wider
modes often have slightly lower maximal displacements.

E.g. for MIPS, SImode loads and stores have a displacement range of
[-32768, 32764], but DImode loads and stores only accept [-32768, 32760].
So the maximal displacement depends on mode, even though the instruction set
is pretty regular.

Targets with full address-size displacements can use the default false return,
but it looks like the x86 port defines spill_class_mode instead, so AIUI
the value isn't really tested on Core i7.  What's the impact of that compared
to the other x86 targets that don't set X86_TUNE_GENERAL_REGS_SSE_SPILL?
Is LRA just quicker for them, or will it make different decisions
(compared to Core i7) even for non-SSE insns?

 +/* Determine class of registers which could be used for spilled
 +   pseudos instead of memory.  */
 +DEFHOOK
 +(spill_class,
 + This hook defines a class of registers which could be used for spilled 
 pseudos\
 +  of given class instead of memory,
 + reg_class_t, (reg_class_t),
 + NULL)

Should probably say that NO_REGS means none.

 +/* Determine mode for spilling pseudos into registers instead of memory.  */
 +DEFHOOK
 +(spill_class_mode,
 + This hook defines mode in which a pseudo of given mode and of the first\
 +  register class can be spilled into the second register class,
 + enum machine_mode, (reg_class_t, reg_class_t, enum machine_mode),
 + NULL)

It looks like the only use is in:

+ || (targetm.spill_class_mode (rclass, spill_class,
+   PSEUDO_REGNO_MODE (regno))
+ != PSEUDO_REGNO_MODE (regno))

So would it make sense to have a single hook like:

/* Determine mode for spilling pseudos into registers instead of memory.  */
DEFHOOK
(spill_class,
 This hook defines a class of registers which could be used for spilling\
  pseudos of the given mode and class, or @code{NO_REGS} if only memory\
  should be used.  Not defining this hook is equivalent to returning\
  @code{NO_REGS} for all inputs.
 reg_class_t, (reg_class_t, enum machine_mode),
 NULL)

?  It means that setup_reg_spill_flag needs a class-x-mode walk, but
(bad excuse ahoy) we have plenty of those already.  If we really wanted
to avoid the extra loop, we could make VOIDmode mean any mode,
although that does make the interface a bit more clunky.

Richard

Re: RFC: LRA for x86/x86-64 [0/9]

[Ian Lance Taylor]

On Mon, Oct 1, 2012 at 10:51 AM, Vladimir Makarov vmaka...@redhat.com wrote:

 When I proposed merge LRA to gcc4.8, I had in mind that:
   o moving most changes from LRA branch will help LRA maintenance on the
 branch and I'll have more time to work on other targets and problems.
   o the earlier we start the transition, the better it will be for LRA
 because LRA on the trunk will have more feedback and better testing.

 I've chosen x86/x86-64 for this because I am confident in this port.  On
 majority of tests, it generates faster, smaller code (even for these two
 extreme tests it generates 15% smaller code) for less time.  IMO, the slow
 compilation of the extreme tests are much less important than what I've just
 mentioned.

 But because I got clear objections from at least two people and no clear
 support for the LRA inclusion (there were just no objections to include it),
 I will not insists on LRA merge now.

I believe that we should proceed with the LRA merge as Vlad has
proposed, and treat the compilation time slowdowns on specific test
cases as bugs to be addressed.

Clearly these slowdowns are not good.  However, requiring significant
work like LRA to be better or equal to the current code in every
single case is making the perfect the enemy of the good.  We must
weigh the benefits and drawbacks, not require that there be no
drawbacks at all.  In this case I believe that the benefits of LRA
significantly outweigh the drawbacks.

Steven is correct in saying that there is a tendency to move on and
never address GCC bugs.  However, there is also a counter-vailing
tendency to fix GCC bugs.  Anyhow I'm certainly not saying that in all
cases it's OK to accept a merge with regressions; I'm saying that in
this specific case it is OK.

(I say all this based on Vlad's descriptions, I have not actually
looked at the patches.)

Ian

Re: RFC: LRA for x86/x86-64 [4/9]

[Paul_Koning]

On Oct 1, 2012, at 2:51 PM, Richard Sandiford wrote:

 ...
 E.g. for MIPS, SImode loads and stores have a displacement range of
 [-32768, 32764], but DImode loads and stores only accept [-32768, 32760].
 So the maximal displacement depends on mode, even though the instruction set
 is pretty regular.

It may be that the case doesn't arise in code GCC generates, but I don't think 
that's true.  The offset field is always a 2's complement 16 bit integer, hence 
in the range -32768..32767.  The alignment required in loading multibyte data 
with aligned load/store instructions applies to the final address, not the 
offset.  For example, if R1 contains 1, then LD r2,32767(r1) will work.

paul

Re: [Patch contrib] check_GNU_style: remove tmp file

[Ian Lance Taylor]

On Mon, Sep 10, 2012 at 5:23 AM, Christophe Lyon
christophe.l...@linaro.org wrote:

 Good point. Here is a new version, catching the same signals as warn_summary.

This is OK.

Thanks.

(Minor note: it's easier if you the ChangeLog entry in the body of the
message rather than the patch.)

Ian

Re: RFC: LRA for x86/x86-64 [0/9]

[David Miller]

From: Ian Lance Taylor i...@google.com
Date: Mon, 1 Oct 2012 11:55:56 -0700

 Steven is correct in saying that there is a tendency to move on and
 never address GCC bugs.  However, there is also a counter-vailing
 tendency to fix GCC bugs.  Anyhow I'm certainly not saying that in all
 cases it's OK to accept a merge with regressions; I'm saying that in
 this specific case it is OK.

I think it's more important in this case to recognize Steven's real
point, which is that for an identical situation (IRA), and with an
identical patch author, we had similar bugs.  They were promised to be
worked on, and yet some of those regressions are still very much with
us.

The likelyhood of a repeat is therefore very real.

I really don't have a lot of confidence given what has happened in
the past.  I also don't understand what's so evil about sorting this
out on a branch.  It's the perfect carrot to get the compile time
regressions fixed.

Re: PR 53889: Add __gthread_recursive_mutex_destroy

[Ian Lance Taylor]

On Sun, Sep 30, 2012 at 11:41 AM, Jonathan Wakely jwakely@gmail.com wrote:
 There is no __gthread_recursive_mutex_destroy function in the gthreads API.

 Trying to use __gthread_mutex_destroy fails to compile on platforms
 where the mutex
 types are different. To avoid resource leaks libstdc++ needs to hack
 around the missing function with overloaded functions and SFINAE
 tricks to detect how a recursive mutex can be destroyed.

 This patch extends the gthreads API to include
 __gthread_recursive_mutex_destroy, defining it for each gthread model,
 and removing the hacks from libstdc++.

 +return rtems_gxx_mutex_destroy( __mutex );

Space before '(', not space after.

Doing anything else here is going to be painful, but this assumes that
RTEMS uses the same representation for non-recursive and recursive
mutexes.  That is currently true, but it deserves a comment.


 --- a/libgcc/config/i386/gthr-win32.h
 +++ b/libgcc/config/i386/gthr-win32.h
 +static inline void
 +__gthread_recursive_mutex_destroy (__gthread_recursive_mutex_t *mutex)
 +{
 +  __gthread_mutex_t __mutex2;
 +  __mutex2.sema = mutex-sema;
 +  __gthr_win32_mutex_destroy (__mutex2);
 +}

I think it would be better to put this in
libgcc/config/i386/gthr-win32.c, like the other functions.  Then you
can just call CloseHandle.

 --- a/libgcc/config/mips/gthr-mipssde.h
 +++ b/libgcc/config/mips/gthr-mipssde.h

 +static inline int
 +__gthread_recursive_mutex_destroy (__gthread_recursive_mutex_t *__mutex)
 +{
 +  return __gthread_mutex_destroy(__mutex);
 +}

Will this even compile?  It doesn't look like it.

Ian

[SH] PR 51244 - Handle T bit - 0x7FFFFFFF / 0x80000000

[Oleg Endo]

Hello,

This handles the case where the T bit is stored to a reg as the value
0x7FFF or 0x8000.
Tested on rev 191894 with
make -k check RUNTESTFLAGS=--target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}

and no new failures.
OK?

Cheers,
Oleg

gcc/ChangeLog:

PR target/51244
* config/sh/sh.md (*mov_t_msb_neg): New insn and two 
accompanying unnamed split patterns.

testsuite/ChangeLog:

PR target/51244
* gcc.target/sh/pr51244-12.c: New.
Index: gcc/testsuite/gcc.target/sh/pr51244-12.c
===
--- gcc/testsuite/gcc.target/sh/pr51244-12.c	(revision 0)
+++ gcc/testsuite/gcc.target/sh/pr51244-12.c	(revision 0)
@@ -0,0 +1,68 @@
+/* Check that the negc instruction is generated as expected for the cases
+   below.  If we see a movrt or #-1 negc sequence it means that the pattern
+   which handles the inverted case does not work properly.  */
+/* { dg-do compile { target sh*-*-* } } */
+/* { dg-options -O1 } */
+/* { dg-skip-if  { sh*-*-* } { -m5* } {  } } */
+/* { dg-final { scan-assembler-times negc 10 } } */
+/* { dg-final { scan-assembler-not movrt|#-1|add|sub } } */
+
+int
+test00 (int a, int b, int* x)
+{
+  return (a == b) ? 0x7FFF : 0x8000;
+}
+
+int
+test00_inv (int a, int b)
+{
+  return (a != b) ? 0x8000 : 0x7FFF;
+}
+
+int
+test01 (int a, int b)
+{
+  return (a = b) ? 0x7FFF : 0x8000;
+}
+
+int
+test01_inv (int a, int b)
+{
+  return (a  b) ? 0x8000 : 0x7FFF;
+}
+
+int
+test02 (int a, int b)
+{
+  return (a  b) ? 0x7FFF : 0x8000;
+}
+
+int
+test02_inv (int a, int b)
+{
+  return (a = b) ? 0x8000 : 0x7FFF;
+}
+
+int
+test03 (int a, int b)
+{
+  return ((a  b) == 0) ? 0x7FFF : 0x8000;
+}
+
+int
+test03_inv (int a, int b)
+{
+  return ((a  b) != 0) ? 0x8000 : 0x7FFF;
+}
+
+int
+test04 (int a)
+{
+  return ((a  0x55) == 0) ? 0x7FFF : 0x8000;
+}
+
+int
+test04_inv (int a)
+{
+  return ((a  0x55) != 0) ? 0x8000 : 0x7FFF;
+}
Index: gcc/config/sh/sh.md
===
--- gcc/config/sh/sh.md	(revision 191894)
+++ gcc/config/sh/sh.md	(working copy)
@@ -10769,6 +10769,51 @@
 	(set (reg:SI T_REG) (const_int 1))
 	(use (match_dup 2))])])
 
+;; Use negc to store the T bit in a MSB of a reg in the following way:
+;;	T = 1: 0x8000 - reg
+;;	T = 0: 0x7FFF - reg
+;; This works because 0 - 0x8000 = 0x8000.
+(define_insn_and_split *mov_t_msb_neg
+  [(set (match_operand:SI 0 arith_reg_dest)
+	(minus:SI (const_int -2147483648)  ;; 0x8000
+		  (match_operand 1 t_reg_operand)))
+   (clobber (reg:SI T_REG))]
+  TARGET_SH1
+  #
+   can_create_pseudo_p ()
+  [(set (match_dup 2) (const_int -2147483648))
+   (parallel [(set (match_dup 0) (minus:SI (neg:SI (match_dup 2))
+ (reg:SI T_REG)))
+	  (clobber (reg:SI T_REG))])]
+{
+  operands[2] = gen_reg_rtx (SImode);
+})
+
+;; These are essentially the same as above, but with the inverted T bit.
+;; Combine recognizes the split patterns, but does not take them sometimes
+;; if the T_REG clobber is specified.  Instead it tries to split out the
+;; T bit negation.  Since these splits are supposed to be taken only by
+;; combine, it will see the T_REG clobber of the *mov_t_msb_neg insn, so this
+;; should be fine.
+(define_split
+  [(set (match_operand:SI 0 arith_reg_dest)
+	(plus:SI (match_operand 1 negt_reg_operand)
+		 (const_int 2147483647)))]  ;; 0x7fff
+  TARGET_SH1  can_create_pseudo_p ()
+  [(parallel [(set (match_dup 0)
+		   (minus:SI (const_int -2147483648) (reg:SI T_REG)))
+	  (clobber (reg:SI T_REG))])])
+
+(define_split
+  [(set (match_operand:SI 0 arith_reg_dest)
+	(if_then_else:SI (match_operand 1 t_reg_operand)
+			 (const_int 2147483647)  ;; 0x7fff
+			 (const_int -2147483648)))]  ;; 0x8000
+  TARGET_SH1  can_create_pseudo_p ()
+  [(parallel [(set (match_dup 0)
+		   (minus:SI (const_int -2147483648) (reg:SI T_REG)))
+	  (clobber (reg:SI T_REG))])])
+
 ;; The *negnegt pattern helps the combine pass to figure out how to fold 
 ;; an explicit double T bit negation.
 (define_insn_and_split *negnegt

Re: RFC: LRA for x86/x86-64 [0/9]

[Vladimir Makarov]

On 10/01/2012 03:19 PM, David Miller wrote:

From: Ian Lance Taylor i...@google.com
Date: Mon, 1 Oct 2012 11:55:56 -0700


Steven is correct in saying that there is a tendency to move on and
never address GCC bugs.  However, there is also a counter-vailing
tendency to fix GCC bugs.  Anyhow I'm certainly not saying that in all
cases it's OK to accept a merge with regressions; I'm saying that in
this specific case it is OK.

I think it's more important in this case to recognize Steven's real
point, which is that for an identical situation (IRA), and with an
identical patch author, we had similar bugs.  They were promised to be
worked on, and yet some of those regressions are still very much with
us.
That is not true.  I worked on many compiler time regression bugs. I 
remeber one serious degradation of compilation time on 
all_cp2k_gfortran.f90.  I solved the problem and make IRA working faster 
and generating much better code than the old RA.


http://blog.gmane.org/gmane.comp.gcc.patches/month=20080501/page=15

About other two mentioned PRs by Steven:

PR26854.  I worked on this bug even when IRA was on the branch and make 
again GCC with IRA 5% faster on this test than GCC with the old RA.


PR 54146 is 3 months old.  There were a lot work on other optimizations 
before IRA became important.  It happens only 2 months ago. I had no 
time to work on it but I am going to.


People sometimes see that RA takes a lot of compilation time but it is 
in the nature of RA.  I'd recommend first to check how the old RA 
behaves and then call it a degradation.


And please, don't listen just one side.

The likelyhood of a repeat is therefore very real.

I really don't have a lot of confidence given what has happened in
the past.  I also don't understand what's so evil about sorting this
out on a branch.  It's the perfect carrot to get the compile time
regressions fixed.

Wrong assumptions result in wrong conclusions.

Re: RFC: LRA for x86/x86-64 [0/9]

[Steven Bosscher]

On Mon, Oct 1, 2012 at 9:51 PM, Vladimir Makarov vmaka...@redhat.com wrote:
 I think it's more important in this case to recognize Steven's real
 point, which is that for an identical situation (IRA), and with an
 identical patch author, we had similar bugs.  They were promised to be
 worked on, and yet some of those regressions are still very much with
 us.

 That is not true.  I worked on many compiler time regression bugs. I remeber
 one serious degradation of compilation time on all_cp2k_gfortran.f90.  I
 solved the problem and make IRA working faster and generating much better
 code than the old RA.

 http://blog.gmane.org/gmane.comp.gcc.patches/month=20080501/page=15

 About other two mentioned PRs by Steven:

 PR26854.  I worked on this bug even when IRA was on the branch and make
 again GCC with IRA 5% faster on this test than GCC with the old RA.

 PR 54146 is 3 months old.  There were a lot work on other optimizations
 before IRA became important.  It happens only 2 months ago. I had no time to
 work on it but I am going to.

This is also not quite true, see PR37448, which shows the problems as
the test case for PR54146.

I just think scalability is a very important issue. If some pass or
algorithm scales bad on some measure, then users _will_ run into that
at some point and report bugs about it (if you're lucky enough to have
a user patient enough to sit out the long compile time :-) ). Also,
good scalability opens up opportunities. For example, historically GCC
has been conservative on inlining heuristics to avoid compile time
explosions. I think it's better to address the causes of that
explosion and to avoid introducing new potential bottlenecks.


 People sometimes see that RA takes a lot of compilation time but it is in
 the nature of RA.  I'd recommend first to check how the old RA behaves and
 then call it a degradation.

There's no question that RA is one of the hardest problems the
compiler has to solve, being NP-complete and all that. I like LRA's
iterative approach, but if you know you're going to solve a hard
problem with a number potentially expensive iterations, there's even
more reason to make scalability a design goal!

As I said earlier in this thread, I was really looking forward to IRA
at the time you worked on it, because it is supposed to be a regional
allocator and I had expected that to mean it could, well, allocate
per-region which is usually very helpful for scalability (partition
your function and insert compensation code on strategically picked
region boundaries). But that's not what IRA has turned out to be.
(Instead, its regional nature is one of the reasons for its
scalability problems.)  IRA is certainly not worse than old global.c
in very many ways, and LRA looks like a well thought-through and
welcome replacement of old reload. But scalability is an issue in the
design of IRA and LRA looks to be the same in that regard.

Ciao!
Steven

Re: RFC: LRA for x86/x86-64 [4/9]

[Jeff Law]

On 09/27/2012 07:44 PM, Vladimir Makarov wrote:

On 09/27/2012 08:07 PM, Joseph S. Myers wrote:

On Thu, 27 Sep 2012, Vladimir Makarov wrote:


Hook spill_class returns a value of enum reg_class which is defined in
target-depend include file.

That's what reg_class_t is for: avoiding enum reg_class in hook
interfaces.


Ok.  Thanks for pointing this out.

Here is the modified patch.

2012-09-27  Vladimir Makarov  vmaka...@redhat.com

 * targhooks.h (default_lra_p): Declare.
 (default_register_bank): Ditto.
 (default_different_addr_displacement_p): Ditto.
 * targhooks.c (default_lra_p): New function.
 (default_register_bank): Ditto.
 (default_different_addr_displacement_p): Ditto.
 * target.def (lra_p): New hook.
 (register_bank): Ditto.
 (different_addr_displacement_p): Ditto.
 (spill_class, spill_class_mode): New hooks.
 * doc/tm.texi.in: Add TARGET_LRA_P, TARGET_REGISTER_BANK,
 TARGET_DIFFERENT_ADDR_DISPLACEMENT_P, TARGET_SPILL_CLASS, and
 TARGET_SPILL_CLASS_MODE.
 * doc/tm.texi: Update.

The change also requires some modification in the 9th patch. The
ChangeLog for the patch should be the same as before.

This looks fine to me.

jeff

[PATCH, libbacktrace]: Compile with -fasynchronous-unwind-tables

[Uros Bizjak]

Hello!

Without -fasynchronous-unwind-tables, FDE is not generated for
backtrace_full and backtrace_simple wrappers. Without FDE, unwinding
terminates at these functions.

Attached patch fixes this problem by adding
-fasynchronous-unwind-tables, and this way forcing FDEs for all
functions. With this change, btest passes OK, failing log and
runtime/pprof from libgo testsuite also pass OK.

BTW: It would be enough to compile only backtrace.c and simple.c with
-fasynchronous-unwind-tables, since critical wrapper functions live
here.

2012-10-01  Uros Bizjak  ubiz...@gmail.com

PR other/54761
* Makefile.am (AM_CFLAGS): Add -fasynchronous-unwind-tables.
* Makefile.in: Regenerate.

Patch was bootstrapped and regression tested on x86_64-pc-linux-gnu
{,-m32} and alphaev68-pc-linux-gnu (where fixes all mentioned
unwinding failures).

OK for mainline?

Uros.
Index: ChangeLog
===
--- ChangeLog   (revision 191932)
+++ ChangeLog   (working copy)
@@ -1,3 +1,9 @@
+2012-10-01  Uros Bizjak  ubiz...@gmail.com
+
+   PR other/54761
+   * Makefile.am (AM_CFLAGS): Add -fasynchronous-unwind-tables.
+   * Makefile.in: Regenerate.
+
 2012-09-29  Ian Lance Taylor  i...@google.com
 
PR other/54749
Index: Makefile.am
===
--- Makefile.am (revision 191932)
+++ Makefile.am (working copy)
@@ -34,7 +34,7 @@
 AM_CPPFLAGS = -I $(top_srcdir)/../include -I $(top_srcdir)/../libgcc \
-I ../libgcc -I ../gcc/include -I $(MULTIBUILDTOP)../../gcc/include
 
-AM_CFLAGS = $(WARN_FLAGS) $(PIC_FLAG)
+AM_CFLAGS = $(WARN_FLAGS) $(PIC_FLAG) -fasynchronous-unwind-tables
 
 noinst_LTLIBRARIES = libbacktrace.la
 
Index: Makefile.in
===
--- Makefile.in (revision 191932)
+++ Makefile.in (working copy)
@@ -253,7 +253,7 @@
 AM_CPPFLAGS = -I $(top_srcdir)/../include -I $(top_srcdir)/../libgcc \
-I ../libgcc -I ../gcc/include -I $(MULTIBUILDTOP)../../gcc/include
 
-AM_CFLAGS = $(WARN_FLAGS) $(PIC_FLAG)
+AM_CFLAGS = $(WARN_FLAGS) $(PIC_FLAG) -fasynchronous-unwind-tables
 noinst_LTLIBRARIES = libbacktrace.la
 libbacktrace_la_SOURCES = \
backtrace.h \

Re: [patch][lra] Use XNEWVEC and friends instead of xmalloc/xrealloc, and add some timevars

[Mike Stump]

On Oct 1, 2012, at 4:05 AM, Steven Bosscher stevenb@gmail.com wrote:
 This patch uses the libiberty new-like operators instead of using
 xmalloc/xrealloc.

So, in headers that can be used by C compiles, we should use the abstraction…  
Should we prefer it for translation units that are C++ only?

[PATCH] Fix powerpc breakage, was: Add option for dumping to stderr (issue6190057)

[Michael Meissner]

I tracked down some of the other code that previously used REPORT_DETAILS, and
MSG_NOTE is the new way to do the same thing.  This bootstraps and no
unexpected errors occur during make check.  Is it ok to install?

2012-10-01  Michael Meissner  meiss...@linux.vnet.ibm.com

* config/rs6000/rs6000.c (toplevel): Include dumpfile.h.
(rs6000_density_test): Rework to accomidate 09-30 change by Sharad
Singhai.

* config/rs6000/t-rs6000 (rs6000.o): Add dumpfile.h dependency.

Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 191932)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -58,6 +58,7 @@
 #include tm-constrs.h
 #include opts.h
 #include tree-vectorizer.h
+#include dumpfile.h
 #if TARGET_XCOFF
 #include xcoffout.h  /* get declarations of xcoff_*_section_name */
 #endif
@@ -3518,11 +3519,11 @@ rs6000_density_test (rs6000_cost_data *d
vec_cost + not_vec_cost  DENSITY_SIZE_THRESHOLD)
 {
   data-cost[vect_body] = vec_cost * (100 + DENSITY_PENALTY) / 100;
-  if (vect_print_dump_info (REPORT_DETAILS))
-   fprintf (vect_dump,
-density %d%%, cost %d exceeds threshold, penalizing 
-loop body cost by %d%%, density_pct, 
-vec_cost + not_vec_cost, DENSITY_PENALTY);
+  if (dump_kind_p (MSG_NOTE))
+   dump_printf_loc (MSG_NOTE, vect_location,
+density %d%%, cost %d exceeds threshold, penalizing 
+loop body cost by %d%%, density_pct,
+vec_cost + not_vec_cost, DENSITY_PENALTY);
 }
 }
 
Index: gcc/config/rs6000/t-rs6000
===
--- gcc/config/rs6000/t-rs6000  (revision 191932)
+++ gcc/config/rs6000/t-rs6000  (working copy)
@@ -26,7 +26,7 @@ rs6000.o: $(CONFIG_H) $(SYSTEM_H) corety
   $(OBSTACK_H) $(TREE_H) $(EXPR_H) $(OPTABS_H) except.h function.h \
   output.h dbxout.h $(BASIC_BLOCK_H) toplev.h $(GGC_H) $(HASHTAB_H) \
   $(TM_P_H) $(TARGET_H) $(TARGET_DEF_H) langhooks.h reload.h gt-rs6000.h \
-  cfgloop.h $(OPTS_H) $(COMMON_TARGET_H)
+  cfgloop.h $(OPTS_H) $(COMMON_TARGET_H) dumpfile.h
 
 rs6000-c.o: $(srcdir)/config/rs6000/rs6000-c.c \
 $(srcdir)/config/rs6000/rs6000-protos.h \

-- 
Michael Meissner, IBM
5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA
meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899

Re: [PATCH] Fix powerpc breakage, was: Add option for dumping to stderr (issue6190057)

[Gabriel Dos Reis]

On Mon, Oct 1, 2012 at 4:37 PM, Michael Meissner
meiss...@linux.vnet.ibm.com wrote:
 I tracked down some of the other code that previously used REPORT_DETAILS, and
 MSG_NOTE is the new way to do the same thing.  This bootstraps and no
 unexpected errors occur during make check.  Is it ok to install?

yes -- qualifies as obvious.  Thanks!



 2012-10-01  Michael Meissner  meiss...@linux.vnet.ibm.com

 * config/rs6000/rs6000.c (toplevel): Include dumpfile.h.
 (rs6000_density_test): Rework to accomidate 09-30 change by Sharad
 Singhai.

 * config/rs6000/t-rs6000 (rs6000.o): Add dumpfile.h dependency.

 Index: gcc/config/rs6000/rs6000.c
 ===
 --- gcc/config/rs6000/rs6000.c  (revision 191932)
 +++ gcc/config/rs6000/rs6000.c  (working copy)
 @@ -58,6 +58,7 @@
  #include tm-constrs.h
  #include opts.h
  #include tree-vectorizer.h
 +#include dumpfile.h
  #if TARGET_XCOFF
  #include xcoffout.h  /* get declarations of xcoff_*_section_name */
  #endif
 @@ -3518,11 +3519,11 @@ rs6000_density_test (rs6000_cost_data *d
 vec_cost + not_vec_cost  DENSITY_SIZE_THRESHOLD)
  {
data-cost[vect_body] = vec_cost * (100 + DENSITY_PENALTY) / 100;
 -  if (vect_print_dump_info (REPORT_DETAILS))
 -   fprintf (vect_dump,
 -density %d%%, cost %d exceeds threshold, penalizing 
 -loop body cost by %d%%, density_pct,
 -vec_cost + not_vec_cost, DENSITY_PENALTY);
 +  if (dump_kind_p (MSG_NOTE))
 +   dump_printf_loc (MSG_NOTE, vect_location,
 +density %d%%, cost %d exceeds threshold, penalizing 
 
 +loop body cost by %d%%, density_pct,
 +vec_cost + not_vec_cost, DENSITY_PENALTY);
  }
  }

 Index: gcc/config/rs6000/t-rs6000
 ===
 --- gcc/config/rs6000/t-rs6000  (revision 191932)
 +++ gcc/config/rs6000/t-rs6000  (working copy)
 @@ -26,7 +26,7 @@ rs6000.o: $(CONFIG_H) $(SYSTEM_H) corety
$(OBSTACK_H) $(TREE_H) $(EXPR_H) $(OPTABS_H) except.h function.h \
output.h dbxout.h $(BASIC_BLOCK_H) toplev.h $(GGC_H) $(HASHTAB_H) \
$(TM_P_H) $(TARGET_H) $(TARGET_DEF_H) langhooks.h reload.h gt-rs6000.h \
 -  cfgloop.h $(OPTS_H) $(COMMON_TARGET_H)
 +  cfgloop.h $(OPTS_H) $(COMMON_TARGET_H) dumpfile.h

  rs6000-c.o: $(srcdir)/config/rs6000/rs6000-c.c \
  $(srcdir)/config/rs6000/rs6000-protos.h \

 --
 Michael Meissner, IBM
 5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA
 meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899

Convert more non-GTY htab_t to hash_table.

[Lawrence Crowl]

Change more non-GTY hash tables to use the new type-safe template hash table.
Constify member function parameters that can be const.
Correct a couple of expressions in formerly uninstantiated templates.

The new code is 0.362% faster in bootstrap, with a 99.5% confidence of
being faster.

Tested on x86-64.

Okay for trunk?


Index: gcc/java/ChangeLog

2012-10-01  Lawrence Crowl  cr...@google.com

* Make-lang.in (JAVA_OBJS): Add dependence on hash-table.o.
(JCFDUMP_OBJS): Add dependence on hash-table.o.
(jcf-io.o): Add dependence on hash-table.h.
* jcf-io.c (memoized_class_lookups): Change to use type-safe hash table.

Index: gcc/c/ChangeLog

2012-10-01  Lawrence Crowl  cr...@google.com

* Make-lang.in (c-decl.o): Add dependence on hash-table.h.
* c-decl.c (detect_field_duplicates_hash): Change to new type-safe
hash table.

Index: gcc/objc/ChangeLog

2012-10-01  Lawrence Crowl  cr...@google.com

* Make-lang.in (OBJC_OBJS): Add dependence on hash-table.o.
(objc-act.o): Add dependence on hash-table.h.
* objc-act.c (objc_detect_field_duplicates): Change to new type-safe
hash table.

Index: gcc/ChangeLog

2012-10-01  Lawrence Crowl  cr...@google.com

* Makefile.in (fold-const.o): Add depencence on hash-table.h.
(dse.o): Likewise.
(cfg.o): Likewise.
* fold-const.c (fold_checksum_tree): Change to new type-safe hash table.
* (print_fold_checksum): Likewise.
* cfg.c (var bb_original): Likewise.
* (var bb_copy): Likewise.
* (var loop_copy): Likewise.
* hash-table.h (template hash_table): Constify parameters for find...
and remove_elt... member functions.
(hash_table::empty) Correct size expression.
(hash_table::clear_slot) Correct deleted entry assignment.
* dse.c (var rtx_group_table): Change to new type-safe hash table.

Index: gcc/cp/ChangeLog

2012-10-01  Lawrence Crowl  cr...@google.com

* Make-lang.in (class.o): Add dependence on hash-table.h.
(tree.o): Likewise.
(semantics.o): Likewise.
* class.c (fixed_type_or_null): Change to new type-safe hash table.
* tree.c (verify_stmt_tree): Likewise.
(verify_stmt_tree_r): Likewise.
* semantics.c (struct nrv_data): Likewise.


Index: gcc/java/Make-lang.in
===
--- gcc/java/Make-lang.in   (revision 191941)
+++ gcc/java/Make-lang.in   (working copy)
@@ -83,10 +83,10 @@ JAVA_OBJS = java/class.o java/decl.o jav
   java/zextract.o java/jcf-io.o java/win32-host.o java/jcf-parse.o
java/mangle.o \
   java/mangle_name.o java/builtins.o java/resource.o \
   java/jcf-depend.o \
-  java/jcf-path.o java/boehm.o java/java-gimplify.o
+  java/jcf-path.o java/boehm.o java/java-gimplify.o hash-table.o

 JCFDUMP_OBJS = java/jcf-dump.o java/jcf-io.o java/jcf-depend.o
java/jcf-path.o \
-   java/win32-host.o java/zextract.o ggc-none.o
+   java/win32-host.o java/zextract.o ggc-none.o hash-table.o

 JVGENMAIN_OBJS = java/jvgenmain.o java/mangle_name.o

@@ -326,7 +326,7 @@ java/java-gimplify.o: java/java-gimplify
 # jcf-io.o needs $(ZLIBINC) added to cflags.
 CFLAGS-java/jcf-io.o += $(ZLIBINC)
 java/jcf-io.o: java/jcf-io.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \
-  $(JAVA_TREE_H) java/zipfile.h
+  $(JAVA_TREE_H) java/zipfile.h $(HASH_TABLE_H)

 # jcf-path.o needs a -D.
 CFLAGS-java/jcf-path.o += \
Index: gcc/java/jcf-io.c
===
--- gcc/java/jcf-io.c   (revision 191941)
+++ gcc/java/jcf-io.c   (working copy)
@@ -31,7 +31,7 @@ The Free Software Foundation is independ
 #include jcf.h
 #include tree.h
 #include java-tree.h
-#include hashtab.h
+#include hash-table.h
 #include dirent.h

 #include zlib.h
@@ -271,20 +271,34 @@ find_classfile (char *filename, JCF *jcf
   return open_class (filename, jcf, fd, dep_name);
 }

-/* Returns 1 if the CLASSNAME (really a char *) matches the name
-   stored in TABLE_ENTRY (also a char *).  */

-static int
-memoized_class_lookup_eq (const void *table_entry, const void *classname)
+/* Hash table helper.  */
+
+struct charstar_hash : typed_noop_remove char
 {
-  return strcmp ((const char *)classname, (const char *)table_entry) == 0;
+  typedef const char T;
+  static inline hashval_t hash (const T *candidate);
+  static inline bool equal (const T *existing, const T *candidate);
+};
+
+inline hashval_t
+charstar_hash::hash (const T *candidate)
+{
+  return htab_hash_string (candidate);
 }

+inline bool
+charstar_hash::equal (const T *existing, const T *candidate)
+{
+  return strcmp (existing, candidate) == 0;
+}
+
+
 /* A hash table keeping track of class names that were not found
during class lookup.  (There is no need to cache the values
associated with names that were found; they are saved in
IDENTIFIER_CLASS_VALUE.)  */
-static htab_t 

[patch][lra] a few bitmap obstacks for lra-assigns

[Steven Bosscher]

Hello,

This eliminates a few large loops in lra-assigns.c. They're not the
most costly loops but the life times of the bitmaps is well-defined
and destroying a bitmap obstack is much cheaper than looping over all
bitmaps calling bitmap_clear. The saving is small but you have to
start somewhere...

Bootstrapped lra-branch and tested on x86_64-unknown-linux-gnu, along
with the patch from earlier today. OK for the branch?

Ciao!
Steven


lra_assign_bitobstacks.diff
Description: Binary data

[PATCH rs6000 testsuite] Fix a couple tests for VSX scalar instructions

[Pat Haugen]

This patch fixes a couple failures that occur if the testsuite is run 
with -mvsx and the VSX scalar sqrt instructions are generated. Ok for trunk?


-Pat


testsuite/ChangeLog:
2012-10-01  Pat Haugen pthau...@us.ibm.com

* gcc.target/powerpc/pr46728-1.c: Accept xssqrtdp.
* gcc.target/powerpc/pr46728-2.c: Likewise.


Index: gcc/testsuite/gcc.target/powerpc/pr46728-1.c
===
--- gcc/testsuite/gcc.target/powerpc/pr46728-1.c(revision 191713)
+++ gcc/testsuite/gcc.target/powerpc/pr46728-1.c(working copy)
@@ -27,5 +27,5 @@ main (int argc, char *argv[])
 }
 
 
-/* { dg-final { scan-assembler-times fsqrt 2 { target powerpc*-*-* } } } */
+/* { dg-final { scan-assembler-times fsqrt|xssqrtdp 2 { target powerpc*-*-* 
} } } */
 /* { dg-final { scan-assembler-not pow { target powerpc*-*-* } } } */
Index: gcc/testsuite/gcc.target/powerpc/pr46728-2.c
===
--- gcc/testsuite/gcc.target/powerpc/pr46728-2.c(revision 191713)
+++ gcc/testsuite/gcc.target/powerpc/pr46728-2.c(working copy)
@@ -27,5 +27,5 @@ main (int argc, char *argv[])
 }
 
 
-/* { dg-final { scan-assembler-times fsqrt 4 { target powerpc*-*-* } } } */
+/* { dg-final { scan-assembler-times fsqrt|xssqrtdp 4 { target powerpc*-*-* 
} } } */
 /* { dg-final { scan-assembler-not pow { target powerpc*-*-* } } } */

[patch][lra] Comment typo fix

[Steven Bosscher]

I suppose no-one would object if I commit this as obvious at some point?

Index: lra-constraints.c
===
--- lra-constraints.c   (revision 191858)
+++ lra-constraints.c   (working copy)
@@ -4293,7 +4293,7 @@ update_ebb_live_info (rtx head, rtx tail
{
  if (prev_bb != NULL)
{
- /* Udpate DF_LR_IN (prev_bb):  */
+ /* Update DF_LR_IN (prev_bb):  */
  EXECUTE_IF_SET_IN_BITMAP (check_only_regs, 0, j, bi)
if (bitmap_bit_p (live_regs, j))
  bitmap_set_bit (DF_LR_IN (prev_bb), j);

Re: [patch][lra] Comment typo fix

[Robert Dewar]

On 10/1/2012 6:09 PM, Steven Bosscher wrote:

I suppose no-one would object if I commit this as obvious at some point?

Index: lra-constraints.c
===
--- lra-constraints.c   (revision 191858)
+++ lra-constraints.c   (working copy)
@@ -4293,7 +4293,7 @@ update_ebb_live_info (rtx head, rtx tail
 {
   if (prev_bb != NULL)
 {
- /* Udpate DF_LR_IN (prev_bb):  */
+ /* Update DF_LR_IN (prev_bb):  */
   EXECUTE_IF_SET_IN_BITMAP (check_only_regs, 0, j, bi)
 if (bitmap_bit_p (live_regs, j))
   bitmap_set_bit (DF_LR_IN (prev_bb), j);



took me a few readings to see the change you had made, amazing how
the brain reads what it expects to see :-)

MAINTAINERS: add myself as dwarf debugging code maintainer

[Cary Coutant]

2012-10-01  Cary Coutant  ccout...@google.com

* MAINTAINERS: Add myself as dwarf debugging code maintainer.


Index: MAINTAINERS
===
--- MAINTAINERS (revision 191942)
+++ MAINTAINERS (working copy)
@@ -185,6 +185,7 @@ caller-save.c   Jeff Law
 l...@redhat.com
 callgraph  Jan Hubicka j...@suse.cz
 debugging code Jim Wilson  wil...@tuliptree.org
 dwarf debugging code   Jason Merrill   ja...@redhat.com
+dwarf debugging code   Cary Coutantccout...@google.com
 c++ runtime libs   Paolo Carlini   paolo.carl...@oracle.com
 c++ runtime libs   Gabriel Dos Reisg...@integrable-solutions.net
 c++ runtime libs   Ulrich Drepper  drep...@gmail.com

Re: [PATCH] Fix powerpc breakage, was: Add option for dumping to stderr (issue6190057)

[Xinliang David Li]

On Mon, Oct 1, 2012 at 2:37 PM, Michael Meissner
meiss...@linux.vnet.ibm.com wrote:
 I tracked down some of the other code that previously used REPORT_DETAILS, and
 MSG_NOTE is the new way to do the same thing.  This bootstraps and no
 unexpected errors occur during make check.  Is it ok to install?

 2012-10-01  Michael Meissner  meiss...@linux.vnet.ibm.com

 * config/rs6000/rs6000.c (toplevel): Include dumpfile.h.
 (rs6000_density_test): Rework to accomidate 09-30 change by Sharad
 Singhai.

 * config/rs6000/t-rs6000 (rs6000.o): Add dumpfile.h dependency.

 Index: gcc/config/rs6000/rs6000.c
 ===
 --- gcc/config/rs6000/rs6000.c  (revision 191932)
 +++ gcc/config/rs6000/rs6000.c  (working copy)
 @@ -58,6 +58,7 @@
  #include tm-constrs.h
  #include opts.h
  #include tree-vectorizer.h
 +#include dumpfile.h
  #if TARGET_XCOFF
  #include xcoffout.h  /* get declarations of xcoff_*_section_name */
  #endif
 @@ -3518,11 +3519,11 @@ rs6000_density_test (rs6000_cost_data *d
 vec_cost + not_vec_cost  DENSITY_SIZE_THRESHOLD)
  {
data-cost[vect_body] = vec_cost * (100 + DENSITY_PENALTY) / 100;
 -  if (vect_print_dump_info (REPORT_DETAILS))
 -   fprintf (vect_dump,
 -density %d%%, cost %d exceeds threshold, penalizing 
 -loop body cost by %d%%, density_pct,
 -vec_cost + not_vec_cost, DENSITY_PENALTY);
 +  if (dump_kind_p (MSG_NOTE))

Is this check needed? Seems redundant.

David


 +   dump_printf_loc (MSG_NOTE, vect_location,
 +density %d%%, cost %d exceeds threshold, penalizing 
 
 +loop body cost by %d%%, density_pct,
 +vec_cost + not_vec_cost, DENSITY_PENALTY);
  }
  }

 Index: gcc/config/rs6000/t-rs6000
 ===
 --- gcc/config/rs6000/t-rs6000  (revision 191932)
 +++ gcc/config/rs6000/t-rs6000  (working copy)
 @@ -26,7 +26,7 @@ rs6000.o: $(CONFIG_H) $(SYSTEM_H) corety
$(OBSTACK_H) $(TREE_H) $(EXPR_H) $(OPTABS_H) except.h function.h \
output.h dbxout.h $(BASIC_BLOCK_H) toplev.h $(GGC_H) $(HASHTAB_H) \
$(TM_P_H) $(TARGET_H) $(TARGET_DEF_H) langhooks.h reload.h gt-rs6000.h \
 -  cfgloop.h $(OPTS_H) $(COMMON_TARGET_H)
 +  cfgloop.h $(OPTS_H) $(COMMON_TARGET_H) dumpfile.h

  rs6000-c.o: $(srcdir)/config/rs6000/rs6000-c.c \
  $(srcdir)/config/rs6000/rs6000-protos.h \

 --
 Michael Meissner, IBM
 5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA
 meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899

Re: [PATCH, libbacktrace]: Compile with -fasynchronous-unwind-tables

[Ian Lance Taylor]

On Mon, Oct 1, 2012 at 2:12 PM, Uros Bizjak ubiz...@gmail.com wrote:

 Without -fasynchronous-unwind-tables, FDE is not generated for
 backtrace_full and backtrace_simple wrappers. Without FDE, unwinding
 terminates at these functions.

I'm not opposed to -fasynchronous-unwind-tables, but now that you
bring it up I'm fairly certain that it would suffice to use
-funwind-tables.  I've been testing mainly on x86_64, and I forgot
that on x86_64 -funwind-tables is the default.  Sorry about that.  And
-fasynchronous-unwind-tables is the default also, so I could be wrong
that -funwind-tables is all that is needed.

 Attached patch fixes this problem by adding
 -fasynchronous-unwind-tables, and this way forcing FDEs for all
 functions. With this change, btest passes OK, failing log and
 runtime/pprof from libgo testsuite also pass OK.

This is basically fine but libbacktrace may be compiled by the host
compiler and that may not be GCC, so please add a configure test to
see if the compiler accepts the -fasynchronous-unwind-tables option.

Ian

Re: [PATCH] Fix powerpc breakage, was: Add option for dumping to stderr (issue6190057)

[Sharad Singhai]

Thanks for tracking down and fixing the powerpc port.

The dump_kind_p () check is redundant but canonical form here. I
think blocks of dump code guarded by if dump_kind_p (...) might be
easier to read/maintain.

Sharad
Sharad


On Mon, Oct 1, 2012 at 3:45 PM, Xinliang David Li davi...@google.com wrote:
 On Mon, Oct 1, 2012 at 2:37 PM, Michael Meissner
 meiss...@linux.vnet.ibm.com wrote:
 I tracked down some of the other code that previously used REPORT_DETAILS, 
 and
 MSG_NOTE is the new way to do the same thing.  This bootstraps and no
 unexpected errors occur during make check.  Is it ok to install?

 2012-10-01  Michael Meissner  meiss...@linux.vnet.ibm.com

 * config/rs6000/rs6000.c (toplevel): Include dumpfile.h.
 (rs6000_density_test): Rework to accomidate 09-30 change by Sharad
 Singhai.

 * config/rs6000/t-rs6000 (rs6000.o): Add dumpfile.h dependency.

 Index: gcc/config/rs6000/rs6000.c
 ===
 --- gcc/config/rs6000/rs6000.c  (revision 191932)
 +++ gcc/config/rs6000/rs6000.c  (working copy)
 @@ -58,6 +58,7 @@
  #include tm-constrs.h
  #include opts.h
  #include tree-vectorizer.h
 +#include dumpfile.h
  #if TARGET_XCOFF
  #include xcoffout.h  /* get declarations of xcoff_*_section_name */
  #endif
 @@ -3518,11 +3519,11 @@ rs6000_density_test (rs6000_cost_data *d
 vec_cost + not_vec_cost  DENSITY_SIZE_THRESHOLD)
  {
data-cost[vect_body] = vec_cost * (100 + DENSITY_PENALTY) / 100;
 -  if (vect_print_dump_info (REPORT_DETAILS))
 -   fprintf (vect_dump,
 -density %d%%, cost %d exceeds threshold, penalizing 
 -loop body cost by %d%%, density_pct,
 -vec_cost + not_vec_cost, DENSITY_PENALTY);
 +  if (dump_kind_p (MSG_NOTE))

 Is this check needed? Seems redundant.

 David


 +   dump_printf_loc (MSG_NOTE, vect_location,
 +density %d%%, cost %d exceeds threshold, 
 penalizing 
 +loop body cost by %d%%, density_pct,
 +vec_cost + not_vec_cost, DENSITY_PENALTY);
  }
  }

 Index: gcc/config/rs6000/t-rs6000
 ===
 --- gcc/config/rs6000/t-rs6000  (revision 191932)
 +++ gcc/config/rs6000/t-rs6000  (working copy)
 @@ -26,7 +26,7 @@ rs6000.o: $(CONFIG_H) $(SYSTEM_H) corety
$(OBSTACK_H) $(TREE_H) $(EXPR_H) $(OPTABS_H) except.h function.h \
output.h dbxout.h $(BASIC_BLOCK_H) toplev.h $(GGC_H) $(HASHTAB_H) \
$(TM_P_H) $(TARGET_H) $(TARGET_DEF_H) langhooks.h reload.h gt-rs6000.h \
 -  cfgloop.h $(OPTS_H) $(COMMON_TARGET_H)
 +  cfgloop.h $(OPTS_H) $(COMMON_TARGET_H) dumpfile.h

  rs6000-c.o: $(srcdir)/config/rs6000/rs6000-c.c \
  $(srcdir)/config/rs6000/rs6000-protos.h \

 --
 Michael Meissner, IBM
 5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA
 meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899

Re: [PATCH] Fix powerpc breakage, was: Add option for dumping to stderr (issue6190057)

[Xinliang David Li]

On Mon, Oct 1, 2012 at 4:05 PM, Sharad Singhai sing...@google.com wrote:
 Thanks for tracking down and fixing the powerpc port.

 The dump_kind_p () check is redundant but canonical form here. I
 think blocks of dump code guarded by if dump_kind_p (...) might be
 easier to read/maintain.


I find it confusing to be honest. The redundant check serves no purpose.

David

 Sharad
 Sharad


 On Mon, Oct 1, 2012 at 3:45 PM, Xinliang David Li davi...@google.com wrote:
 On Mon, Oct 1, 2012 at 2:37 PM, Michael Meissner
 meiss...@linux.vnet.ibm.com wrote:
 I tracked down some of the other code that previously used REPORT_DETAILS, 
 and
 MSG_NOTE is the new way to do the same thing.  This bootstraps and no
 unexpected errors occur during make check.  Is it ok to install?

 2012-10-01  Michael Meissner  meiss...@linux.vnet.ibm.com

 * config/rs6000/rs6000.c (toplevel): Include dumpfile.h.
 (rs6000_density_test): Rework to accomidate 09-30 change by Sharad
 Singhai.

 * config/rs6000/t-rs6000 (rs6000.o): Add dumpfile.h dependency.

 Index: gcc/config/rs6000/rs6000.c
 ===
 --- gcc/config/rs6000/rs6000.c  (revision 191932)
 +++ gcc/config/rs6000/rs6000.c  (working copy)
 @@ -58,6 +58,7 @@
  #include tm-constrs.h
  #include opts.h
  #include tree-vectorizer.h
 +#include dumpfile.h
  #if TARGET_XCOFF
  #include xcoffout.h  /* get declarations of xcoff_*_section_name */
  #endif
 @@ -3518,11 +3519,11 @@ rs6000_density_test (rs6000_cost_data *d
 vec_cost + not_vec_cost  DENSITY_SIZE_THRESHOLD)
  {
data-cost[vect_body] = vec_cost * (100 + DENSITY_PENALTY) / 100;
 -  if (vect_print_dump_info (REPORT_DETAILS))
 -   fprintf (vect_dump,
 -density %d%%, cost %d exceeds threshold, penalizing 
 -loop body cost by %d%%, density_pct,
 -vec_cost + not_vec_cost, DENSITY_PENALTY);
 +  if (dump_kind_p (MSG_NOTE))

 Is this check needed? Seems redundant.

 David


 +   dump_printf_loc (MSG_NOTE, vect_location,
 +density %d%%, cost %d exceeds threshold, 
 penalizing 
 +loop body cost by %d%%, density_pct,
 +vec_cost + not_vec_cost, DENSITY_PENALTY);
  }
  }

 Index: gcc/config/rs6000/t-rs6000
 ===
 --- gcc/config/rs6000/t-rs6000  (revision 191932)
 +++ gcc/config/rs6000/t-rs6000  (working copy)
 @@ -26,7 +26,7 @@ rs6000.o: $(CONFIG_H) $(SYSTEM_H) corety
$(OBSTACK_H) $(TREE_H) $(EXPR_H) $(OPTABS_H) except.h function.h \
output.h dbxout.h $(BASIC_BLOCK_H) toplev.h $(GGC_H) $(HASHTAB_H) \
$(TM_P_H) $(TARGET_H) $(TARGET_DEF_H) langhooks.h reload.h gt-rs6000.h \
 -  cfgloop.h $(OPTS_H) $(COMMON_TARGET_H)
 +  cfgloop.h $(OPTS_H) $(COMMON_TARGET_H) dumpfile.h

  rs6000-c.o: $(srcdir)/config/rs6000/rs6000-c.c \
  $(srcdir)/config/rs6000/rs6000-protos.h \

 --
 Michael Meissner, IBM
 5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA
 meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899

Re: [PATCH] Rs6000 infrastructure cleanup (switches), revised patch #2d

[Michael Meissner]

2012-10-01  Michael Meissner  meiss...@linux.vnet.ibm.com

* config/rs6000/rs6000.c (rs6000_option_override_internal): If
-mcpu=xxx is not specified and the compiler is not configured
using --with-cpu=xxx, use the bits from the TARGET_DEFAULT to
set the initial options.

I reworked the patch to allow TARGET_DEFAULT bits to be set if there is no
-mcpu=xxx and the compiler was not configured using --with-cpu=xxx, so that
we don't first clear all of the ISA bits, set them from the cpu, and then merge
back in the TARGET_DEFAULT bits.

Somebody asked about what is set, when this function gets called.  The
target_flags variable is set with the initial settings (TARGET_DEFAULT) and
then all of the switches that the user sets or resets are then applied.  The
target_flags_explicit variable is only set if the user explicitly used that
switch.

So for instance, if the user passed -mpopcntb -mno-vsx on Linux 64-bit systems,
target_flags would be 0x150001 (MASK_PPC_GFXOPT | MASK_POWERPC64 | MASK_64BIT |
MASK_POPCNTB) and target_flags_explicit would be 0x201 (MASK_POPCNTB |
MASK_VSX).

Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 191942)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -2446,21 +2446,34 @@ rs6000_option_override_internal (bool gl
   rs6000_cpu_index = cpu_index = main_target_opt-x_rs6000_cpu_index;
   have_cpu = true;
 }
+  else if (implicit_cpu)
+{
+  rs6000_cpu_index = cpu_index = rs6000_cpu_name_lookup (implicit_cpu);
+  have_cpu = true;
+}
   else
 {
-  const char *default_cpu =
-(implicit_cpu ? implicit_cpu
- : (TARGET_POWERPC64 ? powerpc64 : powerpc));
-
+  const char *default_cpu = (TARGET_POWERPC64 ? powerpc64 : powerpc);
   rs6000_cpu_index = cpu_index = rs6000_cpu_name_lookup (default_cpu);
-  have_cpu = implicit_cpu != 0;
+  have_cpu = false;
 }
 
   gcc_assert (cpu_index = 0);
 
-  target_flags = ~set_masks;
-  target_flags |= (processor_target_table[cpu_index].target_enable
-   set_masks);
+  /* If we have a cpu, either through an explicit -mcpu=xxx or if the
+ compiler was configured with --with-cpu=xxx, replace all of the ISA bits
+ with those from the cpu, except for options that were explicitly set.  If
+ we don't have a cpu, do not override the target bits set in
+ TARGET_DEFAULT.  */
+  if (have_cpu)
+{
+  target_flags = ~set_masks;
+  target_flags |= (processor_target_table[cpu_index].target_enable
+   set_masks);
+}
+  else
+target_flags |= (processor_target_table[cpu_index].target_enable
+ ~target_flags_explicit);
 
   if (rs6000_tune_index = 0)
 tune_index = rs6000_tune_index;

-- 
Michael Meissner, IBM
5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA
meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899

Re: [PATCH rs6000 testsuite] Fix a couple tests for VSX scalar instructions

[David Edelsohn]

On Mon, Oct 1, 2012 at 6:03 PM, Pat Haugen pthau...@linux.vnet.ibm.com wrote:
 This patch fixes a couple failures that occur if the testsuite is run with
 -mvsx and the VSX scalar sqrt instructions are generated. Ok for trunk?

 -Pat


 testsuite/ChangeLog:
 2012-10-01  Pat Haugen pthau...@us.ibm.com

 * gcc.target/powerpc/pr46728-1.c: Accept xssqrtdp.
 * gcc.target/powerpc/pr46728-2.c: Likewise.

LGTM.

Thanks, David

Re: [PATCH] Fix test breakage, was: Add option for dumping to stderr (issue6190057)

[Sharad Singhai]

Here is a patch to fix test breakage caused by r191883. Bootstrapped
on x86_64 and tested with
make -k check RUNTESTFLAGS=--target_board=unix/\{,-m32\}.

Okay for trunk?

Thanks,
Sharad

2012-10-01  Sharad Singhai  sing...@google.com

* tree-vect-stmts.c (vectorizable_operation): Add missing return.

testsuite/Changelog

* gfortran.dg/vect/vect.exp: Change verbose vectorizor dump options
to fix test failures caused by r191883.
* gcc.dg/tree-ssa/gen-vect-11.c: Likewise.
* gcc.dg/tree-ssa/gen-vect-2.c: Likewise.
* gcc.dg/tree-ssa/gen-vect-32.c: Likewise.
* gcc.dg/tree-ssa/gen-vect-25.c: Likewise.
* gcc.dg/tree-ssa/gen-vect-11a.c: Likewise.
* gcc.dg/tree-ssa/gen-vect-26.c: Likewise.
* gcc.dg/tree-ssa/gen-vect-11b.c: Likewise.
* gcc.dg/tree-ssa/gen-vect-11c.c: Likewise.
* gcc.dg/tree-ssa/gen-vect-28.c: Likewise.
* testsuite/gcc.target/i386/vect-double-1.c: Fix test. Missing entry
from r191883.


Index: testsuite/gfortran.dg/vect/vect.exp
===
--- testsuite/gfortran.dg/vect/vect.exp (revision 191883)
+++ testsuite/gfortran.dg/vect/vect.exp (working copy)
@@ -26,7 +26,7 @@ set DEFAULT_VECTCFLAGS 

 # These flags are used for all targets.
 lappend DEFAULT_VECTCFLAGS -O2 -ftree-vectorize -fno-vect-cost-model \
-  -ftree-vectorizer-verbose=4 -fdump-tree-vect-stats
+  -fdump-tree-vect-details

 # If the target system supports vector instructions, the default action
 # for a test is 'run', otherwise it's 'compile'.  Save current default.
Index: testsuite/gcc.dg/tree-ssa/gen-vect-11.c
===
--- testsuite/gcc.dg/tree-ssa/gen-vect-11.c (revision 191883)
+++ testsuite/gcc.dg/tree-ssa/gen-vect-11.c (working copy)
@@ -1,6 +1,6 @@
 /* { dg-do run { target vect_cmdline_needed } } */
-/* { dg-options -O2 -ftree-vectorize -ftree-vectorizer-verbose=3
-fwrapv -fdump-tree-vect-stats } */
-/* { dg-options -O2 -ftree-vectorize -ftree-vectorizer-verbose=3
-fwrapv -fdump-tree-vect-stats -mno-sse { target { i?86-*-*
x86_64-*-* } } } */
+/* { dg-options -O2 -ftree-vectorize -fwrapv -fdump-tree-vect-details } */
+/* { dg-options -O2 -ftree-vectorize -fwrapv
-fdump-tree-vect-details -mno-sse { target { i?86-*-* x86_64-*-* } }
} */

 #include stdlib.h

Index: testsuite/gcc.dg/tree-ssa/gen-vect-2.c
===
--- testsuite/gcc.dg/tree-ssa/gen-vect-2.c (revision 191883)
+++ testsuite/gcc.dg/tree-ssa/gen-vect-2.c (working copy)
@@ -1,6 +1,6 @@
 /* { dg-do run { target vect_cmdline_needed } } */
-/* { dg-options -O2 -ftree-vectorize -ftree-vectorizer-verbose=4
-fdump-tree-vect-stats } */
-/* { dg-options -O2 -ftree-vectorize -ftree-vectorizer-verbose=4
-fdump-tree-vect-stats -mno-sse { target { i?86-*-* x86_64-*-* } } }
*/
+/* { dg-options -O2 -ftree-vectorize -fdump-tree-vect-details } */
+/* { dg-options -O2 -ftree-vectorize -fdump-tree-vect-details
-mno-sse { target { i?86-*-* x86_64-*-* } } } */

 #include stdlib.h

Index: testsuite/gcc.dg/tree-ssa/gen-vect-32.c
===
--- testsuite/gcc.dg/tree-ssa/gen-vect-32.c (revision 191883)
+++ testsuite/gcc.dg/tree-ssa/gen-vect-32.c (working copy)
@@ -1,6 +1,6 @@
 /* { dg-do run { target vect_cmdline_needed } } */
-/* { dg-options -O2 -ftree-vectorize -ftree-vectorizer-verbose=4
-fdump-tree-vect-stats } */
-/* { dg-options -O2 -ftree-vectorize -ftree-vectorizer-verbose=4
-fdump-tree-vect-stats -mno-sse { target { i?86-*-* x86_64-*-* } } }
*/
+/* { dg-options -O2 -ftree-vectorize -fdump-tree-vect-details } */
+/* { dg-options -O2 -ftree-vectorize -fdump-tree-vect-details
-mno-sse { target { i?86-*-* x86_64-*-* } } } */

 #include stdlib.h

Index: testsuite/gcc.dg/tree-ssa/gen-vect-25.c
===
--- testsuite/gcc.dg/tree-ssa/gen-vect-25.c (revision 191883)
+++ testsuite/gcc.dg/tree-ssa/gen-vect-25.c (working copy)
@@ -1,6 +1,6 @@
 /* { dg-do run { target vect_cmdline_needed } } */
-/* { dg-options -O2 -ftree-vectorize -ftree-vectorizer-verbose=4
-fdump-tree-vect-stats } */
-/* { dg-options -O2 -ftree-vectorize -ftree-vectorizer-verbose=4
-fdump-tree-vect-stats -mno-sse { target { i?86-*-* x86_64-*-* } } }
*/
+/* { dg-options -O2 -ftree-vectorize -fdump-tree-vect-details } */
+/* { dg-options -O2 -ftree-vectorize -fdump-tree-vect-details
-mno-sse { target { i?86-*-* x86_64-*-* } } } */

 #include stdlib.h

Index: testsuite/gcc.dg/tree-ssa/gen-vect-11a.c
===
--- testsuite/gcc.dg/tree-ssa/gen-vect-11a.c (revision 191883)
+++ testsuite/gcc.dg/tree-ssa/gen-vect-11a.c (working copy)
@@ -1,6 +1,6 @@
 /* { dg-do run { target vect_cmdline_needed } } */
-/* { dg-options -O2 -ftree-vectorize -ftree-vectorizer-verbose=3
-fdump-tree-vect-stats 

[v3] update doxygen config

[Benjamin De Kosnik]

to 1.8.2, yay, fixes for template aliases in!

tested x86/linux

-benjamindiff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog
index 9302b71..33a46cc 100644
--- a/libstdc++-v3/ChangeLog
+++ b/libstdc++-v3/ChangeLog
@@ -1,3 +1,7 @@
+2012-09-30  Benjamin Kosnik  b...@redhat.com
+
+	* doc/doxygen/user.cfg.in: Update to doxygen 1.8.2.
+
 2012-09-30  Jonathan Wakely  jwakely@gmail.com
 
 	* include/ext/ropeimpl.h (__uninitialized_fill_n_a): Fix using
diff --git a/libstdc++-v3/doc/doxygen/user.cfg.in b/libstdc++-v3/doc/doxygen/user.cfg.in
index b9fc4bf..3bf306f 100644
--- a/libstdc++-v3/doc/doxygen/user.cfg.in
+++ b/libstdc++-v3/doc/doxygen/user.cfg.in
@@ -1,4 +1,4 @@
-# Doxyfile 1.8.0
+# Doxyfile 1.8.2
 
 # This file describes the settings to be used by the documentation system
 # doxygen (www.doxygen.org) for a project.
@@ -126,7 +126,9 @@ FULL_PATH_NAMES= NO
 # only done if one of the specified strings matches the left-hand part of
 # the path. The tag can be used to show relative paths in the file list.
 # If left blank the directory from which doxygen is run is used as the
-# path to strip.
+# path to strip. Note that you specify absolute paths here, but also
+# relative paths, which will be relative from the directory where doxygen is
+# started.
 
 STRIP_FROM_PATH=
 
@@ -231,14 +233,15 @@ OPTIMIZE_FOR_FORTRAN   = NO
 OPTIMIZE_OUTPUT_VHDL   = NO
 
 # Doxygen selects the parser to use depending on the extension of the files it
-# parses. With this tag you can assign which parser to use for a given extension.
-# Doxygen has a built-in mapping, but you can override or extend it using this
-# tag. The format is ext=language, where ext is a file extension, and language
-# is one of the parsers supported by doxygen: IDL, Java, Javascript, CSharp, C,
-# C++, D, PHP, Objective-C, Python, Fortran, VHDL, C, C++. For instance to make
-# doxygen treat .inc files as Fortran files (default is PHP), and .f files as C
-# (default is Fortran), use: inc=Fortran f=C. Note that for custom extensions
-# you also need to set FILE_PATTERNS otherwise the files are not read by doxygen.
+# parses. With this tag you can assign which parser to use for a given
+# extension. Doxygen has a built-in mapping, but you can override or extend it
+# using this tag. The format is ext=language, where ext is a file extension,
+# and language is one of the parsers supported by doxygen: IDL, Java,
+# Javascript, CSharp, C, C++, D, PHP, Objective-C, Python, Fortran, VHDL, C,
+# C++. For instance to make doxygen treat .inc files as Fortran files (default
+# is PHP), and .f files as C (default is Fortran), use: inc=Fortran f=C. Note
+# that for custom extensions you also need to set FILE_PATTERNS otherwise the
+# files are not read by doxygen.
 
 EXTENSION_MAPPING  =
 
@@ -251,6 +254,13 @@ EXTENSION_MAPPING  =
 
 MARKDOWN_SUPPORT   = YES
 
+# When enabled doxygen tries to link words that correspond to documented classes,
+# or namespaces to their corresponding documentation. Such a link can be
+# prevented in individual cases by by putting a % sign in front of the word or
+# globally by setting AUTOLINK_SUPPORT to NO.
+
+AUTOLINK_SUPPORT   = YES
+
 # If you use STL classes (i.e. std::string, std::vector, etc.) but do not want
 # to include (a tag file for) the STL sources as input, then you should
 # set this tag to YES in order to let doxygen match functions declarations and
@@ -271,12 +281,7 @@ CPP_CLI_SUPPORT= NO
 
 SIP_SUPPORT= NO
 
-# For Microsoft's IDL there are propget and propput attributes to indicate getter
-# and setter methods for a property. Setting this option to YES (the default)
-# will make doxygen replace the get and set methods by a property in the
-# documentation. This will only work if the methods are indeed getting or
-# setting a simple type. If this is not the case, or you want to show the
-# methods anyway, you should set this option to NO.
+# For Microsoft's IDL there are propget and propput attributes to indicate getter and setter methods for a property. Setting this option to YES (the default) will make doxygen replace the get and set methods by a property in the documentation. This will only work if the methods are indeed getting or setting a simple type. If this is not the case, or you want to show the methods anyway, you should set this option to NO.
 
 IDL_PROPERTY_SUPPORT   = NO
 
@@ -300,7 +305,8 @@ SUBGROUPING= YES
 # @ingroup) instead of on a separate page (for HTML and Man pages) or
 # section (for LaTeX and RTF).
 
-INLINE_GROUPED_CLASSES = NO
+#INLINE_GROUPED_CLASSES = NO
+INLINE_GROUPED_CLASSES = YES
 
 # When the INLINE_SIMPLE_STRUCTS tag is set to YES, structs, classes, and
 # unions with only public data fields will be shown inline in the documentation
@@ -308,7 +314,7 @@ INLINE_GROUPED_CLASSES = NO
 # documentation), provided this scope is documented. If set to NO (the default),
 # structs, classes, and unions are shown on a 

Re: profitable_hard_regs vs. PR 48435

[Vladimir Makarov]

On 12-09-30 2:42 PM, Richard Sandiford wrote:

This is another patch needed for the MIPS MD_REGS change described here:

 http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01992.html

The profitable_hard_regs set used during IRA colouring used to be restricted
to registers that are valid for the allocno's mode.  That caused problems
for multi-register modes that can only start with an even register (say),
because profitable_hard_regs would only include the even start registers,
not the pairing odd registers.  Vlad fixed it with:

2011-04-08  Vladimir Makarov  vmaka...@redhat.com

PR inline-asm/48435
* ira-color.c (setup_profitable_hard_regs): Add comments.
Don't take prohibited hard regs into account.
(setup_conflict_profitable_regs): Rename to
get_conflict_profitable_regs.
(check_hard_reg_p): Check prohibited hard regs.

However, one effect of that change is that if register R belongs to class CL
but can never be used anywhere in a register of mode M, it will still be
included in profitable_hard_regs.  That's the case with MD_REGS and
register HI on MIPS.

The patch below is a half-way house between the original behaviour
and the post-48435 one.  It restricts profitable_hard_regs to registers
that can be used for the allocno's mode, but doesn't restrict it to
starting registers.

Most of the ira.c change is reindentation, so I've included a -b
diff as well.

As with the patch linked above, I checked that this produced no
difference in assembly output for a set of x86_64 gcc .ii files
(tested with -O2 -march=native on gcc20).  Also tested on
x86_64-linux-gnu (including -m32) and mipsisa64-elf.  OK to install?



gcc/
* ira-int.h (target_ira_int): Add x_ira_useful_class_mode_regs.
(ira_useful_class_mode_regs): New macro.
* ira.c (clarify_prohibited_class_mode_regs): Set up
ira_useful_class_mode_regs.
* ira-color.c (setup_profitable_hard_regs): Use it to initialise
profitable_hard_regs.

Ok. thanks, Richard.

Various minor C++ PATCHes

[Jason Merrill]

1) I wanted a lang-specific flag for my thread_local work, so I took the 
one away from __PRETTY_FUNCTION__, which really doesn't need it.


2) I didn't end up wanting to use a flag in DECL_LANG_SPECIFIC, but it
still makes sense to check for appropriate tree codes in DECL_FRIEND_P 
and DECL_ANTICIPATED.


3) DECL_NONTRIVIALLY_INITIALIZED_P currently means has a user-written 
initializer and it would be more useful to me if it actually meant has 
non-trivial initialization so that a non-trivial default constructor 
counts even if there is nothing written in the variable declaration. 
The one existing reader of this flag seems to agree with me.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit 6c286ba0a085136d7efecd6d70d0cf96a4e8386a
Author: Jason Merrill ja...@redhat.com
Date:   Wed Sep 26 12:14:15 2012 -0400

	* cp-tree.h (DECL_PRETTY_FUNCTION_P): Just look at the name.
	* decl.c (cp_make_fname_decl): Adjust.

diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
index 9298e3d..cefe92d 100644
--- a/gcc/c-family/c-common.h
+++ b/gcc/c-family/c-common.h
@@ -45,7 +45,6 @@ never after.
 
 /* Usage of TREE_LANG_FLAG_?:
0: IDENTIFIER_MARKED (used by search routines).
-  DECL_PRETTY_FUNCTION_P (in VAR_DECL)
   C_MAYBE_CONST_EXPR_INT_OPERANDS (in C_MAYBE_CONST_EXPR, for C)
1: C_DECLARED_LABEL_FLAG (in LABEL_DECL)
   STATEMENT_LIST_STMT_EXPR (in STATEMENT_LIST)
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index f437022..cee8590 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -56,7 +56,6 @@ c-common.h, not after.
   AGGR_INIT_VIA_CTOR_P (in AGGR_INIT_EXPR)
   PTRMEM_OK_P (in ADDR_EXPR, OFFSET_REF, SCOPE_REF)
   PAREN_STRING_LITERAL (in STRING_CST)
-  DECL_PRETTY_FUNCTION_P (in VAR_DECL)
   KOENIG_LOOKUP_P (in CALL_EXPR)
   STATEMENT_LIST_NO_SCOPE (in STATEMENT_LIST).
   EXPR_STMT_STMT_EXPR_RESULT (in EXPR_STMT)
@@ -2410,7 +2409,8 @@ struct GTY((variable_size)) lang_decl {
 /* Nonzero if this DECL is the __PRETTY_FUNCTION__ variable in a
template function.  */
 #define DECL_PRETTY_FUNCTION_P(NODE) \
-  (TREE_LANG_FLAG_0 (VAR_DECL_CHECK (NODE)))
+  (DECL_NAME (NODE) \
+!strcmp (IDENTIFIER_POINTER (DECL_NAME (NODE)), __PRETTY_FUNCTION__))
 
 /* The _TYPE context in which this _DECL appears.  This field holds the
class where a virtual function instance is actually defined.  */
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 078b148..d4c78e1 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -3829,7 +3829,6 @@ cp_make_fname_decl (location_t loc, tree id, int type_dep)
 
   /* As we're using pushdecl_with_scope, we must set the context.  */
   DECL_CONTEXT (decl) = current_function_decl;
-  DECL_PRETTY_FUNCTION_P (decl) = type_dep;
 
   TREE_STATIC (decl) = 1;
   TREE_READONLY (decl) = 1;
commit 21960ac8d1debe452eef3776fe2d638fa55dbe52
Author: Jason Merrill ja...@redhat.com
Date:   Wed Sep 26 12:19:21 2012 -0400

	* cp-tree.h (TYPE_FUNCTION_OR_TEMPLATE_DECL_CHECK): New.
	(DECL_FRIEND_P, DECL_ANTICIPATED): Use it.
	(TYPE_FUNCTION_OR_TEMPLATE_DECL_P): New.
	* name-lookup.c (hidden_name_p): Use it.

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index cee8590..e4f3761 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -202,6 +202,13 @@ c-common.h, not after.
 #define VAR_OR_FUNCTION_DECL_CHECK(NODE) \
   TREE_CHECK2(NODE,VAR_DECL,FUNCTION_DECL)
 
+#define TYPE_FUNCTION_OR_TEMPLATE_DECL_CHECK(NODE) \
+  TREE_CHECK3(NODE,TYPE_DECL,TEMPLATE_DECL,FUNCTION_DECL)
+
+#define TYPE_FUNCTION_OR_TEMPLATE_DECL_P(NODE) \
+  (TREE_CODE (NODE) == TYPE_DECL || TREE_CODE (NODE) == TEMPLATE_DECL \
+   || TREE_CODE (NODE) == FUNCTION_DECL)
+
 #define VAR_FUNCTION_OR_PARM_DECL_CHECK(NODE) \
   TREE_CHECK3(NODE,VAR_DECL,FUNCTION_DECL,PARM_DECL)
 
@@ -1875,8 +1882,8 @@ struct GTY(()) lang_decl_base {
   unsigned initialized_in_class : 1;	   /* var or fn */
   unsigned repo_available_p : 1;	   /* var or fn */
   unsigned threadprivate_or_deleted_p : 1; /* var or fn */
-  unsigned anticipated_p : 1;		   /* fn or type */
-  unsigned friend_attr : 1;		   /* fn or type */
+  unsigned anticipated_p : 1;		   /* fn, type or template */
+  unsigned friend_attr : 1;		   /* fn, type or template */
   unsigned template_conv_p : 1;		   /* var or template */
   unsigned odr_used : 1;		   /* var or fn */
   unsigned u2sel : 1;
@@ -2293,7 +2300,9 @@ struct GTY((variable_size)) lang_decl {
 
 /* Nonzero for DECL means that this decl is just a friend declaration,
and should not be added to the list of members for this class.  */
-#define DECL_FRIEND_P(NODE) (DECL_LANG_SPECIFIC (NODE)-u.base.friend_attr)
+#define DECL_FRIEND_P(NODE) \
+  (DECL_LANG_SPECIFIC (TYPE_FUNCTION_OR_TEMPLATE_DECL_CHECK (NODE)) \
+   -u.base.friend_attr)
 
 /* A TREE_LIST of the types which have befriended this FUNCTION_DECL.  */
 #define DECL_BEFRIENDING_CLASSES(NODE) \
@@ -3101,7 +3110,8 @@ more_aggr_init_expr_args_p (const aggr_init_expr_arg_iterator *iter)

Re: [patch][lra] a few bitmap obstacks for lra-assigns

[Vladimir Makarov]

On 12-10-01 6:02 PM, Steven Bosscher wrote:

Hello,

This eliminates a few large loops in lra-assigns.c. They're not the
most costly loops but the life times of the bitmaps is well-defined
and destroying a bitmap obstack is much cheaper than looping over all
bitmaps calling bitmap_clear. The saving is small but you have to
start somewhere...

Bootstrapped lra-branch and tested on x86_64-unknown-linux-gnu, along
with the patch from earlier today. OK for the branch?


Ok.  Thanks, Steven.

Re: [v3] libstdc++/54314

[Benjamin De Kosnik]

 
 adds in exports for more vtable bits, as per bugzilla

missed some, added here and tested with:

 tested x86/linux --enable-symvers=gnu-versioned-namespace

-benjamin2012-10-01  Benjamin Kosnik  b...@redhat.com

	* config/abi/pre/gnu-versioned-namespace.ver: Add more
	typeinfo/vtable exports.

diff --git a/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver b/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
index 5f25374..84210e4 100644
--- a/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
+++ b/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
@@ -62,15 +62,18 @@ GLIBCXX_7.0 {
 _ZTTNSt*;
 
 # vtable
+_ZTVSt*;
 _ZTVNSt*;
 
 # thunk
 _ZTv0_n24_NS*;
 
 # typeinfo structure
+_ZTISt*;
 _ZTINSt*;
 
 # typeinfo name
+_ZTSSt*;
 _ZTSNSt*;
 
 # locale

Re: PR 53889: Add __gthread_recursive_mutex_destroy

[Jonathan Wakely]

On 1 October 2012 20:22, Ian Lance Taylor wrote:
 On Sun, Sep 30, 2012 at 11:41 AM, Jonathan Wakely jwakely@gmail.com 
 wrote:
 There is no __gthread_recursive_mutex_destroy function in the gthreads API.

 Trying to use __gthread_mutex_destroy fails to compile on platforms
 where the mutex
 types are different. To avoid resource leaks libstdc++ needs to hack
 around the missing function with overloaded functions and SFINAE
 tricks to detect how a recursive mutex can be destroyed.

 This patch extends the gthreads API to include
 __gthread_recursive_mutex_destroy, defining it for each gthread model,
 and removing the hacks from libstdc++.

 +return rtems_gxx_mutex_destroy( __mutex );

 Space before '(', not space after.

Oops, yes.

 Doing anything else here is going to be painful, but this assumes that
 RTEMS uses the same representation for non-recursive and recursive
 mutexes.  That is currently true, but it deserves a comment.

Good point ... I have a vague recollection that I looked into it and
decided they were the same, but I wrote this patch back in July and
don't remember the details. If anyone knows better please let me know.
The attached revised patch adds a comment.

 --- a/libgcc/config/i386/gthr-win32.h
 +++ b/libgcc/config/i386/gthr-win32.h
 +static inline void
 +__gthread_recursive_mutex_destroy (__gthread_recursive_mutex_t *mutex)
 +{
 +  __gthread_mutex_t __mutex2;
 +  __mutex2.sema = mutex-sema;
 +  __gthr_win32_mutex_destroy (__mutex2);
 +}

 I think it would be better to put this in
 libgcc/config/i386/gthr-win32.c, like the other functions.  Then you
 can just call CloseHandle.

Done. I've also made __gthread_recursive_mutex_destroy return int,
unlike the Win32 __ghtread_mutex_destroy (see PR 53888 for that)


 --- a/libgcc/config/mips/gthr-mipssde.h
 +++ b/libgcc/config/mips/gthr-mipssde.h

 +static inline int
 +__gthread_recursive_mutex_destroy (__gthread_recursive_mutex_t *__mutex)
 +{
 +  return __gthread_mutex_destroy(__mutex);
 +}

 Will this even compile?  It doesn't look like it.

Nope, you're right.

I've replaced it with this, which is all __ghtread_mutex_destroy does anyway:

static inline int
__gthread_recursive_mutex_destroy (__gthread_recursive_mutex_t
   * UNUSED(__mutex))
{
  return 0;
}

Is that indentation right?  (the asterisk is in the same column as the
parameter type in a fixed-width font.)

Thanks for the careful review.

The ChangeLog entry is the same, I haven't rested this because the
changes since the first patch are only to targets I don't have access
to.

libgcc:

PR other/53889
* gthr.h (__gthread_recursive_mutex_destroy): Document new required
function.
* gthr-posix.h (__gthread_recursive_mutex_destroy): Define.
* gthr-single.h (__gthread_recursive_mutex_destroy): Likewise.
* config/gthr-rtems.h (__gthread_recursive_mutex_destroy): Likewise.
* config/gthr-vxworks.h (__gthread_recursive_mutex_destroy): Likewise.
* config/i386/gthr-win32.h (__gthread_recursive_mutex_destroy):
Likewise.
* config/mips/gthr-mipssde.h (__gthread_recursive_mutex_destroy):
Likewise.
* config/pa/gthr-dce.h (__gthread_recursive_mutex_destroy): Likewise.
* config/s390/gthr-tpf.h (__gthread_recursive_mutex_destroy): Likewise.

libstdc++-v3:

PR other/53889
* include/std/mutex (__recursive_mutex_base::~__recursive_mutex_base):
Use __gthread_recursive_mutex_destroy.
(__recursive_mutex_base::_S_destroy): Remove.
(__recursive_mutex_base::_S_destroy_win32): Likewise.
* include/ext/concurrence.h (__recursive_mutex::~__recursive_mutex):
Use __gthread_recursive_mutex_destroy.
(__recursive_mutex::_S_destroy): Remove.
(__recursive_mutex::_S_destroy_win32): Likewise.
commit 7877201b61694279811c0276c92d85aaec2b30a2
Author: Jonathan Wakely jwakely@gmail.com
Date:   Tue Oct 2 01:40:46 2012 +0100

libgcc:

PR other/53889
* gthr.h (__gthread_recursive_mutex_destroy): Document new required
function.
* gthr-posix.h (__gthread_recursive_mutex_destroy): Define.
* gthr-single.h (__gthread_recursive_mutex_destroy): Likewise.
* config/gthr-rtems.h (__gthread_recursive_mutex_destroy): Likewise.
* config/gthr-vxworks.h (__gthread_recursive_mutex_destroy): Likewise.
* config/i386/gthr-win32.h (__gthread_recursive_mutex_destroy):
Likewise.
* config/mips/gthr-mipssde.h (__gthread_recursive_mutex_destroy):
Likewise.
* config/pa/gthr-dce.h (__gthread_recursive_mutex_destroy): Likewise.
* config/s390/gthr-tpf.h (__gthread_recursive_mutex_destroy): Likewise.

libstdc++-v3:

PR other/53889
* include/std/mutex (__recursive_mutex_base::~__recursive_mutex_base):
Use __gthread_recursive_mutex_destroy.
(__recursive_mutex_base::_S_destroy): Remove.

Re: RFC: LRA for x86/x86-64 [0/9]

[Vladimir Makarov]

On 12-10-01 4:24 PM, Steven Bosscher wrote:

On Mon, Oct 1, 2012 at 9:51 PM, Vladimir Makarov vmaka...@redhat.com wrote:

I think it's more important in this case to recognize Steven's real
point, which is that for an identical situation (IRA), and with an
identical patch author, we had similar bugs.  They were promised to be
worked on, and yet some of those regressions are still very much with
us.

That is not true.  I worked on many compiler time regression bugs. I remeber
one serious degradation of compilation time on all_cp2k_gfortran.f90.  I
solved the problem and make IRA working faster and generating much better
code than the old RA.

http://blog.gmane.org/gmane.comp.gcc.patches/month=20080501/page=15

About other two mentioned PRs by Steven:

PR26854.  I worked on this bug even when IRA was on the branch and make
again GCC with IRA 5% faster on this test than GCC with the old RA.

PR 54146 is 3 months old.  There were a lot work on other optimizations
before IRA became important.  It happens only 2 months ago. I had no time to
work on it but I am going to.

This is also not quite true, see PR37448, which shows the problems as
the test case for PR54146.
I worked on this PR too and did some progress but it was much less than 
on other PRs.


Sometimes I think that I should have maintained the old RA to compare 
with it and show that IRA is still a step ahead. Unfortunately, 
comparison with old releases has no sense now because more aggressive 
optimizations (inlining).

I just think scalability is a very important issue. If some pass or
algorithm scales bad on some measure, then users _will_ run into that
at some point and report bugs about it (if you're lucky enough to have
a user patient enough to sit out the long compile time :-) ). Also,
good scalability opens up opportunities. For example, historically GCC
has been conservative on inlining heuristics to avoid compile time
explosions. I think it's better to address the causes of that
explosion and to avoid introducing new potential bottlenecks.
As I wrote, scalability sometimes misleading as in case PR (a Scheme 
interpreter) where 30% more compilation time with LRA is translated into 
15% decrease in code size and most probably better performance.  Now we 
can manage to achieve scalability with worse performance but that is not 
what user expects and even worse he did know it.  It is even a bigger 
problem IMO.


Ideally, we should have more scalable algorithms as fallback but we 
should warn the programmer that worse performance algorithms are used 
and he could achieve a better performance by dividing a huge function 
into several ones.



People sometimes see that RA takes a lot of compilation time but it is in
the nature of RA.  I'd recommend first to check how the old RA behaves and
then call it a degradation.

There's no question that RA is one of the hardest problems the
compiler has to solve, being NP-complete and all that. I like LRA's
iterative approach, but if you know you're going to solve a hard
problem with a number potentially expensive iterations, there's even
more reason to make scalability a design goal!
When I designed IRA I kept this goal in my mind too.  Although my first 
priority was the performance.  The old RA was ok when the register 
pressure was not high.  I knew aggressive inlining and LTO were coming.  
And my goal was to design RA generating a good code for bigger programs 
with much higher register pressure where the old RA drawbacks would be 
obvious.

As I said earlier in this thread, I was really looking forward to IRA
at the time you worked on it, because it is supposed to be a regional
allocator and I had expected that to mean it could, well, allocate
per-region which is usually very helpful for scalability (partition
your function and insert compensation code on strategically picked
region boundaries). But that's not what IRA has turned out to be.
(Instead, its regional nature is one of the reasons for its
scalability problems.)  IRA is certainly not worse than old global.c
in very many ways, and LRA looks like a well thought-through and
welcome replacement of old reload. But scalability is an issue in the
design of IRA and LRA looks to be the same in that regard.
Regional allocator means that allocation is made taking mostly a region 
into account to achieve a better allocation.  But a good regional RA 
(e.g. Callahan-Koblenz or Intel fusion based RA) takes interactions with 
other regions too and such allocators might be even slower than 
non-regional.  Although I should say that in my impressions CK-allocator 
(I tried and implemented this about 6 years ago) is probably better 
scalable than IRA but it generates worse code.

Re: RFC: LRA for x86/x86-64 [0/9]

[Vladimir Makarov]

On 10/01/2012 09:03 AM, Steven Bosscher wrote:

On Sat, Sep 29, 2012 at 10:26 PM, Steven Bosscher stevenb@gmail.com wrote:

  LRA create live ranges  : 175.30 (15%) usr   2.14 (13%) sys 177.44
(15%) wall2761 kB ( 0%) ggc

I've tried to split this up a bit more:

process_bb_lives ~50%
create_start_finish_chains ~25%
remove_some_program_points_and_update_live_ranges ~25%

The latter two have a common structure with loops that look like this:

   for (i = FIRST_PSEUDO_REGISTER; i  max_regno; i++)
 {
   for (r = lra_reg_info[i].live_ranges; r != NULL; r = r-next)

Perhaps it's possible to do some of the work of compress_live_ranges
during process_bb_lives, to create shorter live_ranges chains.
  It is aready done.  Moreover program points are compressed to minimal 
to guarantee right conflict resolution.  For example, if only 2 pseudos 
live in 1..10 and 2..14, they actually will have the same range like 1..1.


  Analogous live ranges are used in IRA as intermidiate step to build a 
conflict graph.  Actually, the first approach was to use IRA code to 
assign hard registers to pseudos (e.g.  Jeff Law tried this approach) 
but it was rejected as requiring much more compilation time.  In some 
way, one can look at the assignment in LRA is a compromise between 
quality (which could achieved through repeated buidling conflict graphs 
and using graph coloring) and compilation speed.

Also, maybe doing something else than a linked list of live_ranges
will help (unfortunately that's not a trivial change, it seems,
because the lra_live_range_t type is used everywhere and there are no
iterators or anything abstracted out like that -- just chain
walks...).

Still it does seem to me that a sorted VEC of lra_live_range objects
probably would speed things up. Question is of course how much... :-)

  My experience shows that these lists are usually 1-2 elements. 
Although in this case, there are pseudos with huge number elements 
(hundreeds).  I tried -fweb for this tests because it can decrease the 
number elements but GCC (I don't know what pass) scales even worse: 
after 20 min of waiting and when virt memory achieved 20GB I stoped it.


   I guess the same speed or close to reload one on this test can be 
achieved through implementing other simpler algorithms generating worse 
code.  I need some time to design them and implement this.

Re: [PATCH v2, rtl-optimization]: Fix PR54457, [x32] Fail to combine 64bit index + constant

[Andrew Pinski]

On Thu, Sep 27, 2012 at 11:13 AM, Uros Bizjak ubiz...@gmail.com wrote:
 On Thu, Sep 27, 2012 at 8:08 PM,  paul_kon...@dell.com wrote:

 I agree (subreg:M (op:N A C) 0) to (op:M (subreg:N (A 0)) C) is
 a good transformation, but why do we need to handle as special
 the case where the subreg is itself the operand of a plus or minus?
 I think it should happen regardless of where the subreg occurs.

 Don't we need to restrict this to the low part though?

 ...

 After some off-line discussion with Richard, attached is v2 of the patch.

 2012-09-27  Uros Bizjak  ubiz...@gmail.com

PR rtl-optimization/54457
* simplify-rtx.c (simplify_subreg):
   Simplify (subreg:SI (op:DI ((x:DI) (y:DI)), 0)
   to (op:SI (subreg:SI (x:DI) 0) (subreg:SI (x:DI) 0)).
 ...

 Is it just specific to DI - SI, or is it for any large mode - smaller 
 mode, like SI - HI?

 Oh, I just copied v1 ChangeLog. The patch converts all modes where
 size of mode M  size of mode N. Updated ChangeLog reads:

 2012-09-27  Uros Bizjak  ubiz...@gmail.com

 PR rtl-optimization/54457
 * simplify-rtx.c (simplify_subreg):
 Simplify (subreg:M (op:N ((x:N) (y:N)), 0)
 to (op:M (subreg:M (x:N) 0) (subreg:M (x:N) 0)), where
 the outer subreg is effectively a truncation to the original mode M.


When I was doing something similar on our internal toolchain at
Cavium.  I found doing this caused a regression on MIPS64 n32 in
gcc.c-torture/execute/20040709-1.c Where:


(insn 15 14 16 2 (set (reg/v:DI 200 [ y ])
(reg:DI 2 $2)) t.c:16 301 {*movdi_64bit}
 (expr_list:REG_DEAD (reg:DI 2 $2)
(nil)))

(insn 16 15 17 2 (set (reg:DI 210)
(zero_extract:DI (reg/v:DI 200 [ y ])
(const_int 29 [0x1d])
(const_int 0 [0]))) t.c:16 249 {extzvdi}
 (expr_list:REG_DEAD (reg/v:DI 200 [ y ])
(nil)))

(insn 17 16 23 2 (set (reg:SI 211)
(truncate:SI (reg:DI 210))) t.c:16 175 {truncdisi2}
 (expr_list:REG_DEAD (reg:DI 210)
(nil)))

Gets converted to:
(insn 23 17 26 2 (set (reg/i:SI 2 $2)
(and:SI (reg:SI 2 $2 [+4 ])
(const_int 536870911 [0x1fff]))) t.c:18 156 {*andsi3}
 (nil))

Which is considered an ext instruction

And with the Octeon simulator which causes undefined arguments to
32bit word operations to come out as 0xDEADBEEF which showed the
regression.  I fixed it by changing it to produce TRUNCATE instead of
the subreg.

I did the simplification on ior/and rather than plus/minus/mult so the
issue is only when expanding to this to and/ior.

Thanks,
Andrew Pinski




 testsuite/ChangeLog:

 2012-09-27  Uros Bizjak  ubiz...@gmail.com

 PR rtl-optimization/54457
 * gcc.target/i386/pr54457.c: New test.

 Uros.

Re: RFC: LRA for x86/x86-64 [0/9]

[Jeff Law]

On 10/01/2012 07:14 PM, Vladimir Makarov wrote:


   Analogous live ranges are used in IRA as intermidiate step to build a
conflict graph.  Actually, the first approach was to use IRA code to
assign hard registers to pseudos (e.g.  Jeff Law tried this approach)
but it was rejected as requiring much more compilation time.  In some
way, one can look at the assignment in LRA is a compromise between
quality (which could achieved through repeated buidling conflict graphs
and using graph coloring) and compilation speed.
Not only was it slow (iterating IRA), guaranteeing termination was a 
major problem.  There's some algorithmic games that have to be played 
(they're at least discussed in literature, but not under the heading of 
termination) and there's some issues specific to the IRA implementation 
which make ensuring termination difficult.


I got nearly as good of results by conservative updates of the conflicts 
after splitting ranges and (ab)using ira's reload hooks to give the new 
pseudos for the split range a chance to be allocated again.


The biggest problem with that approach was getting the costing right for 
the new pseudos.  That requires running a fair amount of IRA a second 
time.  I'd still like to return to some of the ideas from that work as I 
think some of the bits are still relevant in the IRA+LRA world.



   My experience shows that these lists are usually 1-2 elements.
That's been my experience as well.  The vast majority of the time the 
range lists are very small.


Jeff

Re: RFC: LRA for x86/x86-64 [9/9]

[Jeff Law]

On 09/27/2012 04:59 PM, Vladimir Makarov wrote:

This is the last patch switching on LRA for x86/x86-64.  The patch also
contains code deciding when to use spilling general regs into SSE
instead of memory.

2012-09-27  Vladimir Makarov  vmaka...@redhat.com

 * config/i386/i386.h (enum ix86_tune_indices): Add
 X86_TUNE_GENERAL_REGS_SSE_SPILL.
 (TARGET_GENERAL_REGS_SSE_SPILL): New macro.
 * config/i386/i386.c (initial_ix86_tune_features): Set up
 X86_TUNE_GENERAL_REGS_SSE_SPILL for m_COREI7 and
 m_CORE2I7.
 (ix86_lra_p, ix86_register_bank): New functions.
 (ix86_secondary_reload): Add NON_Q_REGS, SIREG, DIREG.
 (inline_secondary_memory_needed): Change assert.
 (ix86_spill_class, ix86_spill_class_mode): New function.
 (TARGET_LRA_P, TARGET_REGISTER_BANK, TARGET_SPILL_CLASS): New macros.
 (TARGET_SPILL_CLASS_MODE): New macro.

So for the register_bank stuff, aren't we really just defining some kind 
of alternate costing model?  ie, we can't really get the costs we want 
from register classes, but it's dependent on the precise register used.


I guess I'm rethinking if register bank is the right name.

Otherwise it seems reasonable.  Looks like there's an extra newline at EOF.

jeff

Re: RFC: LRA for x86/x86-64 [8/9]

[Jeff Law]

On 09/27/2012 04:59 PM, Vladimir Makarov wrote:

   The following patch adds a code neccessary for correct work of LRA
(function ira_setup_eliminable_regset) and for correct work of the
compiler when LRA is used (see file dwarf2out.c).

2012-09-27  Vladimir Makarov  vmaka...@redhat.com

 * loop-invariant.c (calculate_loop_reg_pressure): Pass new
 argument to ira_setup_eliminable_regset.
 * haifa-sched.c (sched_init): Pass new argument to
 ira_setup_eliminable_regset.
 * dwarf2out.c: Include lra.h.
 (based_loc_descr, compute_frame_pointer_to_fb_displacement): Use
 lra_eliminate_regs for LRA instead of eliminate_regs.
 * ira.c: (ira_setup_eliminable_regset): Add parameter. Remove
 need_fp.  Call lra_init_elemination and mark
 HARD_FRAME_POINTER_REGNUM as living forever if
 frame_pointer_needed.
 (ira): Call ira_setup_eliminable_regset with a new
 argument.
 * ira.h (ira_setup_eliminable_regset): Add an argument.
 * Makefile.in (dwarf2out.o): Add dependence on ira.h and lra.h.

This is OK.  Obviously it's useless without 7a/7b.  But I just wanted to 
go ahead and review the ancillary bits before going to the meat of the 
submission.


So it's just the 7a/7b patch that needs review, right?

jeff