Re: [PATCH] Preserve loops from tree to RTL loop optimizers
On 1 April 2012 23:55, David Edelsohn dje@gmail.com wrote: If there are no further comments I am inclined to commit this patch early next week (possibly causing quite some fallout ...). I am glad there was not more fallout. Unfortunately powerpc-aix was not so lucky: /farm/dje/src/src/libstdc++-v3/src/c++98/streambuf.cc: In function 'std::streamsize std::__copy_streambufs_eof(std::basic_streambuf_CharT, _Traits*, std::basic_streambuf_CharT, _Traits*, bool) [with _CharT = wchar_t; _Traits = std::char_traitswchar_t; std::streamsize = long int]': /farm/dje/src/src/libstdc++-v3/src/c++98/streambuf.cc:113:5: internal compiler error: in get_loop_body, at cfgloop.c:831 This looks similar to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52800 Ramana
Re: [Patch V2] libgfortran: do not assume libm
On Mar 30, 2012, at 2:39 PM, Paolo Bonzini wrote: Il 30/03/2012 12:22, Tristan Gingold ha scritto: On Mar 27, 2012, at 10:38 AM, Janne Blomqvist wrote: On Tue, Mar 27, 2012 at 11:01, Tristan Gingold ging...@adacore.com wrote: Hi, this patch fixes this issue. Is it OK ? Ok. Maybe we should include the AC_DEFINE action within GCC_CHECK_MATH_FUNC. Will try to do that. That looks like a cleaner solution, yes, and less chance for typos to sneak in. Hi, here is the 'cleaner solution': now GCC_CHECK_MATH_FUNC automatically define the HAVE_xxx variable. The description is now: Define to 1 if you have the `xxx' function. As a consequence, libgfortran/config.h.in was regenerated (with differences like: -/* acos is available */ +/* Define to 1 if you have the `acos' function. */ #undef HAVE_ACOS ) Tested by rebuild libgfortran for ia64-hp-openvms and visual inspection of differences. I have CC: Paolo as he approved the first version of math.m4. Ok for trunk ? Yes. Thanks, committed. Tristan.
Re: [libiberty] Avoid compiler warnings in stack-limit.c
On Mar 30, 2012, at 5:46 PM, Ian Lance Taylor wrote: Tristan Gingold ging...@adacore.com writes: 2012-03-30 Tristan Gingold ging...@adacore.com * stack-limit.c: Includes ansidecl.h. (stack_limit_increase): Add ATTRIBUTE_UNUSED This is OK. Thanks, committed. Tristan. Thanks. Ian
Re: [Patch]: ggc-page.c: use uintptr_t instead of size_t
On Mar 30, 2012, at 7:44 PM, Richard Henderson wrote: On 03/20/2012 05:41 AM, Tristan Gingold wrote: 2012-03-20 Tristan Gingold ging...@adacore.com * ggc-page.c (PAGE_L1_SIZE, PAGE_L2_SIZE, LOOKUP_L1, LOOKUP_L2) (ggc_allocated_p, lookup_page_table_entry, set_page_table_entry) (alloc_page, init_ggc, clear_marks, struct ggc_pch_data) (ggc_pch_this_base): Use uintptr_t instead of size_t. Ok. Thanks, committed. Tristan.
Re: [PATCH]: Restore alpha boostrap by partial revert
On Sat, 31 Mar 2012, Uros Bizjak wrote: Hello! Attached patch restores alpha bootstrap. 2012-03-31 Uros Bizjak ubiz...@gmail.com Partially revert: 2012-03-29 Richard Guenther rguent...@suse.de * rtl.h (extended_count): Remove. * combine.c (extended_count): Remove. Bootstrapped on alphaev68-pc-linux-gnu. OK for mainline? As alpha is the only user and this does not look in any way combine specific, can you move it to alpha.c instead please? Thanks, Richard.
Re: [PATCH]: Restore alpha boostrap by partial revert
On Mon, Apr 2, 2012 at 10:21 AM, Richard Guenther rguent...@suse.de wrote: 2012-03-31 Uros Bizjak ubiz...@gmail.com Partially revert: 2012-03-29 Richard Guenther rguent...@suse.de * rtl.h (extended_count): Remove. * combine.c (extended_count): Remove. Bootstrapped on alphaev68-pc-linux-gnu. OK for mainline? As alpha is the only user and this does not look in any way combine specific, can you move it to alpha.c instead please? This was the first thing I thought, but the function uses nonzero_sign_valid, a variable local to combine.c Uros.
Re: [PATCH]: Restore alpha boostrap by partial revert
On Mon, 2 Apr 2012, Uros Bizjak wrote: On Mon, Apr 2, 2012 at 10:21 AM, Richard Guenther rguent...@suse.de wrote: 2012-03-31 Uros Bizjak ubiz...@gmail.com Partially revert: 2012-03-29 Richard Guenther rguent...@suse.de * rtl.h (extended_count): Remove. * combine.c (extended_count): Remove. Bootstrapped on alphaev68-pc-linux-gnu. OK for mainline? As alpha is the only user and this does not look in any way combine specific, can you move it to alpha.c instead please? This was the first thing I thought, but the function uses nonzero_sign_valid, a variable local to combine.c Hmm, how ugly ;) Your patch is ok then. Sorry for the breakage. Richard.
[Ada] Implement Valid_Scalars attribute (except for variant records)
This patch implements the new Valid_Scalars attribute (that tests all scalar parts of an object including discriminabnts and subcomponents, to ensure they are valid. All cases are handled (including multi- dimensional arrays) except for variant records which will be implemented in a separate step. The following shows warnings that are generated (compiled with -gnatc, -gnatld7 -gnatj60) 1. package ValidScalarsW is 2.type Ptr is access Integer; 3. 4.type Rec is tagged record 5. A, B : Ptr; 6.end record; 7. 8.type RecN is new Rec with record 9. X : Integer; 10.end record; 11. 12.type Arr is array (1 .. 10) of Ptr; 13. 14.V1 : Ptr; 15.V2 : Rec; 16.V3 : Rec'Class := V2; 17.V4 : Arr; 18. 19.M1 : Boolean := V1'Valid_Scalars; | warning: attribute Valid_Scalars always True, no scalars to check 20.M2 : Boolean := V2'Valid_Scalars; | warning: attribute Valid_Scalars always True, no scalars to check 21.M3 : Boolean := V3'Valid_Scalars; | warning: attribute Valid_Scalars always True, no scalars to check 22.M4 : Boolean := V4'Valid_Scalars; | warning: attribute Valid_Scalars always True, no scalars to check 23. end ValidScalarsW; Tested on x86_64-pc-linux-gnu, committed on trunk 2012-04-02 Robert Dewar de...@adacore.com * einfo.adb (First_Component_Or_Discriminant) Now applies to all types with discriminants, not just records. * exp_attr.adb (Expand_N_Attribute): Add Scalar_Values handling for arrays, scalars and non-variant records. * sem_attr.adb (Analyze_Attribute): Handle Valid_Scalars * sem_attr.ads (Valid_Scalars): Update description * sem_util.ads, sem_util.adb (No_Scalar_Parts): New function. Index: exp_attr.adb === --- exp_attr.adb(revision 186067) +++ exp_attr.adb(working copy) @@ -76,6 +76,14 @@ -- Local Subprograms -- --- + function Build_Array_VS_Func + (A_Type : Entity_Id; + Nod: Node_Id) return Entity_Id; + -- Build function to test Valid_Scalars for array type A_Type. Nod is the + -- Valid_Scalars attribute node, used to insert the function body, and the + -- value returned is the entity of the constructed function body. We do not + -- bother to generate a separate spec for this subprogram. + procedure Compile_Stream_Body_In_Scope (N : Node_Id; Decl : Node_Id; @@ -174,6 +182,149 @@ -- expansion. Typically used for rounding and truncation attributes that -- appear directly inside a conversion to integer. + - + -- Build_Array_VS_Func -- + - + + function Build_Array_VS_Func + (A_Type : Entity_Id; + Nod: Node_Id) return Entity_Id + is + Loc: constant Source_Ptr := Sloc (Nod); + Comp_Type : constant Entity_Id := Component_Type (A_Type); + Body_Stmts : List_Id; + Index_List : List_Id; + Func_Id: Entity_Id; + Formals: List_Id; + + function Test_Component return List_Id; + -- Create one statement to test validity of one component designated by + -- a full set of indexes. Returns statement list containing test. + + function Test_One_Dimension (N : Int) return List_Id; + -- Create loop to test one dimension of the array. The single statement + -- in the loop body tests the inner dimensions if any, or else the + -- single component. Note that this procedure is called recursively, + -- with N being the dimension to be initialized. A call with N greater + -- than the number of dimensions simply generates the component test, + -- terminating the recursion. Returns statement list containing tests. + + + -- Test_Component -- + + + function Test_Component return List_Id is + Comp : Node_Id; + Anam : Name_Id; + + begin + Comp := + Make_Indexed_Component (Loc, + Prefix = Make_Identifier (Loc, Name_uA), + Expressions = Index_List); + + if Is_Scalar_Type (Comp_Type) then +Anam := Name_Valid; + else +Anam := Name_Valid_Scalars; + end if; + + return New_List ( + Make_If_Statement (Loc, + Condition = + Make_Op_Not (Loc, + Right_Opnd = + Make_Attribute_Reference (Loc, + Attribute_Name = Anam, + Prefix = Comp)), + Then_Statements = New_List ( +
[Ada] Style checks on subprogram instantiations
Style checks must apply to suprogram instantiations, even though they are rewritten by means of a wrapper package and appear not to come from source. Missing overriding indicators (for primitives of untagged types) and casing anomalies in the text of the instance are now diagnosed. the command gcc -c -gnat05 -gnatyO -gnatc instances.ads must yield: instances.ads:13:04: in instantiation at generics.ads:4 instances.ads:13:04: (style) missing overriding indicator in declaration of Ms --- package Generics is generic type Pt is private; procedure Gen_Func (X : in out Pt); end Generics; --- package body Generics is procedure Gen_Func (X : in out PT) is begin null; end; end; --- with Generics; use Generics; package Instances is type T is record A : Integer; B : Integer; end record; procedure Ms (X : in out T); type NT is new T; procedure Ms is new Gen_Func (PT = NT); end Instances; --- the command: gcc -c -gnatyr instance_style.adb must yield: instance_style.adb:14:26: (style) bad casing of G declared at line 6 instance_style.adb:14:29: (style) bad casing of X declared at line 2 --- procedure Instance_Style is X : constant Integer := 15; generic Val : Integer; procedure G; procedure G is begin if Val /= 10 then null; end if; end G; procedure Inst is new g (x); begin Inst; end Instance_Style; Tested on x86_64-pc-linux-gnu, committed on trunk 2012-04-02 Ed Schonberg schonb...@adacore.com * sem_ch12.adb (Analyze_Subprogram_Instantiation): Do not suppress style checks, because the subprogram instance itself may contain violations of syle rules. * style.adb (Missing_Overriding): Check for missing overriding indicator on a subprogram instance. Index: style.adb === --- style.adb (revision 186067) +++ style.adb (working copy) @@ -6,7 +6,7 @@ -- -- -- B o d y -- -- -- --- Copyright (C) 1992-2010, Free Software Foundation, Inc. -- +-- Copyright (C) 1992-2012, Free Software Foundation, Inc. -- -- -- -- GNAT is free software; you can redistribute it and/or modify it under -- -- terms of the GNU General Public License as published by the Free Soft- -- @@ -236,7 +236,13 @@ procedure Missing_Overriding (N : Node_Id; E : Entity_Id) is begin - if Style_Check_Missing_Overriding and then Comes_From_Source (N) then + + -- Perform the check on source subprograms and on subprogram instances, + -- because these can be primitives of untagged types. + + if Style_Check_Missing_Overriding +and then (Comes_From_Source (N) or else Is_Generic_Instance (E)) + then if Nkind (N) = N_Subprogram_Body then Error_Msg_NE -- CODEFIX ((style) missing OVERRIDING indicator in body of, N, E); Index: sem_ch12.adb === --- sem_ch12.adb(revision 186067) +++ sem_ch12.adb(working copy) @@ -4404,9 +4404,6 @@ Parent_Installed : Boolean := False; Renaming_List: List_Id; - Save_Style_Check : constant Boolean := Style_Check; - -- Save style check mode for restore on exit - procedure Analyze_Instance_And_Renamings; -- The instance must be analyzed in a context that includes the mappings -- of generic parameters into actuals. We create a package declaration @@ -4587,11 +4584,13 @@ Instantiation_Node := N; - -- Turn off style checking in instances. If the check is enabled on the - -- generic unit, a warning in an instance would just be noise. If not - -- enabled on the generic, then a warning in an instance is just wrong. + -- For package instantiations we turn off style checks, because they + -- will have been emitted in the generic. For subprogram instantiations + -- we want to apply at least the check on overriding indicators so we + -- do not modify the style check status. - Style_Check := False; + -- The renaming declarations for the actuals do not come from source and + -- will not generate spurious warnings. Preanalyze_Actuals (N); @@ -4859,8 +4858,6 @@ Generic_Renamings_HTable.Reset; end if; - Style_Check := Save_Style_Check; - Leave if Has_Aspects (N) then Analyze_Aspect_Specifications (N, Act_Decl_Id); @@ -4875,8 +4872,6 @@ if Env_Installed then Restore_Env; end if; - - Style_Check := Save_Style_Check;
[Ada] Interaction between packed arrays and post conditions
This patch corrects the insertion of the compiler-generated routine which encapsulates the behavior of post conditions. When a formal parameter is of a packed array type, the compiler creates several helper subtypes and inserts them at the top of the related subprogram declaration list. Since the post conditions may reference formal parameters, the compiler-generated routine _postconditions must be inserted after the last internal declaration at the subprogram level. Tested on x86_64-pc-linux-gnu, committed on trunk 2012-04-02 Hristian Kirtchev kirtc...@adacore.com * sem_ch6.adb (Last_Implicit_Declaration): New routine. (Process_PPCs): Insert the body of _postconditions after the last internally generated declaration. This ensures that actual subtypes created for formal parameters are visible and properly frozen as _postconditions may reference them. Index: sem_ch6.adb === --- sem_ch6.adb (revision 186067) +++ sem_ch6.adb (working copy) @@ -11057,6 +11057,9 @@ -- that an invariant check is required (for an IN OUT parameter, or -- the returned value of a function. + function Last_Implicit_Declaration return Node_Id; + -- Return the last internally-generated declaration of N + - -- Grab_CC -- - @@ -11307,6 +11310,50 @@ end if; end Is_Public_Subprogram_For; + --- + -- Last_Implicit_Declaration -- + --- + + function Last_Implicit_Declaration return Node_Id is + Loc : constant Source_Ptr := Sloc (N); + Decls : List_Id := Declarations (N); + Decl : Node_Id; + Succ : Node_Id; + + begin + if No (Decls) then +Decls := New_List (Make_Null_Statement (Loc)); +Set_Declarations (N, Decls); + + elsif Is_Empty_List (Declarations (N)) then +Append_To (Decls, Make_Null_Statement (Loc)); + end if; + + -- Implicit and source declarations may be interspersed. Search for + -- the last implicit declaration which is either succeeded by a + -- source construct or is the last node in the declarative list. + + Decl := First (Declarations (N)); + while Present (Decl) loop +Succ := Next (Decl); + +-- The current declaration is the last one, do not return Empty + +if No (Succ) then + exit; + +-- The successor is a source construct + +elsif Comes_From_Source (Succ) then + exit; +end if; + +Next (Decl); + end loop; + + return Decl; + end Last_Implicit_Declaration; + -- Start of processing for Process_PPCs begin @@ -11712,7 +11759,7 @@ -- The entity for the _Postconditions procedure begin -Prepend_To (Declarations (N), +Insert_After (Last_Implicit_Declaration, Make_Subprogram_Body (Loc, Specification = Make_Procedure_Specification (Loc,
[Ada] File descriptor leak in GNAT.Expect
When GNAT.Expect reaches the end of its input, it does not properly closes the input file descriptor, thus resulting in a memory leak. This was properly handles when calling Get_Process_Output, but not when writing the loop manually --- -- The following program had errors reported by valgrind (fd leaks) with Ada.Directories; with GNAT.Expect; with GNAT.OS_Lib; procedure GNAT_Expect is File : constant String := /tmp/data.expect; Count : constant:= 2048; Args : GNAT.OS_Lib.Argument_List (1 .. 4); Pd: GNAT.Expect.Process_Descriptor; Match : GNAT.Expect.Expect_Match; Cmd : constant String := echo testdataFile; Res : Integer := 1; begin Args (1) := new String'(-o); Args (2) := new String'(pipefail); Args (3) := new String'(-c); Args (4) := new String'(Cmd); for I in 1 .. Count loop GNAT.Expect.Non_Blocking_Spawn (Descriptor = Pd, Command = /bin/bash, Args= Args, Buffer_Size = 0); begin GNAT.Expect.Expect (Descriptor = Pd, Result = Match, Regexp = , Timeout = -1); exception when GNAT.Expect.Process_Died = GNAT.Expect.Close (Descriptor = Pd, Status = Res); end; end loop; end GNAT_Expect; Tested on x86_64-pc-linux-gnu, committed on trunk 2012-04-02 Emmanuel Briot br...@adacore.com * g-expect.adb (Expect_Internal): Fix leak of the input file descriptor. Index: g-expect.adb === --- g-expect.adb(revision 186067) +++ g-expect.adb(working copy) @@ -6,7 +6,7 @@ -- -- -- B o d y -- -- -- --- Copyright (C) 2000-2011, AdaCore -- +-- Copyright (C) 2000-2012, AdaCore -- -- -- -- GNAT is free software; you can redistribute it and/or modify it under -- -- terms of the GNU General Public License as published by the Free Soft- -- @@ -33,7 +33,7 @@ with System.OS_Constants; use System.OS_Constants; with Ada.Calendar;use Ada.Calendar; -with GNAT.IO; +with GNAT.IO; use GNAT.IO; with GNAT.OS_Lib; use GNAT.OS_Lib; with GNAT.Regpat; use GNAT.Regpat; @@ -678,6 +678,7 @@ -- ??? Note that ddd tries again up to three times -- in that case. See LiterateA.C:174 + Close (Descriptors (D).Input_Fd); Descriptors (D).Input_Fd := Invalid_FD; Result := Expect_Process_Died; return; @@ -893,7 +894,8 @@ begin Non_Blocking_Spawn -(Process, Command, Arguments, Err_To_Out = Err_To_Out); +(Process, Command, Arguments, Err_To_Out = Err_To_Out, + Buffer_Size = 0); if Input'Length 0 then Send (Process, Input); @@ -1055,17 +1057,18 @@ Command_With_Path : String_Access; begin - -- Create the rest of the pipes - - Set_Up_Communications -(Descriptor, Err_To_Out, Pipe1'Access, Pipe2'Access, Pipe3'Access); - Command_With_Path := Locate_Exec_On_Path (Command); if Command_With_Path = null then raise Invalid_Process; end if; + -- Create the rest of the pipes once we know we will be able to + -- execute the process. + + Set_Up_Communications +(Descriptor, Err_To_Out, Pipe1'Access, Pipe2'Access, Pipe3'Access); + -- Fork a new process Descriptor.Pid := Fork; @@ -1365,6 +1368,8 @@ end if; if Create_Pipe (Pipe2) /= 0 then + Close (Pipe1.Input); + Close (Pipe1.Output); return; end if; @@ -1389,7 +1394,7 @@ -- Create a separate pipe for standard error if Create_Pipe (Pipe3) /= 0 then -return; +Pipe3.all := Pipe2.all; end if; end if;
[PATCH] Fix PR52803
This fixes PR52803 - when we do not enter the pass_loop2 sub-pass
queue nothing will execute pass_rtl_loop_done. But we still need
to destroy loops, which are preserved until after pass_loop2.
Doing so in the gate of pass_loop2 is ugly, but destroyed
properties are ignored if the gate returns false. Another
solution would be to destroy loops earlier dependent on
gate_handle_loop2 - but that's equally ugly. Another solution
would be to add a pass after pass_loop2 that only destroys
loops (also ugly).
Honza, how is this part of the pass manager supposed to work?
Thanks,
Richard.
2012-04-02 Richard Guenther rguent...@suse.de
PR middle-end/52803
* loop-init.c (gate_handle_loop2): Destroy loops here if
we don't enter RTL loop optimizers.
* gcc.dg/pr52803.c: New testcase.
Index: gcc/loop-init.c
===
--- gcc/loop-init.c (revision 186066)
+++ gcc/loop-init.c (working copy)
@@ -158,15 +158,24 @@ loop_optimizer_finalize (void)
static bool
gate_handle_loop2 (void)
{
- return (optimize 0
- (flag_move_loop_invariants
- || flag_unswitch_loops
- || flag_peel_loops
- || flag_unroll_loops
+ if (optimize 0
+ (flag_move_loop_invariants
+ || flag_unswitch_loops
+ || flag_peel_loops
+ || flag_unroll_loops
#ifdef HAVE_doloop_end
- || (flag_branch_on_count_reg HAVE_doloop_end)
+ || (flag_branch_on_count_reg HAVE_doloop_end)
#endif
- ));
+))
+return true;
+ else
+{
+ /* No longer preserve loops, remove them now. */
+ cfun-curr_properties = ~PROP_loops;
+ if (current_loops)
+ loop_optimizer_finalize ();
+ return false;
+}
}
struct rtl_opt_pass pass_loop2 =
Index: gcc/testsuite/gcc.dg/pr52803.c
===
--- gcc/testsuite/gcc.dg/pr52803.c (revision 0)
+++ gcc/testsuite/gcc.dg/pr52803.c (revision 0)
@@ -0,0 +1,4 @@
+/* { dg-do compile } */
+/* { dg-options -O -fno-move-loop-invariants } */
+
+int main () { return 0; }
[Ada] Navigation an user-defined operators
The definition of a User-defined operator carries quotes around the name, as
do operators invoked in functional notation. The parser handles these as strings
and their source position is that of the opening quote. This is awkward for
GPS navigation, where we want the highlight of occurrences of the entity to
mark the operator and not the starting quote. This patch modifies the sloc in
the reference table accordingly.
The following command:
gcc -c bla.adb
grep + bla.ali
must yield:
2V14 +{integer} 218 224 6b14 9l9 9t12 11s21 13s24
---
procedure Bla is
function + (Left, Right : Integer) return Integer;
Zero : constant Integer := 0;
function + (Left, Right : Integer) return Integer is
begin
return 42;
end +;
A : Integer := 0 + 0;
B : Integer := Bla.+ (Zero, 10);
function = (X, Y : Integer) return Boolean is begin
return X 0;
end =;
Yes : Boolean := A = B;
begin
null;
end Bla;
Tested on x86_64-pc-linux-gnu, committed on trunk
2012-04-02 Ed Schonberg schonb...@adacore.com
* lib-xref.adb (Generate_Reference): For a reference to an
operator symbol, set the sloc to point to the first character
of the operator name, and not to the initial quaote.
(Output_References): Ditto for the definition of an operator
symbol.
Index: lib-xref.adb
===
--- lib-xref.adb(revision 186067)
+++ lib-xref.adb(working copy)
@@ -1031,6 +1031,15 @@
Ref := Original_Location (Sloc (Nod));
Def := Original_Location (Sloc (Ent));
+-- If this is an operator symbol, skip the initial
+-- quote, for navigation purposes.
+
+if Nkind (N) = N_Defining_Operator_Symbol
+ or else Nkind (Nod) = N_Operator_Symbol
+then
+ Ref := Ref + 1;
+end if;
+
Add_Entry
((Ent = Ent,
Loc = Ref,
@@ -1718,11 +1727,24 @@
-- since at the time the reference or definition is made, private
-- types may be swapped, and the Sloc value may be incorrect. We
-- also set up the pointer vector for the sort.
+ -- For user-defined operators we need to skip the initial
+ -- quote and point to the first character of the name, for
+ -- navigation purposes.
for J in 1 .. Nrefs loop
-Rnums (J) := J;
-Xrefs.Table (J).Def :=
- Original_Location (Sloc (Xrefs.Table (J).Key.Ent));
+declare
+ E : constant Entity_Id := Xrefs.Table (J).Key.Ent;
+ Loc : constant Source_Ptr := Original_Location (Sloc (E));
+
+begin
+ Rnums (J) := J;
+
+ if Nkind (E) = N_Defining_Operator_Symbol then
+ Xrefs.Table (J).Def := Loc + 1;
+ else
+ Xrefs.Table (J).Def := Loc;
+ end if;
+end;
end loop;
-- Sort the references
[Ada] New Z lines in ALI files for implicit withs from instantiation
Units that are only withed from generic instantiation are now put in the ALI file as Z lines instead of W lines. There is no impact on GNAT tools. This is for the benefit of gprbuild. The test for this is to have a unit A instantiating a generic unit B, the body of which import a package C. In tha ALI file for A, there should be a Z line for package C. Tested on x86_64-pc-linux-gnu, committed on trunk 2012-04-02 Vincent Celier cel...@adacore.com * ali.adb (Scan_Ali): Recognize Z lines. Set Implicit_With_From_Instantiation to True in the With_Record for Z lines. * ali.ads (With_Record): New Boolean component Implicit_With_From_Instantiation, defaulted to False. * csinfo.adb: Indicate that Implicit_With_From_Instantiation is special * lib-writ.adb (Write_ALI): New array Implicit_With. (Collect_Withs): Set Implicit_With for the unit is it is not Yes. (Write_With_Lines): Write a Z line instead of a W line if Implicit_With is Yes for the unit. * sem_ch12.adb (Inherit_Context): Only add a unit in the context if it is not there yet. * sinfo.ads: New flag Implicit_With_From_Instantiation (Flag12) added. Index: csinfo.adb === --- csinfo.adb (revision 186067) +++ csinfo.adb (working copy) @@ -6,7 +6,7 @@ -- -- -- B o d y -- -- -- --- Copyright (C) 1992-2010, Free Software Foundation, Inc. -- +-- Copyright (C) 1992-2012, Free Software Foundation, Inc. -- -- -- -- GNAT is free software; you can redistribute it and/or modify it under -- -- terms of the GNU General Public License as published by the Free Soft- -- @@ -218,6 +218,7 @@ Set (Special, Has_Dynamic_Range_Check, True); Set (Special, Has_Dynamic_Length_Check, True); Set (Special, Has_Private_View, True); + Set (Special, Implicit_With_From_Instantiation, True); Set (Special, Is_Controlling_Actual, True); Set (Special, Is_Overloaded, True); Set (Special, Is_Static_Expression, True); Index: sinfo.adb === --- sinfo.adb (revision 186067) +++ sinfo.adb (working copy) @@ -1624,6 +1624,14 @@ return Flag16 (N); end Implicit_With; + function Implicit_With_From_Instantiation + (N : Node_Id) return Boolean is + begin + pragma Assert (False +or else NT (N).Nkind = N_With_Clause); + return Flag12 (N); + end Implicit_With_From_Instantiation; + function Interface_List (N : Node_Id) return List_Id is begin @@ -4704,6 +4712,14 @@ Set_Flag16 (N, Val); end Set_Implicit_With; + procedure Set_Implicit_With_From_Instantiation + (N : Node_Id; Val : Boolean := True) is + begin + pragma Assert (False +or else NT (N).Nkind = N_With_Clause); + Set_Flag12 (N, Val); + end Set_Implicit_With_From_Instantiation; + procedure Set_Interface_List (N : Node_Id; Val : List_Id) is begin Index: sinfo.ads === --- sinfo.ads (revision 186076) +++ sinfo.ads (working copy) @@ -1226,6 +1226,9 @@ --'Address or 'Tag attribute. ???There are other implicit with clauses --as well. + -- Implicit_With_From_Instantiation (Flag12-Sem) + -- Set in N_With_Clause nodes from generic instantiations. + -- Import_Interface_Present (Flag16-Sem) -- This flag is set in an Interface or Import pragma if a matching -- pragma of the other kind is also present. This is used to avoid @@ -5805,6 +5808,7 @@ -- Elaborate_Desirable (Flag11-Sem) -- Private_Present (Flag15) set if with_clause has private keyword -- Implicit_With (Flag16-Sem) + -- Implicit_With_From_Instantiation (Flag12-Sem) -- Limited_Present (Flag17) set if LIMITED is present -- Limited_View_Installed (Flag18-Sem) -- Unreferenced_In_Spec (Flag7-Sem) @@ -8592,6 +8596,9 @@ function Implicit_With (N : Node_Id) return Boolean;-- Flag16 + function Implicit_With_From_Instantiation + (N : Node_Id) return Boolean;-- Flag12 + function Import_Interface_Present (N : Node_Id) return Boolean;-- Flag16 @@ -9573,6 +9580,9 @@ procedure Set_Implicit_With (N : Node_Id; Val : Boolean := True);-- Flag16 + procedure Set_Implicit_With_From_Instantiation + (N : Node_Id; Val : Boolean := True);-- Flag12 + procedure Set_Import_Interface_Present (N : Node_Id; Val : Boolean := True);-- Flag16 @@
Re: [patch] Add support for FP bit fields in varasm.c
You should be able to use fold_unary instead of fold_build1.
make_signed_type should also not be used, but
build_nonstandard_integer_type (or even better, get an integer mode of the
same size of the float mode and then use type_for_mode).
Using the mode size wouldn't work directly for XFmode on x86. Moreover the
precision seems to be the right property in this bit-field context.
Adjusted patch attached, tested on i586-suse-linux, OK for mainline?
--
Eric Botcazou
Index: varasm.c
===
--- varasm.c (revision 186054)
+++ varasm.c (working copy)
@@ -4420,6 +4420,7 @@ initializer_constant_valid_for_bitfield_
}
case INTEGER_CST:
+case REAL_CST:
return true;
case VIEW_CONVERT_EXPR:
@@ -5075,10 +5076,7 @@ output_constructor (tree exp, unsigned H
/* The element in a union constructor specifies the proper field
or index. */
- if ((TREE_CODE (local.type) == RECORD_TYPE
- || TREE_CODE (local.type) == UNION_TYPE
- || TREE_CODE (local.type) == QUAL_UNION_TYPE)
- ce-index != NULL_TREE)
+ if (RECORD_OR_UNION_TYPE_P (local.type) ce-index != NULL_TREE)
local.field = ce-index;
else if (TREE_CODE (local.type) == ARRAY_TYPE)
@@ -5110,9 +5108,18 @@ output_constructor (tree exp, unsigned H
|| !CONSTRUCTOR_BITFIELD_P (local.field)))
output_constructor_regular_field (local);
- /* For a true bitfield or part of an outer one. */
+ /* For a true bitfield or part of an outer one. Only INTEGER_CSTs are
+ supported for scalar fields, so we may need to convert first. */
else
- output_constructor_bitfield (local, outer);
+{
+ if (TREE_CODE (local.val) == REAL_CST)
+ local.val
+ = fold_unary (VIEW_CONVERT_EXPR,
+ build_nonstandard_integer_type
+ (TYPE_PRECISION (TREE_TYPE (local.val)), 0),
+ local.val);
+ output_constructor_bitfield (local, outer);
+ }
}
/* If we are not at toplevel, save the pending data for our caller.
Re: [patch] Add support for FP bit fields in varasm.c
On Mon, Apr 2, 2012 at 12:57 PM, Eric Botcazou ebotca...@adacore.com wrote: You should be able to use fold_unary instead of fold_build1. make_signed_type should also not be used, but build_nonstandard_integer_type (or even better, get an integer mode of the same size of the float mode and then use type_for_mode). Using the mode size wouldn't work directly for XFmode on x86. Moreover the precision seems to be the right property in this bit-field context. Adjusted patch attached, tested on i586-suse-linux, OK for mainline? Ok. Thanks, Richard. -- Eric Botcazou
Re: [PATCH] Dissociate store_expr's temp from exp so that it is not marked as addressable
On Sat, 31 Mar 2012, Martin Jambor wrote:
Hi,
On Fri, Mar 30, 2012 at 10:03:59AM +0200, Richard Guenther wrote:
On Fri, 30 Mar 2012, Martin Jambor wrote:
Hi,
when testing a patch of mine on sparc64-linux, I came across an Ada
bootstrap failure due to a structure DECL which was marked addressable
but had a register DECL_RTL (and therefore mem_ref_refers_to_non_mem_p
failed to trigger on it).
Mode of the structure was TI (16 bytes int) and it was mistakenly
marked as addressable during expansion of an assignment statement in
which a 12 byte portion of it was copied to another structure with
BLKmode. Specifically, this happened because expand_assignment called
store_expr which loaded the required portion to temporary 12 byte
BLKmode MEM_P variable and then called emit_block_move from the
temporary to the destination. emit_block_move_hints then marked
MEM_EXPR of the temp as addressable because it handled the copy by
emitting a library call. And MEM_EXPR pointed to the DECL of the
source of the assignment which I believe is the bug, thus this patch
re-sets MEM_EXPR of temp in these cases.
However, if anybody believes the main issue is elsewhere and another
component of this chain of events needs to be fixed, I'll be happy to
come up with another patch. so far this patch has passed bootstrap
and testing on x86_64-linux and helped my patch which uncovered this
issue to reach stage 3 of bootstrap.
What do you think, is it OK for trunk?
Hmm, I think this should be done at the point we create the mem - where
does that happen?
The function gets it by simply calling expand_expr_real:
temp = expand_expr_real (exp, tmp_target, GET_MODE (target),
(call_param_p
? EXPAND_STACK_PARM : EXPAND_NORMAL),
alt_rtl);
I have reproduced the issue again and looked at how expand_expr_real_1
comes up with the MEM attributes in the COMPONENT_REF case.
The memory-backed temporary is created in:
/* Otherwise, if this is a constant or the object is not in memory
and need be, put it there. */
else if (CONSTANT_P (op0) || (!MEM_P (op0) must_force_mem))
{
tree nt = build_qualified_type (TREE_TYPE (tem),
(TYPE_QUALS (TREE_TYPE (tem))
| TYPE_QUAL_CONST));
memloc = assign_temp (nt, 1, 1, 1);
emit_move_insn (memloc, op0);
op0 = memloc;
}
and at the end of the case, the bitpos is added by adjust_address,
followed by set_mem_attributes (op0, exp, 0);
Indeed it seems that we should not be calling set_mem_attributes if
op0 is based on such temporary... or perhaps just make sure that we
only clear MEM_EXPR afterwards?
Yes, either way I suppose. The following also looks dangerous to me:
/* If OFFSET is making OP0 more aligned than BIGGEST_ALIGNMENT,
record its alignment as BIGGEST_ALIGNMENT. */
if (MEM_P (op0) bitpos == 0 offset != 0
is_aligning_offset (offset, tem))
set_mem_align (op0, BIGGEST_ALIGNMENT);
Maybe we can fall through most of the rest of the function if we
canonicalized in the above way? Eric?
Thanks,
Richard.
[PATCH] Fix PR52800
This fixes PR52800. Bootstrapped and tested on x86_64-unknown-linux-gnu. Richard. 2012-04-02 Richard Guenther rguent...@suse.de PR rtl-optimization/52800 * cprop.c (execute_rtl_cprop): Call cleanup_cfg with CLEANUP_CFG_CHANGED. Index: gcc/cprop.c === --- gcc/cprop.c (revision 186066) +++ gcc/cprop.c (working copy) @@ -1916,7 +1916,7 @@ execute_rtl_cprop (void) changed = one_cprop_pass (); flag_rerun_cse_after_global_opts |= changed; if (changed) -cleanup_cfg (0); +cleanup_cfg (CLEANUP_CFG_CHANGED); return 0; }
Re: [patch][rfa] Do not call output_constant from the front end
Steven Bosscher stevenb@gmail.com writes:
Therefore, an RFA for the attached patch. Bootstrappedtested on
powerpc64-unknown-linux-gnu. OK?
Unfortunately, this patch completely broke libjava testing on
i386-pc-solaris2* and x86_64-unknown-linux-gnu: all execution tests fail
with a SEGV:
Program received signal SIGSEGV, Segmentation fault.
0xfd0ddf7d in _Jv_Linker::verify_class (klass=klass@entry=0xfe945d80)
at /vol/gcc/src/hg/trunk/local/libjava/link.cc:1904
1904 klass-engine-verify(klass);
klass-engine is NULL at this point. Checking the generated .jcr
sections, I found that a large number of them have sh_addralign 0x20
instead of 0x4 before your patch. This caused a massive reduction in
the number of _Jv_RegisterClassHookDefault calls:
With the following DTrace one-liner
pid$target::_Jv_RegisterClassHookDefault:entry{ @[ustack()] = count(); }
to investigate ArrayStore.exe execution, I find for the unpatched jc1:
libgcj.so.13.0.0`_Jv_RegisterClassHookDefault
libgcj.so.13.0.0`_Jv_RegisterClasses+0x44
libgcj.so.13.0.0`_ZN4java4lang9Cloneable6class$E
0xe0ec
7213
With your patch, I get
libgcj.so.13.0.0`_Jv_RegisterClassHookDefault
libgcj.so.13.0.0`_Jv_RegisterNewClasses+0xb7
ArrayStore.exe`_Utf18
1
libgcj.so.13.0.0`_Jv_RegisterClassHookDefault
libgcj.so.13.0.0`_Jv_RegisterClasses+0x44
libgcj.so.13.0.0`_ZN4java4lang9Cloneable6class$E
0xe0ec
12
instead.
The alignment change happens because LOCAL_ALIGNMENT overrides
DECL_ALIGN. This can be avoided by setting DECL_USER_ALIGN (which
unfortunately is undocumented). The result looks better, but still
fails in a different way:
Exception in thread main java.lang.NoClassDefFoundError: ArrayStore
at java.lang.Class.initializeClass(libgcj.so.13.0.0)
Caused by: java.lang.NullPointerException
at java.lang.Class.initializeClass(libgcj.so.13.0.0)
But the _Jv_RegisterClassHookDefault are almost back to normal:
libgcj.so.13.0.0`_Jv_RegisterClassHookDefault
libgcj.so.13.0.0`_Jv_RegisterClasses+0x44
libgcj.so.13.0.0`_ZN4java4lang9Cloneable6class$E
0xe0ec
7212
I could trace this to a change in .jcr section flags: in ArrayStore.exe,
I find
Section Header[18]: sh_name: .jcr
sh_addr: 0x8052058 sh_flags: [ SHF_ALLOC ]
sh_size: 0x4 sh_type:[ SHT_PROGBITS ]
sh_offset:0x2058 sh_entsize: 0
sh_link: 0 sh_info:0
sh_addralign: 0x4
Section Header[26]: sh_name: .jcr
sh_addr: 0x80625e4 sh_flags: [ SHF_WRITE SHF_ALLOC ]
sh_size: 0x4 sh_type:[ SHT_PROGBITS ]
sh_offset:0x25e4 sh_entsize: 0
sh_link: 0 sh_info:0
sh_addralign: 0x4
The first (without SHF_WRITE set) is from jc1, the second from
crtbegin.o. The Solaris linker (and probably other ELF linkers which
don't special-case .jcr) merges sections not just by name, but only if
name and attributs (flags, type) match. Not marking .jcr read-only
fixes that part of the failure and restores libjava testsuite results on
Solaris 11/x86 back to normal (no failures).
Bootstrapped without regressions on i386-pc-solaris2.11.
Ok for mainline?
Rainer
2012-03-31 Rainer Orth r...@cebitec.uni-bielefeld.de
* class.c (emit_register_classes_in_jcr_section): Set DECL_USER_ALIGN.
Clear TREE_READONLY.
# HG changeset patch
# Parent ae1fe58e699b5ec26f0ad31675d3915eef63d963
Fix .jcr alignment
diff --git a/gcc/java/class.c b/gcc/java/class.c
--- a/gcc/java/class.c
+++ b/gcc/java/class.c
@@ -2815,10 +2815,11 @@ emit_register_classes_in_jcr_section (vo
DECL_SECTION_NAME (cdecl) = build_string (strlen (JCR_SECTION_NAME),
JCR_SECTION_NAME);
DECL_ALIGN (cdecl) = POINTER_SIZE;
+ DECL_USER_ALIGN (cdecl) = 1;
DECL_INITIAL (cdecl) = build_constructor (class_array_type, init);
TREE_CONSTANT (DECL_INITIAL (cdecl)) = 1;
TREE_STATIC (cdecl) = 1;
- TREE_READONLY (cdecl) = 1;
+ TREE_READONLY (cdecl) = 0;
TREE_CONSTANT (cdecl) = 1;
DECL_ARTIFICIAL (cdecl) = 1;
DECL_IGNORED_P (cdecl) = 1;
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [patch][rfa] Do not call output_constant from the front end
On Mon, Apr 2, 2012 at 2:24 PM, Rainer Orth r...@cebitec.uni-bielefeld.de
wrote:
Steven Bosscher stevenb@gmail.com writes:
Therefore, an RFA for the attached patch. Bootstrappedtested on
powerpc64-unknown-linux-gnu. OK?
Unfortunately, this patch completely broke libjava testing on
i386-pc-solaris2* and x86_64-unknown-linux-gnu: all execution tests fail
with a SEGV:
Program received signal SIGSEGV, Segmentation fault.
0xfd0ddf7d in _Jv_Linker::verify_class (klass=klass@entry=0xfe945d80)
at /vol/gcc/src/hg/trunk/local/libjava/link.cc:1904
1904 klass-engine-verify(klass);
klass-engine is NULL at this point. Checking the generated .jcr
sections, I found that a large number of them have sh_addralign 0x20
instead of 0x4 before your patch. This caused a massive reduction in
the number of _Jv_RegisterClassHookDefault calls:
With the following DTrace one-liner
pid$target::_Jv_RegisterClassHookDefault:entry{ @[ustack()] = count(); }
to investigate ArrayStore.exe execution, I find for the unpatched jc1:
libgcj.so.13.0.0`_Jv_RegisterClassHookDefault
libgcj.so.13.0.0`_Jv_RegisterClasses+0x44
libgcj.so.13.0.0`_ZN4java4lang9Cloneable6class$E
0xe0ec
7213
With your patch, I get
libgcj.so.13.0.0`_Jv_RegisterClassHookDefault
libgcj.so.13.0.0`_Jv_RegisterNewClasses+0xb7
ArrayStore.exe`_Utf18
1
libgcj.so.13.0.0`_Jv_RegisterClassHookDefault
libgcj.so.13.0.0`_Jv_RegisterClasses+0x44
libgcj.so.13.0.0`_ZN4java4lang9Cloneable6class$E
0xe0ec
12
instead.
The alignment change happens because LOCAL_ALIGNMENT overrides
DECL_ALIGN. This can be avoided by setting DECL_USER_ALIGN (which
unfortunately is undocumented). The result looks better, but still
fails in a different way:
Exception in thread main java.lang.NoClassDefFoundError: ArrayStore
at java.lang.Class.initializeClass(libgcj.so.13.0.0)
Caused by: java.lang.NullPointerException
at java.lang.Class.initializeClass(libgcj.so.13.0.0)
But the _Jv_RegisterClassHookDefault are almost back to normal:
libgcj.so.13.0.0`_Jv_RegisterClassHookDefault
libgcj.so.13.0.0`_Jv_RegisterClasses+0x44
libgcj.so.13.0.0`_ZN4java4lang9Cloneable6class$E
0xe0ec
7212
I could trace this to a change in .jcr section flags: in ArrayStore.exe,
I find
Section Header[18]: sh_name: .jcr
sh_addr: 0x8052058 sh_flags: [ SHF_ALLOC ]
sh_size: 0x4 sh_type: [ SHT_PROGBITS ]
sh_offset: 0x2058 sh_entsize: 0
sh_link: 0 sh_info: 0
sh_addralign: 0x4
Section Header[26]: sh_name: .jcr
sh_addr: 0x80625e4 sh_flags: [ SHF_WRITE SHF_ALLOC ]
sh_size: 0x4 sh_type: [ SHT_PROGBITS ]
sh_offset: 0x25e4 sh_entsize: 0
sh_link: 0 sh_info: 0
sh_addralign: 0x4
The first (without SHF_WRITE set) is from jc1, the second from
crtbegin.o. The Solaris linker (and probably other ELF linkers which
don't special-case .jcr) merges sections not just by name, but only if
name and attributs (flags, type) match. Not marking .jcr read-only
fixes that part of the failure and restores libjava testsuite results on
Solaris 11/x86 back to normal (no failures).
Bootstrapped without regressions on i386-pc-solaris2.11.
Ok for mainline?
Ok. I wonder what happens if we mark __JCR_END__ in crtstuff.c
as const?
Thanks,
Richard.
Rainer
2012-03-31 Rainer Orth r...@cebitec.uni-bielefeld.de
* class.c (emit_register_classes_in_jcr_section): Set DECL_USER_ALIGN.
Clear TREE_READONLY.
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
[PATCH] Fix PR52756
After going through a gazillion of candidate fixes for PR52756, a
case where jump threading destroys loops in a non-recoverable way,
I settled with the following. The issue is that we thread both
the loop latch and the loop entry edge but the code is not prepared
for that. Another possible fix would be to unconditionally throw
away threadings if we threaded the latch based on the fact that
the rest of the edges no longer are loop entry edges (but threading
them may create one, I think even still one that will end up
creating a multiple entry loop).
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Thanks,
Richard.
2012-04-02 Richard Guenther rguent...@suse.de
PR tree-optimization/52756
* tree-ssa-threadupdate.c (thread_through_loop_header): After
threading through the loop latch re-start the function to
double-check the rest of the threading opportunities.
* gcc.dg/torture/pr52756.c: New testcase.
Index: gcc/testsuite/gcc.dg/torture/pr52756.c
===
*** gcc/testsuite/gcc.dg/torture/pr52756.c (revision 0)
--- gcc/testsuite/gcc.dg/torture/pr52756.c (revision 0)
***
*** 0
--- 1,9
+ /* { dg-do compile } */
+
+ void Env_FetchObj0AttrOffset (unsigned int NumFields, int *Status)
+ {
+ int Found = 0;
+ if (NumFields)
+ while ((*Status == 0) NumFields-- 0 Found == 0)
+ Found = 1;
+ }
Index: gcc/tree-ssa-threadupdate.c
===
*** gcc/tree-ssa-threadupdate.c (revision 186066)
--- gcc/tree-ssa-threadupdate.c (working copy)
*** thread_through_loop_header (struct loop
*** 838,843
--- 838,844
edge_iterator ei;
basic_block tgt_bb, atgt_bb;
enum bb_dom_status domst;
+ bool threaded_latch = false;
/* We have already threaded through headers to exits, so all the threading
requests now are to the inside of the loop. We need to avoid creating
*** thread_through_loop_header (struct loop
*** 908,913
--- 909,915
if (single_succ_p (header))
goto fail;
+ thread_rest:
if (latch-aux)
{
if (THREAD_TARGET2 (latch))
*** thread_through_loop_header (struct loop
*** 916,922
tgt_bb = tgt_edge-dest;
}
else if (!may_peel_loop_headers
! !redirection_block_p (loop-header))
goto fail;
else
{
--- 918,924
tgt_bb = tgt_edge-dest;
}
else if (!may_peel_loop_headers
! !redirection_block_p (header))
goto fail;
else
{
*** thread_through_loop_header (struct loop
*** 950,956
if (!tgt_bb)
{
/* There are no threading requests. */
! return false;
}
/* Redirecting to empty loop latch is useless. */
--- 952,958
if (!tgt_bb)
{
/* There are no threading requests. */
! return threaded_latch;
}
/* Redirecting to empty loop latch is useless. */
*** thread_through_loop_header (struct loop
*** 971,977
loop-header = NULL;
loop-latch = NULL;
loops_state_set (LOOPS_NEED_FIXUP);
! return thread_block (header, false);
}
if (tgt_bb-loop_father-header == tgt_bb)
--- 973,979
loop-header = NULL;
loop-latch = NULL;
loops_state_set (LOOPS_NEED_FIXUP);
! return threaded_latch | thread_block (header, false);
}
if (tgt_bb-loop_father-header == tgt_bb)
*** thread_through_loop_header (struct loop
*** 994,1002
loop-latch = thread_single_edge (latch);
gcc_assert (single_succ (loop-latch) == tgt_bb);
loop-header = tgt_bb;
/* Thread the remaining edges through the former header. */
! thread_block (header, false);
}
else
{
--- 996,1005
loop-latch = thread_single_edge (latch);
gcc_assert (single_succ (loop-latch) == tgt_bb);
loop-header = tgt_bb;
+ threaded_latch = true;
/* Thread the remaining edges through the former header. */
! goto thread_rest;
}
else
{
*** fail:
*** 1039,1045
free (e-aux);
e-aux = NULL;
}
! return false;
}
/* Walk through the registered jump threads and convert them into a
--- 1042,1048
free (e-aux);
e-aux = NULL;
}
! return threaded_latch;
}
/* Walk through the registered jump threads and convert them into a
Re: Support for Runtime CPU type detection via builtins (issue5754058)
On Sat, Mar 31, 2012 at 1:03 AM, Sriraman Tallam tmsri...@google.com wrote:
On Fri, Mar 30, 2012 at 5:47 AM, Michael Matz m...@suse.de wrote:
Hi,
On Thu, 29 Mar 2012, Sriraman Tallam wrote:
+struct __processor_model
+{
+ /* Vendor. */
+ unsigned int __cpu_is_amd : 1;
+ unsigned int __cpu_is_intel : 1;
+ /* CPU type. */
+ unsigned int __cpu_is_intel_atom : 1;
+ unsigned int __cpu_is_intel_core2 : 1;
+ unsigned int __cpu_is_intel_corei7 : 1;
+ unsigned int __cpu_is_intel_corei7_nehalem : 1;
+ unsigned int __cpu_is_intel_corei7_westmere : 1;
+ unsigned int __cpu_is_intel_corei7_sandybridge : 1;
+ unsigned int __cpu_is_amdfam10h : 1;
+ unsigned int __cpu_is_amdfam10h_barcelona : 1;
+ unsigned int __cpu_is_amdfam10h_shanghai : 1;
+ unsigned int __cpu_is_amdfam10h_istanbul : 1;
+ unsigned int __cpu_is_amdfam15h_bdver1 : 1;
+ unsigned int __cpu_is_amdfam15h_bdver2 : 1;
+} __cpu_model;
It doesn't make sense for the model to be a bitfield, a processor will
have only ever exactly one model. Just make it an enum or even just an
int.
Not entirely true, nehalem and corei7 can be both set. However, I
modified this by dividing it into types and sub types and then did
what you said.
Uh... then I suppose you need to document somewhere what names
match to what cpuid family/model (supposedly thats where your two-layer
hierarchy comes from, which incidentially misses one layer, the vendor?)
Richard.
* config/i386/i386.c (build_processor_features_struct): New function.
(build_processor_model_struct): New function.
(make_var_decl): New function.
(get_field_from_struct): New function.
(fold_builtin_target): New function.
(ix86_fold_builtin): New function.
(ix86_expand_builtin): Expand new builtins by folding them.
(make_cpu_type_builtin): New functions.
(ix86_init_platform_type_builtins): Make the new builtins.
(ix86_init_builtins): Make new builtins to detect CPU type.
(TARGET_FOLD_BUILTIN): New macro.
(IX86_BUILTIN_CPU_INIT): New enum value.
(IX86_BUILTIN_CPU_IS): New enum value.
(IX86_BUILTIN_CPU_SUPPORTS): New enum value.
* config/i386/i386-builtin-types.def: New function type.
* testsuite/gcc.target/builtin_target.c: New testcase.
* libgcc/config/i386/i386-cpuinfo.c: New file.
* libgcc/config/i386/t-cpuinfo: New file.
* libgcc/config.host: Include t-cpuinfo.
* libgcc/config/i386/libgcc-glibc.ver: Version symbols __cpu_model
and __cpu_features.
Patch available for review here:
http://codereview.appspot.com/5754058
Thanks,
-Sri.
Ciao,
Michael.
Re: [PATCH] Fix PR52803
This fixes PR52803 - when we do not enter the pass_loop2 sub-pass queue nothing will execute pass_rtl_loop_done. But we still need to destroy loops, which are preserved until after pass_loop2. Doing so in the gate of pass_loop2 is ugly, but destroyed properties are ignored if the gate returns false. Another solution would be to destroy loops earlier dependent on gate_handle_loop2 - but that's equally ugly. Another solution would be to add a pass after pass_loop2 that only destroys loops (also ugly). Honza, how is this part of the pass manager supposed to work? Did not think of much of alternatives. We can have pass just after loop destroying the loop structure or perhaps we can simply run loop init/uninit always even if all the subpasses are disabled. Would be a bit smoother, but also wasteful. Honza
Re: [PATCH, i386, Android] -mandroid support for i386 target
On 2/04/2012, at 3:23 AM, Ilya Enkovich wrote:
As is, it appears this patch did not see much testing, I'm pretty sure it
breaks building shared libraries and PIE executable for Linux.
I do not expect any changes in compiler behavior for non Android
targets. I bootstrapped and checked patched compiler on linux-x86_64.
I also built ptched compiler for Android target using NDK scripts.
OK.
Here and in other instances below you use GNU_USER_TARGET_ prefix. I
would prefer using a shorter GNU_USER_ instead unless there is a good
reason to add TARGET too.
The reason is that some macroses are defined in other files and I just
redefine them (i.e. GNU_USER_TARGET_CC1_SPEC). This prefix is also
used for other targets (i.e. in linux-eabi.h). So I do not see a good
reason to change it everywhere or mix it with other prefix
GNU_USER_.
OK.
Here you remove %{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s.
Presumably, you are moving that to GNU_USER[_TARGET]_ENDFILE_SPEC, but you
never define it.
You are right. It is in GNU_USER_TARGET_ENDFILE_SPEC which is defined
in gcc/config/gnu-user.h.
OK. I missed that GNU_USER_TARGET_ENDFILE_SPEC was already defined.
/* A C statement (sans semicolon) to output to the stdio stream
FILE the assembler definition of uninitialized global DECL named
diff --git a/gcc/config/i386/linux.h b/gcc/config/i386/linux.h
index 73681fe..a832ddc 100644
--- a/gcc/config/i386/linux.h
+++ b/gcc/config/i386/linux.h
i386/linux.h is used only for simple x86 32-bit builds; i386/linux64.h is
used for multilib-enabled x86 toolchains. Placing below definitions in
i386/linux.h will not allow adding an Android as an additional multilib to
-m32/-m64 x86 builds. I improve on this situation I suggest:
- rename i386/linux.h to i386/linux32.h (with corresponding change to
config.gcc),
- put below definitions to new i386/linux.h (remember to add license notice
header to the new file),
- include i386/linux.h from both i386/linux32.h and i386/linux64.h.
Android does not support x86_64 target and therefore I do not want
-mandroid support for this target. When Android supports x86_64 target
this change would be appropriate.
The point is that one can build a toolchain for i686-linux-gnu that will
support both 32-bit and 64-bit multilibs. The 32-bit multilib will be used
by default, and compilation for 64-bit user-space can be requested with -m64
option. Even though Android is not supported for -m64, such a toolchain can
support Android as a additional -m32 -mandroid multilib. I.e., the
toolchain will have three multilibs in total: -m32 (default), -m64 and
-m32 -mandroid. I386/linux64.h will be picked up for such a toolchain,
even though by default it would compile for 32-bit target. Does this clear
up things?
I think I see your point. And it seems to make all this work I'll also
have to rename i386/gnu-user.h into i386/gnu-user32.h and create
i386/gnu-user.h with common definitions to be included by
gnu-user[32|64].h. Otherwise I wont be able to use some definitions
(i.e. GNU_USER_TARGET_LINK_SPEC and GNU_USER_TARGET_MATHFILE_SPEC) in
linux64.h. Right?
Thanks,
Ilya
Thank you,
--
Maxim Kuvyrkov
CodeSourcery / Mentor Graphics
Re: [PATCH] Fix PRs 52080, 52097 and 48124, rewrite bitfield expansion, enable the C++ memory model wrt bitfields everywhere
On Fri, 30 Mar 2012, Eric Botcazou wrote: May I apply the patch I posted? It boostrapped/regtested fine on x86-64/Linux. Yes. Thanks. Unfortunately, while this was the last identified problem on x86, another issue is visible on x86-64 as a miscompilation of XML/Ada at -O0. Reduced testcase attached: gnat.dg/pack18.adb gnat.dg/pack18_pkg.ads The executable segfaults because it attempts a read at 0x2000. The scenario is a follows: Rec is packed record so its fields are bit fields, N being at bit offset 129. The representative is at offset 0. get_bit_range is invoked on N with a bitpos of 1, because there is variable offset and its DECL_FIELD_OFFFSET is added to it instead of bitpos. Hence bitpos - bitoffset is (unsigned HOST_WIDE_INT) -128. This value enters unchanged the new code in store_bit_field and the division: offset = bitregion_start / BITS_PER_UNIT; yields the problematic big number. It would therefore appear that bitstart and bitend need to be signed offsets, at least until they are adjusted by store_bit_field. Hmm, yeah. Or something like Index: expr.c === --- expr.c (revision 186082) +++ expr.c (working copy) @@ -4490,8 +4490,8 @@ get_bit_range (unsigned HOST_WIDE_INT *b bitoffset += (tree_low_cst (DECL_FIELD_BIT_OFFSET (field), 1) - tree_low_cst (DECL_FIELD_BIT_OFFSET (repr), 1)); - *bitstart = bitpos - bitoffset; - *bitend = *bitstart + tree_low_cst (DECL_SIZE (repr), 1) - 1; + *bitstart = bitpos (HOST_WIDE_INT) bitoffset ? 0 : bitpos - bitoffset; + *bitend = bitpos + tree_low_cst (DECL_SIZE (repr), 1) - bitoffset - 1; } /* Returns true if the MEM_REF REF refers to an object that does not which conservatively truncates the bitrange. Richard.
Re: [PATCH, i386, Android] -mandroid support for i386 target
On Mon, Apr 2, 2012 at 7:16 AM, Ilya Enkovich enkovich@gmail.com wrote:
On 2/04/2012, at 3:23 AM, Ilya Enkovich wrote:
As is, it appears this patch did not see much testing, I'm pretty sure it
breaks building shared libraries and PIE executable for Linux.
I do not expect any changes in compiler behavior for non Android
targets. I bootstrapped and checked patched compiler on linux-x86_64.
I also built ptched compiler for Android target using NDK scripts.
OK.
Here and in other instances below you use GNU_USER_TARGET_ prefix. I
would prefer using a shorter GNU_USER_ instead unless there is a good
reason to add TARGET too.
The reason is that some macroses are defined in other files and I just
redefine them (i.e. GNU_USER_TARGET_CC1_SPEC). This prefix is also
used for other targets (i.e. in linux-eabi.h). So I do not see a good
reason to change it everywhere or mix it with other prefix
GNU_USER_.
OK.
Here you remove %{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s.
Presumably, you are moving that to GNU_USER[_TARGET]_ENDFILE_SPEC, but you
never define it.
You are right. It is in GNU_USER_TARGET_ENDFILE_SPEC which is defined
in gcc/config/gnu-user.h.
OK. I missed that GNU_USER_TARGET_ENDFILE_SPEC was already defined.
/* A C statement (sans semicolon) to output to the stdio stream
FILE the assembler definition of uninitialized global DECL named
diff --git a/gcc/config/i386/linux.h b/gcc/config/i386/linux.h
index 73681fe..a832ddc 100644
--- a/gcc/config/i386/linux.h
+++ b/gcc/config/i386/linux.h
i386/linux.h is used only for simple x86 32-bit builds; i386/linux64.h is
used for multilib-enabled x86 toolchains. Placing below definitions in
i386/linux.h will not allow adding an Android as an additional multilib to
-m32/-m64 x86 builds. I improve on this situation I suggest:
- rename i386/linux.h to i386/linux32.h (with corresponding change to
config.gcc),
- put below definitions to new i386/linux.h (remember to add license
notice header to the new file),
- include i386/linux.h from both i386/linux32.h and i386/linux64.h.
Android does not support x86_64 target and therefore I do not want
-mandroid support for this target. When Android supports x86_64 target
this change would be appropriate.
The point is that one can build a toolchain for i686-linux-gnu that will
support both 32-bit and 64-bit multilibs. The 32-bit multilib will be used
by default, and compilation for 64-bit user-space can be requested with -m64
option. Even though Android is not supported for -m64, such a toolchain can
support Android as a additional -m32 -mandroid multilib. I.e., the
toolchain will have three multilibs in total: -m32 (default), -m64 and
-m32 -mandroid. I386/linux64.h will be picked up for such a toolchain,
even though by default it would compile for 32-bit target. Does this clear
up things?
I think I see your point. And it seems to make all this work I'll also
have to rename i386/gnu-user.h into i386/gnu-user32.h and create
i386/gnu-user.h with common definitions to be included by
gnu-user[32|64].h. Otherwise I wont be able to use some definitions
(i.e. GNU_USER_TARGET_LINK_SPEC and GNU_USER_TARGET_MATHFILE_SPEC) in
linux64.h. Right?
I think it is a good idea.
Thanks.
--
H.J.
Re: [PATCH] Fix PR52756
On Mon, 2 Apr 2012, Richard Guenther wrote:
After going through a gazillion of candidate fixes for PR52756, a
case where jump threading destroys loops in a non-recoverable way,
I settled with the following. The issue is that we thread both
the loop latch and the loop entry edge but the code is not prepared
for that. Another possible fix would be to unconditionally throw
away threadings if we threaded the latch based on the fact that
the rest of the edges no longer are loop entry edges (but threading
them may create one, I think even still one that will end up
creating a multiple entry loop).
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
And revealed one missed optimization, gcc.dg/tree-ssa/ssa-dom-thread-2.c
Thus the following is another try to fix things.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2012-04-02 Richard Guenther rguent...@suse.de
PR tree-optimization/52756
* tree-ssa-threadupdate.c (def_split_header_continue_p): New function.
(thread_through_loop_header): After threading through the loop latch
remove the split part from the loop and clear further threading
opportunities that would create a multiple entry loop.
* gcc.dg/torture/pr52756.c: New testcase.
Index: gcc/testsuite/gcc.dg/torture/pr52756.c
===
*** gcc/testsuite/gcc.dg/torture/pr52756.c (revision 0)
--- gcc/testsuite/gcc.dg/torture/pr52756.c (revision 0)
***
*** 0
--- 1,9
+ /* { dg-do compile } */
+
+ void Env_FetchObj0AttrOffset (unsigned int NumFields, int *Status)
+ {
+ int Found = 0;
+ if (NumFields)
+ while ((*Status == 0) NumFields-- 0 Found == 0)
+ Found = 1;
+ }
Index: gcc/tree-ssa-threadupdate.c
===
*** gcc/tree-ssa-threadupdate.c (revision 186082)
--- gcc/tree-ssa-threadupdate.c (working copy)
*** determine_bb_domination_status (struct l
*** 826,831
--- 826,842
return (bb_reachable ? DOMST_DOMINATING : DOMST_LOOP_BROKEN);
}
+ /* Return true if BB is part of the new pre-header that is created
+when threading the latch to DATA. */
+
+ static bool
+ def_split_header_continue_p (const_basic_block bb, const void *data)
+ {
+ const_basic_block new_header = (const_basic_block) data;
+ return (bb-loop_father == new_header-loop_father
+ bb != new_header);
+ }
+
/* Thread jumps through the header of LOOP. Returns true if cfg changes.
If MAY_PEEL_LOOP_HEADERS is false, we avoid threading from entry edges
to the inside of the loop. */
*** thread_through_loop_header (struct loop
*** 990,1000
--- 1001,1046
if (latch-aux)
{
+ basic_block *bblocks;
+ unsigned nblocks, i;
+
/* First handle the case latch edge is redirected. */
loop-latch = thread_single_edge (latch);
gcc_assert (single_succ (loop-latch) == tgt_bb);
loop-header = tgt_bb;
+ /* Remove the new pre-header blocks from our loop. */
+ bblocks = XCNEWVEC (basic_block, loop-num_nodes);
+ nblocks = dfs_enumerate_from (header, 0, def_split_header_continue_p,
+ bblocks, loop-num_nodes, tgt_bb);
+ for (i = 0; i nblocks; i++)
+ {
+ remove_bb_from_loops (bblocks[i]);
+ add_bb_to_loop (bblocks[i], loop_outer (loop));
+ }
+ free (bblocks);
+
+ /* Cancel remaining threading requests that would make the
+loop a multiple entry loop. */
+ FOR_EACH_EDGE (e, ei, header-preds)
+ {
+ edge e2;
+ if (e-aux == NULL)
+ continue;
+
+ if (THREAD_TARGET2 (e))
+ e2 = THREAD_TARGET2 (e);
+ else
+ e2 = THREAD_TARGET (e);
+
+ if (e-src-loop_father != e2-dest-loop_father
+ e2-dest != loop-header)
+ {
+ free (e-aux);
+ e-aux = NULL;
+ }
+ }
+
/* Thread the remaining edges through the former header. */
thread_block (header, false);
}
Re: [PATCH] Fix PR52756
On Mon, Apr 2, 2012 at 5:32 AM, Richard Guenther rguent...@suse.de wrote:
After going through a gazillion of candidate fixes for PR52756, a
case where jump threading destroys loops in a non-recoverable way,
I settled with the following. The issue is that we thread both
the loop latch and the loop entry edge but the code is not prepared
for that. Another possible fix would be to unconditionally throw
away threadings if we threaded the latch based on the fact that
the rest of the edges no longer are loop entry edges (but threading
them may create one, I think even still one that will end up
creating a multiple entry loop).
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Thanks,
Richard.
2012-04-02 Richard Guenther rguent...@suse.de
PR tree-optimization/52756
* tree-ssa-threadupdate.c (thread_through_loop_header): After
threading through the loop latch re-start the function to
double-check the rest of the threading opportunities.
* gcc.dg/torture/pr52756.c: New testcase.
Index: gcc/testsuite/gcc.dg/torture/pr52756.c
===
*** gcc/testsuite/gcc.dg/torture/pr52756.c (revision 0)
--- gcc/testsuite/gcc.dg/torture/pr52756.c (revision 0)
***
*** 0
--- 1,9
+ /* { dg-do compile } */
+
+ void Env_FetchObj0AttrOffset (unsigned int NumFields, int *Status)
+ {
+ int Found = 0;
+ if (NumFields)
+ while ((*Status == 0) NumFields-- 0 Found == 0)
+ Found = 1;
+ }
Is compiler allowed to optimize this function into an empty body?
Will it be a useful testcase then?
--
H.J.
Re: [PATCH] Fix PR52756
On Mon, 2 Apr 2012, H.J. Lu wrote:
On Mon, Apr 2, 2012 at 5:32 AM, Richard Guenther rguent...@suse.de wrote:
After going through a gazillion of candidate fixes for PR52756, a
case where jump threading destroys loops in a non-recoverable way,
I settled with the following. The issue is that we thread both
the loop latch and the loop entry edge but the code is not prepared
for that. Another possible fix would be to unconditionally throw
away threadings if we threaded the latch based on the fact that
the rest of the edges no longer are loop entry edges (but threading
them may create one, I think even still one that will end up
creating a multiple entry loop).
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Thanks,
Richard.
2012-04-02 Richard Guenther rguent...@suse.de
PR tree-optimization/52756
* tree-ssa-threadupdate.c (thread_through_loop_header): After
threading through the loop latch re-start the function to
double-check the rest of the threading opportunities.
* gcc.dg/torture/pr52756.c: New testcase.
Index: gcc/testsuite/gcc.dg/torture/pr52756.c
===
*** gcc/testsuite/gcc.dg/torture/pr52756.c (revision 0)
--- gcc/testsuite/gcc.dg/torture/pr52756.c (revision 0)
***
*** 0
--- 1,9
+ /* { dg-do compile } */
+
+ void Env_FetchObj0AttrOffset (unsigned int NumFields, int *Status)
+ {
+ int Found = 0;
+ if (NumFields)
+ while ((*Status == 0) NumFields-- 0 Found == 0)
+ Found = 1;
+ }
Is compiler allowed to optimize this function into an empty body?
Will it be a useful testcase then?
I don't think so as *Status may trap.
Richard.
Re: [PATCH, RTL] Fix PR 51106
Hello,
On 19.01.2012 18:40, Jakub Jelinek wrote:
On Thu, Jan 19, 2012 at 06:13:58PM +0400, Andrey Belevantsev wrote:
2012-01-19 Andrey Belevantseva...@ispras.ru
PR target/51106
* function.c (instantiate_virtual_regs_in_insn): Use
delete_insn_and_edges when removing a wrong asm insn.
This is ok for trunk.
After Richi's RTL generation related cleanups went it, the extra
cleanup_cfg call was added so we are no longer lucky to have the proper
fallthru edge in this case. The PR trail has the patch to purge_dead_edges
making it consider this situation, but I still prefer the below patch that
fixes only the invalid asm case. The reason is that I think it unlikely
that after initial RTL expansion (of which the instantiate virtual regs
pass seems to be the part) we will get the problematic situation. However,
I'm happy to test the PR trail patch, too.
Tested fine on x86-64, ok for trunk?
Andrey
2012-04-02 Andrey Belevantsev a...@ispras.ru
PR target/51106
PR middle-end/52650
* function.c (instantiate_virtual_regs_in_insn): Make sure to set
the proper fallthru bits when removing a wrong jump asm.
diff --git a/gcc/function.c b/gcc/function.c
index 3e903ef..a2638bb 100644
--- a/gcc/function.c
+++ b/gcc/function.c
@@ -1730,6 +1730,15 @@ instantiate_virtual_regs_in_insn (rtx insn)
if (!check_asm_operands (PATTERN (insn)))
{
error_for_asm (insn, impossible constraint in %asm%);
+ if (JUMP_P (insn))
+ {
+ basic_block bb = BLOCK_FOR_INSN (insn);
+ edge e;
+
+ if (single_succ_p (bb)
+ !((e = single_succ_edge (bb))-flags EDGE_FALLTHRU))
+ e-flags |= EDGE_FALLTHRU;
+ }
delete_insn_and_edges (insn);
}
}
Re: PATCH: Update x32 rt_sigreturn syscall number to 0x40000201
H.J. Lu hjl.to...@gmail.com writes: The final rt_sigreturn syscall number is changed to 0x4201 in Linux kernel v3.4-rc1. This patch updates x32 rt_sigreturn syscall number. OK for trunk and 4.7 branch? Sure. Ian
Re: [PATCH, i386, Android] -mandroid support for i386 target
On 3/04/2012, at 2:16 AM, Ilya Enkovich wrote: The point is that one can build a toolchain for i686-linux-gnu that will support both 32-bit and 64-bit multilibs. The 32-bit multilib will be used by default, and compilation for 64-bit user-space can be requested with -m64 option. Even though Android is not supported for -m64, such a toolchain can support Android as a additional -m32 -mandroid multilib. I.e., the toolchain will have three multilibs in total: -m32 (default), -m64 and -m32 -mandroid. I386/linux64.h will be picked up for such a toolchain, even though by default it would compile for 32-bit target. Does this clear up things? I think I see your point. And it seems to make all this work I'll also have to rename i386/gnu-user.h into i386/gnu-user32.h and create i386/gnu-user.h with common definitions to be included by gnu-user[32|64].h. Otherwise I wont be able to use some definitions (i.e. GNU_USER_TARGET_LINK_SPEC and GNU_USER_TARGET_MATHFILE_SPEC) in linux64.h. Right? It's simpler that you think. The target headers ($tm_file in config.gcc -- gnu-user.h, linux*.h, etc. in this case) are all included into tm.h, which serves as proxy to all those headers. All definitions made in preceding headers are available in subsequent headers. So, given that i386/gnu-user*.h precedes i386/linux*.h in config.gcc's $tm_file, you only need to touch linux*.h. Thanks, -- Maxim Kuvyrkov CodeSourcery / Mentor Graphics
Re: Support for Runtime CPU type detection via builtins (issue5754058)
On Mon, Apr 2, 2012 at 5:38 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Sat, Mar 31, 2012 at 1:03 AM, Sriraman Tallam tmsri...@google.com wrote:
On Fri, Mar 30, 2012 at 5:47 AM, Michael Matz m...@suse.de wrote:
Hi,
On Thu, 29 Mar 2012, Sriraman Tallam wrote:
+struct __processor_model
+{
+ /* Vendor. */
+ unsigned int __cpu_is_amd : 1;
+ unsigned int __cpu_is_intel : 1;
+ /* CPU type. */
+ unsigned int __cpu_is_intel_atom : 1;
+ unsigned int __cpu_is_intel_core2 : 1;
+ unsigned int __cpu_is_intel_corei7 : 1;
+ unsigned int __cpu_is_intel_corei7_nehalem : 1;
+ unsigned int __cpu_is_intel_corei7_westmere : 1;
+ unsigned int __cpu_is_intel_corei7_sandybridge : 1;
+ unsigned int __cpu_is_amdfam10h : 1;
+ unsigned int __cpu_is_amdfam10h_barcelona : 1;
+ unsigned int __cpu_is_amdfam10h_shanghai : 1;
+ unsigned int __cpu_is_amdfam10h_istanbul : 1;
+ unsigned int __cpu_is_amdfam15h_bdver1 : 1;
+ unsigned int __cpu_is_amdfam15h_bdver2 : 1;
+} __cpu_model;
It doesn't make sense for the model to be a bitfield, a processor will
have only ever exactly one model. Just make it an enum or even just an
int.
Not entirely true, nehalem and corei7 can be both set. However, I
modified this by dividing it into types and sub types and then did
what you said.
Uh... then I suppose you need to document somewhere what names
match to what cpuid family/model (supposedly thats where your two-layer
hierarchy comes from, which incidentially misses one layer, the vendor?)
Yes, it is 3-layer. Vendor, family and model.
What is the right place to document these?
Richard.
* config/i386/i386.c (build_processor_features_struct): New function.
(build_processor_model_struct): New function.
(make_var_decl): New function.
(get_field_from_struct): New function.
(fold_builtin_target): New function.
(ix86_fold_builtin): New function.
(ix86_expand_builtin): Expand new builtins by folding them.
(make_cpu_type_builtin): New functions.
(ix86_init_platform_type_builtins): Make the new builtins.
(ix86_init_builtins): Make new builtins to detect CPU type.
(TARGET_FOLD_BUILTIN): New macro.
(IX86_BUILTIN_CPU_INIT): New enum value.
(IX86_BUILTIN_CPU_IS): New enum value.
(IX86_BUILTIN_CPU_SUPPORTS): New enum value.
* config/i386/i386-builtin-types.def: New function type.
* testsuite/gcc.target/builtin_target.c: New testcase.
* libgcc/config/i386/i386-cpuinfo.c: New file.
* libgcc/config/i386/t-cpuinfo: New file.
* libgcc/config.host: Include t-cpuinfo.
* libgcc/config/i386/libgcc-glibc.ver: Version symbols __cpu_model
and __cpu_features.
Patch available for review here:
http://codereview.appspot.com/5754058
Thanks,
-Sri.
Ciao,
Michael.
[PATCH, committed] Fix PR2497, libffi build breakage on powerpc64-*
I have committed the following patch to fix the libffi build breakage I'm
seeing on powerpc64-linux (when building java) which was caused by the
recent merge of upstream libffi. Anthony Green ack'd this patch for
upstream, but said to commit it here and he'd merge the gcc sources
back to upstream libffi.
libffi/
* src/powerpc/ffi.c (ffi_prep_args_SYSV): Declare double_tmp.
Silence casting pointer to integer of different size warning.
Delete goto to previously deleted label.
(ffi_call): Silence possibly undefined warning.
(ffi_closure_helper_SYSV): Declare variable type.
Index: libffi/src/powerpc/ffi.c
===
--- libffi/src/powerpc/ffi.c(revision 186090)
+++ libffi/src/powerpc/ffi.c(revision 186091)
@@ -146,6 +146,7 @@
gpr_base.u = stacktop.u - ASM_NEEDS_REGISTERS - NUM_GPR_ARG_REGISTERS;
intarg_count = 0;
#ifndef __NO_FPRS__
+ double double_tmp;
fpr_base.d = gpr_base.d - NUM_FPR_ARG_REGISTERS;
fparg_count = 0;
copy_space.c = ((flags FLAG_FP_ARGUMENTS) ? fpr_base.c : gpr_base.c);
@@ -155,9 +156,9 @@
next_arg.u = stack + 2;
/* Check that everything starts aligned properly. */
- FFI_ASSERT (((unsigned) (char *) stack 0xF) == 0);
- FFI_ASSERT (((unsigned) copy_space.c 0xF) == 0);
- FFI_ASSERT (((unsigned) stacktop.c 0xF) == 0);
+ FFI_ASSERT (((unsigned long) (char *) stack 0xF) == 0);
+ FFI_ASSERT (((unsigned long) copy_space.c 0xF) == 0);
+ FFI_ASSERT (((unsigned long) stacktop.c 0xF) == 0);
FFI_ASSERT ((bytes 0xF) == 0);
FFI_ASSERT (copy_space.c = next_arg.c);
@@ -211,8 +212,6 @@
case FFI_TYPE_DOUBLE:
/* With FFI_LINUX_SOFT_FLOAT doubles are handled like UINT64. */
- if (ecif-cif-abi == FFI_LINUX_SOFT_FLOAT)
- goto soft_double_prep;
double_tmp = **p_argv.d;
if (fparg_count = NUM_FPR_ARG_REGISTERS)
@@ -925,7 +924,7 @@
*/
unsigned int smst_buffer[2];
extended_cif ecif;
- unsigned int rsize;
+ unsigned int rsize = 0;
ecif.cif = cif;
ecif.avalue = avalue;
@@ -1132,7 +1131,7 @@
if (nf 8)
{
- temp = pfr-d;
+ double temp = pfr-d;
pfr-f = (float) temp;
avalue[i] = pfr;
nf++;
Re: [ping 6] [patch] attribute to reverse bitfield allocations (is anyone even reading these?)
Ping 6... It's now been over EIGHT MONTHS since I posted the patch, back in stage 1 for 4.7. Can someone please review and/or approve this before gcc 4.8's stage 1 is closed? This is needed as a first step for ABI compatibility for rx-elf. Ping 5... Ping 4... Ping 3? It's been months with no feedback... Ping 2 ? http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01889.html http://gcc.gnu.org/ml/gcc-patches/2011-07/msg02555.html http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00529.html http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01246.html http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00636.html
Re: [PATCH H8300] Added -mno-exr option in case of function with monitor attribute
On 03/30/2012 08:13 AM, Sandeep Kumar Singh wrote: Hi, Please find the attached patch to avoid saving of EXR register for monitor functions. By default, in prologue code of a monitor function, EXR register is pushed onto the stack. This implementation is not required for H8S/224x and 21xx variants of H8S controllers. The behavior can be controlled with option -mno-exr. Built compiler is only for compiling C language source code. No regression found with this patch. Compiler behavior with different command line options used for compilation of code after applying this patch is given below: * h8300-elf-gcc -mn -S test.c test.c:1:0: error: -mn is used without -mh or -ms or -msx * h8300-elf-gcc -mh -mexr -S test.c test.c:1:0: error: -mexr is used without -ms * h8300-elf-gcc -mh -mno-exr -S test.c test.c:1:0: warning: -mno-exr valid only with -ms or -msx - Option ignored! [-mno-exr] * Generated assembly without option '-mno-exr': _testmonitor: stc exr,@-er7 mov.l er0,@-er7 stc ccr,r0l * Generated assembly with option '-mno-exr': _testmonitor: mov.l er0,@-er7 stc ccr,r0l Please review the patch and let me know if there should be any modifications in it? This looks pretty good. Just a couple minor issues. First, do you have an assignment on file with the FSF. I note several other engineers at KPIT have assignments, but I'm not aware of one for you. That will need to be taken care of before we can accept the code. My recollection was -mint32 was supported on the original H8/300; is there something in particular that makes you want to issue an error for that case? Or is my memory incorrect? In h8300.opt, rather than say Push exr on stack, would it make more sense to say [Do not] Push extended registers on stack in monitor functions? Jeff
Re: [PATCH] ARM: Use different linker path for hardfloat ABI
On Fri, Mar 30, 2012 at 06:52:34PM +0100, Richard Earnshaw wrote:
On 29/03/12 20:34, dann frazier wrote:
This is an updated version of a patch Debian and Ubuntu are using to
use an alternate linker path for hardfloat binaries. The difference
with this one is that it covers the case where no float flag
was passed in, defaulting to the softfloat path.
2012-03-29 dann frazier dann.fraz...@canonical.com
* config/arm/linux-elf.h: Use alternate linker path
for hardfloat ABI
Index: gcc/config/arm/linux-elf.h
===
--- gcc/config/arm/linux-elf.h (revision 185708)
+++ gcc/config/arm/linux-elf.h (working copy)
@@ -59,14 +59,21 @@
#define LIBGCC_SPEC %{mfloat-abi=soft*:-lfloat} -lgcc
-#define GLIBC_DYNAMIC_LINKER /lib/ld-linux.so.2
+#define LINUX_DYNAMIC_LINKER_SF /lib/ld-linux.so.3
+#define LINUX_DYNAMIC_LINKER_HF /lib/arm-linux-gnueabihf/ld-linux.so.3
#define LINUX_TARGET_LINK_SPEC %{h*} \
%{static:-Bstatic} \
%{shared:-shared} \
%{symbolic:-Bsymbolic} \
%{rdynamic:-export-dynamic} \
- -dynamic-linker GNU_USER_DYNAMIC_LINKER \
+ %{msoft-float:-dynamic-linker LINUX_DYNAMIC_LINKER_SF } \
+ %{mfloat-abi=soft*:-dynamic-linker LINUX_DYNAMIC_LINKER_SF } \
+ %{mhard-float:-dynamic-linker LINUX_DYNAMIC_LINKER_HF } \
+ %{mfloat-abi=hard:-dynamic-linker LINUX_DYNAMIC_LINKER_HF } \
+ %{!mfloat-abi: \
+ %{!msoft-float: \
+ %{!mhard-float:-dynamic-linker LINUX_DYNAMIC_LINKER_SF }}} \
-X \
%{mbig-endian:-EB} %{mlittle-endian:-EL} \
SUBTARGET_EXTRA_LINK_SPEC
Looks to me as though this will break the old Linux ABI. While we've
marked that as deprecated, it hasn't been removed as yet. So I think
this patch either needs to wait until that removal has taken place, or
provide the relevant updates to maintain the old ABI support.
Thanks for your review. You're right, this does appear to break the
old ABI - that was a misunderstanding on my part. I think this fixes
the problem:
Index: gcc/config/arm/linux-elf.h
===
--- gcc/config/arm/linux-elf.h (revision 185708)
+++ gcc/config/arm/linux-elf.h (working copy)
@@ -60,13 +60,17 @@
#define LIBGCC_SPEC %{mfloat-abi=soft*:-lfloat} -lgcc
#define GLIBC_DYNAMIC_LINKER /lib/ld-linux.so.2
+#define LINUX_DYNAMIC_LINKER_HF /lib/arm-linux-gnueabihf/ld-linux.so.3
#define LINUX_TARGET_LINK_SPEC %{h*} \
%{static:-Bstatic} \
%{shared:-shared} \
%{symbolic:-Bsymbolic} \
%{rdynamic:-export-dynamic} \
- -dynamic-linker GNU_USER_DYNAMIC_LINKER \
+ %{mhard-float:-dynamic-linker LINUX_DYNAMIC_LINKER_HF } \
+ %{mfloat-abi=hard:-dynamic-linker LINUX_DYNAMIC_LINKER_HF } \
+ %{!mfloat-abi: \
+ %{!mhard-float:-dynamic-linker GNU_USER_DYNAMIC_LINKER }} \
-X \
%{mbig-endian:-EB} %{mlittle-endian:-EL} \
SUBTARGET_EXTRA_LINK_SPEC
[PATCH] Don't ignore failures from compute_data_dependences_for_loop in build_rdg (PR tree-optimization/52835)
Hi!
On the following testcase compute_data_dependences_for_loop
fails, but build_rdg ignores its return value and happily goes
on as if it didn't fail, optimizing away a call.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk/4.7?
2012-04-02 Jakub Jelinek ja...@redhat.com
PR tree-optimization/52835
* tree-data-ref.c (build_rdg): Return NULL if
compute_data_dependences_for_loop failed.
* gfortran.dg/pr52835.f90: New test.
--- gcc/tree-data-ref.c.jj 2012-03-20 08:51:32.0 +0100
+++ gcc/tree-data-ref.c 2012-04-02 21:30:13.783378347 +0200
@@ -5129,20 +5129,19 @@ build_rdg (struct loop *loop,
VEC (data_reference_p, heap) **datarefs)
{
struct graph *rdg = NULL;
- VEC (gimple, heap) *stmts = VEC_alloc (gimple, heap, 10);
- compute_data_dependences_for_loop (loop, false, loop_nest, datarefs,
-dependence_relations);
-
- if (known_dependences_p (*dependence_relations))
+ if (compute_data_dependences_for_loop (loop, false, loop_nest, datarefs,
+dependence_relations)
+ known_dependences_p (*dependence_relations))
{
+ VEC (gimple, heap) *stmts = VEC_alloc (gimple, heap, 10);
stmts_from_loop (loop, stmts);
rdg = build_empty_rdg (VEC_length (gimple, stmts));
create_rdg_vertices (rdg, stmts);
create_rdg_edges (rdg, *dependence_relations);
+ VEC_free (gimple, heap, stmts);
}
- VEC_free (gimple, heap, stmts);
return rdg;
}
--- gcc/testsuite/gfortran.dg/pr52835.f90.jj2012-04-02 21:35:42.616505464
+0200
+++ gcc/testsuite/gfortran.dg/pr52835.f90 2012-04-02 21:35:08.0
+0200
@@ -0,0 +1,16 @@
+! PR tree-optimization/52835
+! { dg-do compile }
+! { dg-options -O3 -fdump-tree-optimized }
+
+subroutine foo (x, y, z, n)
+ integer :: n, i
+ real :: x(n), y(n), z(n)
+ do i = 1, n
+z(i) = 0.0
+y(i) = 0.0
+call bar (y(i), z(i), x(i))
+ end do
+end subroutine
+
+! { dg-final { scan-tree-dump bar optimized } }
+! { dg-final { cleanup-tree-dump optimized } }
Jakub
[google] Fix PR52822 in google's gcc-4.6 branch (issue5975063)
I'll send the patches for trunk, gcc-4_7-branch, and gcc-4_6-branch in
a separate thread later today or tomorrow, but I need to get the
google branch fixed before that. Paolo suggested this simple fix was
the right approach for the gcc-4_6-branch, so I'm using it for
google/gcc-4_6 too. I'll be happy to fix up the google branch to match
whatever gets accepted for gcc-4_6-branch once that's decided.
Tested with `make check` on x86-64-linux, and I'll check this against
the build I originally noticed the problem in before committing it.
2012-04-02 Jeffrey Yasskin jyass...@google.com
* libstdc++-v3/include/bits/stl_algo.h (__stable_partition_adaptive):
Avoid move-assigning an object to itself by explicitly testing
for identity.
* libstdc++-v3/testsuite/25_algorithms/stable_partition/pr52822.cc:
Test vectors, which have a destructive self-move-assignment.
* libstdc++-v3/testsuite/25_algorithms/stable_partition/moveable.cc
(test02):
Test with rvalstruct, which explicitly checks self-move-assignment.
Index: libstdc++-v3/include/bits/stl_algo.h
===
--- libstdc++-v3/include/bits/stl_algo.h(revision 186093)
+++ libstdc++-v3/include/bits/stl_algo.h(working copy)
@@ -1844,7 +1844,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
for (; __first != __last; ++__first)
if (__pred(*__first))
{
- *__result1 = _GLIBCXX_MOVE(*__first);
+if (*__result1 != *__first)
+ *__result1 = _GLIBCXX_MOVE(*__first);
++__result1;
}
else
Index: libstdc++-v3/testsuite/25_algorithms/stable_partition/pr52822.cc
===
--- libstdc++-v3/testsuite/25_algorithms/stable_partition/pr52822.cc
(revision 0)
+++ libstdc++-v3/testsuite/25_algorithms/stable_partition/pr52822.cc
(revision 0)
@@ -0,0 +1,43 @@
+// { dg-options -std=gnu++0x }
+
+// Copyright (C) 2012 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library. This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without Pred the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3. If not see
+// http://www.gnu.org/licenses/.
+
+// 25.2.12 [lib.alg.partitions] Partitions.
+
+#include algorithm
+#include vector
+#include testsuite_hooks.h
+
+bool true_vector_pred(const std::vectorint) { return true; }
+
+void
+test01()
+{
+ std::vectorstd::vectorint v(1);
+ v[0].push_back(7);
+ VERIFY( v[0].size() == 1 );
+ std::stable_partition(v.begin(), v.end(), true_vector_pred);
+ VERIFY( v[0].size() == 1 );
+}
+
+int
+main()
+{
+ test01();
+ return 0;
+}
Index: libstdc++-v3/testsuite/25_algorithms/stable_partition/moveable.cc
===
--- libstdc++-v3/testsuite/25_algorithms/stable_partition/moveable.cc
(revision 186093)
+++ libstdc++-v3/testsuite/25_algorithms/stable_partition/moveable.cc
(working copy)
@@ -1,6 +1,6 @@
// { dg-options -std=gnu++0x }
-// Copyright (C) 2009, 2010 Free Software Foundation, Inc.
+// Copyright (C) 2009, 2010, 2012 Free Software Foundation, Inc.
//
// This file is part of the GNU ISO C++ Library. This library is free
// software; you can redistribute it and/or modify it under the
@@ -39,6 +39,12 @@ const int A[] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11
const int B[] = {2, 4, 6, 8, 10, 12, 14, 16, 1, 3, 5, 7, 9, 11, 13, 15, 17};
const int N = sizeof(A) / sizeof(int);
+// Check that starting with a value the predicate returns true for
+// works too. (PR52822)
+const int A2[] = {2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17};
+const int B2[] = {2, 4, 6, 8, 10, 12, 14, 16, 3, 5, 7, 9, 11, 13, 15, 17};
+const int N2 = sizeof(A2) / sizeof(int);
+
struct Pred
{
bool
@@ -46,7 +52,8 @@ struct Pred
{ return (x.val % 2) == 0; }
};
-// 25.2.12 stable_partition()
+// 25.2.12 stable_partition(), starting with a value for which the
+// predicate returns false.
void
test01()
{
@@ -60,9 +67,25 @@ test01()
VERIFY( std::equal(s1, s1 + N, B) );
}
+// 25.2.12 stable_partition(), starting with a value for which the
+// predicate returns true.
+void
+test02()
+{
+ bool test __attribute__((unused)) = true;
+
+ rvalstruct s1[N2];
+ std::copy(A2, A2 + N2, s1);
+ Container con(s1, s1 + N2);
+
+ std::stable_partition(con.begin(), con.end(), Pred());
+ VERIFY(
Re: [ping 6] [patch] attribute to reverse bitfield allocations (is anyone even reading these?)
On Apr 2, 2012, at 12:41 PM, DJ Delorie wrote: Ping 6... It's now been over EIGHT MONTHS since I posted the patch, back in stage 1 for 4.7. Can someone please review and/or approve this before gcc 4.8's stage 1 is closed? This is needed as a first step for ABI compatibility for rx-elf. Set up a cron job to ping once a day. :-) Did you ever dig up the Apple test cases from the APPLE LOCAL work I pointed you at earlier? They will be more comprehensive that any testing you've done, and, if you get them to all pass, the work should be closer to being complete. The feature needed a ton of testcases, a few didn't cut it.
Re: [PATCH] ARM: Use different linker path for hardfloat ABI
On 3 April 2012 09:06, dann frazier dann.fraz...@canonical.com wrote:
On Fri, Mar 30, 2012 at 06:52:34PM +0100, Richard Earnshaw wrote:
On 29/03/12 20:34, dann frazier wrote:
This is an updated version of a patch Debian and Ubuntu are using to
use an alternate linker path for hardfloat binaries. The difference
with this one is that it covers the case where no float flag
was passed in, defaulting to the softfloat path.
Hi Dann. The change should be in the EABI specific linux-eabi.h
instead of the shared/OABI linux-elf.h. It breaks support for uClibc
and Bionic by always using the GLIBC loader in hard float mode. The
final line in the spec is missing a '=hard' and always adds
/lib/ld-linux.so.3.
How about:
2012-04-03 Michael Hope michael.h...@linaro.org
* config/arm/linux-eabi.h (GLIBC_DYNAMIC_LINKER_HARD_FLOAT): Define.
(GLIBC_DYNAMIC_LINKER): Redefine to use the hard float loader.
diff --git a/gcc/config/arm/linux-eabi.h b/gcc/config/arm/linux-eabi.h
index 80bd825..8498472 100644
--- a/gcc/config/arm/linux-eabi.h
+++ b/gcc/config/arm/linux-eabi.h
@@ -62,7 +62,12 @@
/* Use ld-linux.so.3 so that it will be possible to run classic
GNU/Linux binaries on an EABI system. */
#undef GLIBC_DYNAMIC_LINKER
-#define GLIBC_DYNAMIC_LINKER /lib/ld-linux.so.3
+#define GLIBC_DYNAMIC_LINKER_SOFT_FLOAT /lib/ld-linux.so.3
+#define GLIBC_DYNAMIC_LINKER_HARD_FLOAT
/lib/arm-linux-gnueabihf/ld-linux.so.3
+#define GLIBC_DYNAMIC_LINKER \
+ %{mhard-float: GLIBC_DYNAMIC_LINKER_HARD_FLOAT } \
+%{mfloat-abi=hard: GLIBC_DYNAMIC_LINKER_HARD_FLOAT } \
+%{!mfloat-abi=hard:%{!mhard-float: GLIBC_DYNAMIC_LINKER_SOFT_FLOAT }}
/* At this point, bpabi.h will have clobbered LINK_SPEC. We want to
use the GNU/Linux version, not the generic BPABI version. */
which works for the following test cases:
gcc -mhard-float foo.c = /lib/arm-linux-gnueabihf/ld-linux.so.3
gcc -mfloat-abi=hard foo.c = /lib/arm-linux-gnueabihf/ld-linux.so.3
gcc -msoft-float foo.c = /lib/ld-linux.so.3
gcc -mfloat-abi=softfp foo.c = /lib/ld-linux.so.3
gcc -mbionic = /system/bin/linker
gcc -mbionic -mhard-float = /system/bin/linker
gcc -muclibc = /lib/ld-uClibc.so.0
gcc -muclibc -mhard-float = /lib/ld-uClibc.so.0
-- Michael
