Re: [PATCH] [GOMP4] OpenACC 1.0+ support in fortran front-end
Hi, Thomas! Likewise, if you have any comments on my patch series for »initial support for OpenACC data clauses«, I'd like to hear them. Sure: + else if (!strcmp (present_or_copy, p)) +result = PRAGMA_OMP_CLAUSE_PRESENT_OR_COPY; + else if (!strcmp (present_or_copyin, p)) +result = PRAGMA_OMP_CLAUSE_PRESENT_OR_COPYIN; + else if (!strcmp (present_or_copyout, p)) +result = PRAGMA_OMP_CLAUSE_PRESENT_OR_COPYOUT; + else if (!strcmp (present_or_create, p)) +result = PRAGMA_OMP_CLAUSE_PRESENT_OR_CREATE; For these combined clauses the specification specifies short names: pcopy, pcopyin, pcopyout and pcreate (see 2.6.5.9 - 2.6.5.12 of OpenACC 2.0). And otherwise, as you state that you'd base your work on this, it probably makes sense if I commit my patches soon? (I now also have to rebase my patches onto the updated gomp-4_0-branch.) Yes, it would be great! -- Ilmir.
[Ada] Include constant objects in SPARK cross references
The cross references generated for formal verification in GNATprove mode did not include constant objects. The needs have changed, and these should be included now, with a specific type character 'c' to distinguish them from references to non-constant objects. Tested on x86_64-pc-linux-gnu, committed on trunk 2014-01-27 Yannick Moy m...@adacore.com * get_spark_xrefs.adb (Get_SPARK_Xrefs): Accept new type 'c' for reference. * lib-xref-spark_specific.adb (Is_Global_Constant): Remove useless function now. (Add_SPARK_Xrefs): Include references to constants. * spark_xrefs.ads Document new character 'c' for references to constants. Index: lib-xref-spark_specific.adb === --- lib-xref-spark_specific.adb (revision 207120) +++ lib-xref-spark_specific.adb (working copy) @@ -334,10 +334,6 @@ S : Scope_Index) return Boolean; -- Check whether entity E is in SPARK_Scope_Table at index S or higher - function Is_Global_Constant (E : Entity_Id) return Boolean; - -- Return True if E is a global constant for which we should ignore - -- reads in SPARK. - function Lt (Op1 : Natural; Op2 : Natural) return Boolean; -- Comparison function for Sort call @@ -440,14 +436,6 @@ if Ekind (E) in Overloadable_Kind then return Typ = 's'; - -- References to constant objects are not considered in SPARK - -- section, as these will be translated as constants in the - -- intermediate language for formal verification, and should - -- therefore never appear in frame conditions. - - elsif Is_Constant_Object (E) then -return False; - -- Objects of Task type or protected type are not SPARK references elsif Present (Etype (E)) @@ -526,16 +514,6 @@ return False; end Is_Future_Scope_Entity; - - -- Is_Global_Constant -- - - - function Is_Global_Constant (E : Entity_Id) return Boolean is - begin - return Ekind (E) = E_Constant - and then Ekind_In (Scope (E), E_Package, E_Package_Body); - end Is_Global_Constant; - -- Lt -- @@ -726,7 +704,6 @@ and then SPARK_References (Ref.Typ) and then Is_SPARK_Scope (Ref.Ent_Scope) and then Is_SPARK_Scope (Ref.Ref_Scope) - and then not Is_Global_Constant (Ref.Ent) and then Is_SPARK_Reference (Ref.Ent, Ref.Typ) -- Discard references from unknown scopes, e.g. generic scopes @@ -805,6 +782,7 @@ declare Ref_Entry : Xref_Entry renames Xrefs.Table (Rnums (Refno)); Ref : Xref_Key renames Ref_Entry.Key; +Typ : Character; begin -- If this assertion fails, the scope which we are looking for is @@ -844,6 +822,17 @@ Col := Int (Get_Column_Number (Ref_Entry.Def)); end if; +-- References to constant objects are considered specially in +-- SPARK section, because these will be translated as constants in +-- the intermediate language for formal verification, and should +-- therefore never appear in frame conditions. + +if Is_Constant_Object (Ref.Ent) then + Typ := 'c'; +else + Typ := Ref.Typ; +end if; + SPARK_Xref_Table.Append ( (Entity_Name = Ref_Name, Entity_Line = Line, @@ -852,7 +841,7 @@ File_Num= Dependency_Num (Ref.Lun), Scope_Num = Get_Scope_Num (Ref.Ref_Scope), Line= Int (Get_Logical_Line_Number (Ref.Loc)), - Rtype = Ref.Typ, + Rtype = Typ, Col = Int (Get_Column_Number (Ref.Loc; end; end loop; Index: spark_xrefs.ads === --- spark_xrefs.ads (revision 207120) +++ spark_xrefs.ads (working copy) @@ -177,6 +177,7 @@ --m = modification --r = reference + --c = reference to constant object --s = subprogram reference in a static call -- Special entries for reads and writes to memory reference a special @@ -229,6 +230,7 @@ Rtype : Character; -- Indicates type of reference, using code used in ALI file: --r = reference + --c = reference to constant object --m = modification --s = call Index: get_spark_xrefs.adb === --- get_spark_xrefs.adb (revision 207120) +++ get_spark_xrefs.adb (working copy) @@ -455,6 +455,7 @@ pragma
[Ada] Fix incorrect reason in exception information for range check
When a dynamic run-time range check was generated to check the bounds of an aggregate, the reason was wrong, resulting in an exception message saying length check failed instead of range check failed. The following test: 1. with Ada.Exceptions; use Ada.Exceptions; 2. with Ada.Text_IO; use Ada.Text_IO; 3. procedure MissLenCheck is 4.function F return Integer is (1); 5. begin 6.begin 7. declare 8. X : String (F .. F) := (F - 1 = '0'); 9. begin 10. null; 11. end; 12. Put_Line (case 1: no exception); 13.exception 14. when x : others = 15. Put_Line (case 1: Exception_Information (X)); 16.end; 17. 18.begin 19. declare 20. Y : String (1 .. 1) := (0 = '0'); | warning: lower bound of aggregate out of range warning: Constraint_Error will be raised at run time 21. begin 22. null; 23. end; 24. Put_Line (case 2: no exception); 25.exception 26. when x : others = 27. Put_Line (case 2: Exception_Information (X)); 28.end; 29. end MissLenCheck; generates at run-time: case 1: Exception name: CONSTRAINT_ERROR Message: misslencheck.adb:8 range check failed case 2: Exception name: CONSTRAINT_ERROR Message: misslencheck.adb:20 range check failed Before this patch, the first message said length check Tested on x86_64-pc-linux-gnu, committed on trunk 2014-01-27 Robert Dewar de...@adacore.com * exp_aggr.adb (Check_Bounds): Reason is range check, not length check. Index: exp_aggr.adb === --- exp_aggr.adb(revision 207120) +++ exp_aggr.adb(working copy) @@ -4141,7 +4141,7 @@ Insert_Action (N, Make_Raise_Constraint_Error (Loc, Condition = Cond, -Reason= CE_Length_Check_Failed)); +Reason= CE_Range_Check_Failed)); end if; end Check_Bounds;
[Ada] Assign and Copy do not work for ordered and hashed maps
Subprograms Assign and Copy in Containers.Ordered_Maps and Containers.Hashed_Maps were not assigning or copying anything. This patch fixes that. The test is to use these subprograms with a non empty Source map and to check that the Target map is not empty. Tested on x86_64-pc-linux-gnu, committed on trunk 2014-01-27 Vincent Celier cel...@adacore.com * a-coorma.adb, a-cohama.adb (Assign): Copy the Source to the Target, not the Target to itself. Index: a-coorma.adb === --- a-coorma.adb(revision 207120) +++ a-coorma.adb(working copy) @@ -274,7 +274,7 @@ end if; Target.Clear; - Insert_Items (Target.Tree); + Insert_Items (Source.Tree); end Assign; - Index: a-cohama.adb === --- a-cohama.adb(revision 207120) +++ a-cohama.adb(working copy) @@ -167,7 +167,7 @@ Target.Reserve_Capacity (Source.Length); end if; - Insert_Items (Target.HT); + Insert_Items (Source.HT); end Assign; --
[Ada] Fix irregularity in tree generated for SPARK
The compiler now uses Replace instead of Rewrite, when the semantic analyzer discovers that what looked like a selected component was in factt a function call. This avoids a special case in ASIS for handling an undecorated original node. This is an internal change only with no functional effect (basically it is a cleanup in the interface between the front end and ASIS). The following test, compiled with -gnatdt 1. procedure Ololo is 2. type Rec is record 3.C : Integer; 4. end record; 5. Rec_0 : Rec := (C = 0); 6. function Fun return Rec is 7. begin 8.return Rec_0; 9. end Fun; 10. I : Integer; 11. begin 12. I := Ololo.Fun.C; 13. end Ololo; generates output which does NOT contain any instance of the string: Rewritten: original node = N_Expanded_Name Previously there was one occurrence Tested on x86_64-pc-linux-gnu, committed on trunk 2014-01-27 Robert Dewar de...@adacore.com * sem_ch8.adb (Find_Selected_Component): Use Replace instead of Rewrite. Index: sem_ch8.adb === --- sem_ch8.adb (revision 207120) +++ sem_ch8.adb (working copy) @@ -6296,9 +6296,10 @@ -- If no interpretation as an expanded name is possible, it -- must be a selected component of a record returned by a -- function call. Reformat prefix as a function call, the rest - -- is done by type resolution. If the prefix is procedure or - -- entry, as is P.X; this is an error. + -- is done by type resolution. + -- Error if the prefix is procedure or entry, as is P.X + if Ekind (P_Name) /= E_Function and then (not Is_Overloaded (P) @@ -6309,7 +6310,6 @@ -- chain, the candidate package may be anywhere on it. if Present (Homonym (Current_Entity (P_Name))) then - P_Name := Current_Entity (P_Name); while Present (P_Name) loop @@ -6327,6 +6327,7 @@ Set_Entity (Prefix (N), P_Name); Find_Expanded_Name (N); return; + else P_Name := Entity (Prefix (N)); end if; @@ -6338,11 +6339,27 @@ Set_Entity (N, Any_Id); Set_Etype (N, Any_Type); + -- Here we have a function call, so do the reformatting + else Nam := New_Copy (P); Save_Interps (P, Nam); - Rewrite (P, + + -- We use Replace here because this is one of those cases + -- where the parser has missclassified the node, and we + -- fix things up and then do the semantic analysis on the + -- fixed up node. Normally we do this using one of the + -- Sinfo.CN routines, but this is too tricky for that. + + -- Note that using Rewrite would be wrong, because we + -- would have a tree where the original node is unanalyzed, + -- and this violates the required interface for ASIS. + + Replace (P, Make_Function_Call (Sloc (P), Name = Nam)); + + -- Now analyze the reformatted node + Analyze_Call (P); Analyze_Selected_Component (N); end if;
[Ada] Refined external states
This patch implements the following rules concerning the refinement of external abstract states: * A state abstraction that is not specified as External shall not have constituents which are External states. * An External state abstraction shall have at least one constituent that is External state, or shall have a null refinement. * An External state abstraction shall have each of the properties set to True which are True for any of its constituents. * Refined_Global aspects must respect the rules related to external properties of constituents which are external states given in External State and External State - Variables. -- Source -- -- semantics.ads package Semantics with Abstract_State = (State, (AR_AW_ER_EW_State_1 with External), (AR_AW_ER_EW_State_2 with External), (AR_AW_ER_EW_State_3 with External), (AR_EW_State with External = (Async_Readers, Effective_Writes)), (AW_ER_State with External = (Async_Writers, Effective_Reads))) is procedure Proc with Global = (Input = AW_ER_State); end Semantics; -- semantics.adb package body Semantics with Refined_State = (State = (Var_1, AR_1), -- error AR_AW_ER_EW_State_1 = null, -- ok AR_AW_ER_EW_State_2 = (Var_2_1, Var_2_2), -- error AR_AW_ER_EW_State_3 = (AR_EW_3, AW_3), -- error AR_EW_State = (AW_ER_4, AR_EW_4), -- error AW_ER_State = AW_ER_5)-- ok is Var_1 : Integer := 1; Var_2_1 : Integer := 2; Var_2_2 : Integer := 3; AR_1: Integer := 4 with Volatile, Async_Readers; AR_EW_3 : Integer := 5 with Volatile, Async_Readers, Effective_Writes; AW_3: Integer := 6 with Volatile, Async_Writers; AR_EW_4 : Integer := 7 with Volatile, Async_Readers, Effective_Writes; AW_ER_4 : Integer := 8 with Volatile, Async_Writers, Effective_Reads; AW_ER_5 : Integer := 9 with Volatile, Async_Writers, Effective_Reads; procedure Proc with Refined_Global = (Input = AW_ER_5) -- error is begin null; end Proc; end Semantics; -- Compilation and output -- $ gcc -c semantics.adb semantics.adb:3:06: non-external state State cannot contain external constituents in refinement (SPARK RM 7.2.8(1)) semantics.adb:7:06: external state Ar_Aw_Er_Ew_State_2 requires at least one external constituent or null refinement (SPARK RM 7.2.8(2)) semantics.adb:9:06: external state Ar_Aw_Er_Ew_State_3 requires at least one constituent with property Effective_Reads (SPARK RM 7.2.8(3)) semantics.adb:11:06: external state Ar_Ew_State lacks property Async_Writers set by constituent Aw_Er_4 (SPARK RM 7.2.8(3)) semantics.adb:27:39: volatile global item AW_ER_5 with property Effective_Reads must have mode In_Out or Output (SPARK RM 7.1.3(11)) Tested on x86_64-pc-linux-gnu, committed on trunk 2014-01-27 Hristian Kirtchev kirtc...@adacore.com * einfo.adb (Has_Option): Reimplemented. * sem_prag.adb (Analyze_Refinement_Clause): Add global variables AR_Constit, AW_Constit, ER_Constit, EW_Constit, External_Constit_Seen and State. Add local variables Body_Ref, Body_Ref_Elmt and Extra_State. Reimplement part of the logic to avoid a cumbersome while pool. Verify the legality of an external state and relevant properties. (Check_External_Property): New routine. (Check_Matching_State): Remove parameter profile and update comment on usage. (Collect_Constituent): Store the relevant external property of a constituent. * sem_util.adb (Async_Readers_Enabled): Update the call to Has_Enabled_Property. (Async_Writers_Enabled): Update the call to Has_Enabled_Property. (Effective_Reads_Enabled): Update the call to Has_Enabled_Property. (Effective_Writes_Enabled): Update the call to Has_Enabled_Property. (Has_Enabled_Property): Rename formal parameter Extern to State_Id. Update comment on usage. Reimplement the logic to recognize the various formats of properties. Index: einfo.adb === --- einfo.adb (revision 207138) +++ einfo.adb (working copy) @@ -589,10 +589,10 @@ --- function Has_Option - (State : Entity_Id; - Opt_Nam : Name_Id) return Boolean; - -- Determine whether abstract state State has a particular option denoted - -- by the name Opt_Nam. + (State_Id : Entity_Id; + Option_Nam : Name_Id) return Boolean; + -- Determine whether abstract state State_Id has particular option denoted + -- by the name Option_Nam. --- -- Float_Rep -- @@ -609,33 +609,56 @@ function Has_Option - (State : Entity_Id; - Opt_Nam : Name_Id) return Boolean + (State_Id : Entity_Id; +
[Ada] Do not service entries after a protected function call (with -gnatp).
For single entry protected objects, the entry was served (in case of pending call and when compiled without checks) after a function call. This is useless, and not coherent with code generated without -gnatp. The following program displays 'Barrier called' only three times: gnatmake -gnatp main ./main Barrier called Barrier called Barrier called package prot is protected P is procedure proc; function fun return integer; entry en; procedure release; private released : boolean := false; end p; end prot; with ada.text_io; use ada.text_io; package body prot is function Barrier return boolean is begin put_line (Barrier called); return false; end Barrier; protected body P is procedure proc is begin null; end proc; function fun return integer is begin return 1; end fun; procedure release is begin released := true; end release; entry en when Barrier or else released is begin null; end en; end p; task T; task body T is begin P.en; end T; end prot; with prot; procedure main is v : integer; begin delay 1.0; v := prot.p.fun; prot.p.release; end; Tested on x86_64-pc-linux-gnu, committed on trunk 2014-01-27 Tristan Gingold ging...@adacore.com * exp_ch7.adb (Build_Cleanup_Statements): Call Build_Protected_Subprogram_Call_Cleanup to insert the cleanup for protected body. * exp_ch9.adb (Build_Protected_Subprogram_Body): Likewise. Remove Service_Name variable. (Build_Protected_SUbprogam_Call_Cleanup): New procedure that factorize code from the above subprograms. * exp_ch9.ads (Build_Protected_Subprogram_Call_Cleanup): New procedure. Index: exp_ch7.adb === --- exp_ch7.adb (revision 207140) +++ exp_ch7.adb (working copy) @@ -511,7 +511,6 @@ declare Spec : constant Node_Id := Parent (Corresponding_Spec (N)); Conc_Typ : Entity_Id; -Nam : Node_Id; Param : Node_Id; Param_Typ : Entity_Id; @@ -532,81 +531,15 @@ pragma Assert (Present (Param)); --- If the associated protected object has entries, a protected --- procedure has to service entry queues. In this case generate: +-- Historical note: In earlier versions of GNAT, there was code +-- at this point to generate stuff to service entry queues. But +-- that was wrong thinking. This was useless and resulted in +-- incoherencies between code generated with and without -gnatp. ---Service_Entries (_object._object'Access); +-- All that is needed at this stage is a normal cleanup call -if Nkind (Specification (N)) = N_Procedure_Specification - and then Has_Entries (Conc_Typ) -then - case Corresponding_Runtime_Package (Conc_Typ) is - when System_Tasking_Protected_Objects_Entries = - Nam := New_Reference_To (RTE (RE_Service_Entries), Loc); - - when System_Tasking_Protected_Objects_Single_Entry = - Nam := New_Reference_To (RTE (RE_Service_Entry), Loc); - - when others = - raise Program_Error; - end case; - - Append_To (Stmts, - Make_Procedure_Call_Statement (Loc, - Name = Nam, - Parameter_Associations = New_List ( - Make_Attribute_Reference (Loc, - Prefix = - Make_Selected_Component (Loc, - Prefix= New_Reference_To ( - Defining_Identifier (Param), Loc), - Selector_Name = - Make_Identifier (Loc, Name_uObject)), - Attribute_Name = Name_Unchecked_Access; - -else - -- Generate: - --Unlock (_object._object'Access); - - case Corresponding_Runtime_Package (Conc_Typ) is - when System_Tasking_Protected_Objects_Entries = - Nam := New_Reference_To (RTE (RE_Unlock_Entries), Loc); - - when System_Tasking_Protected_Objects_Single_Entry = - Nam := New_Reference_To (RTE (RE_Unlock_Entry), Loc); - - when System_Tasking_Protected_Objects = - Nam := New_Reference_To (RTE (RE_Unlock), Loc); - - when others = - raise Program_Error; - end case; - - Append_To (Stmts, - Make_Procedure_Call_Statement (Loc, - Name = Nam, - Parameter_Associations =
Re: [PATCH, ARM] ICE when building kernel raid6 neon code
On Thu, Jan 16, 2014 at 5:44 AM, Zhenqiang Chen zhenqiang.c...@linaro.org wrote: Thanks for comments. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59837 The patch with a test case is attached. +/* { dg-options -Os -fno-omit-frame-pointer -mapcs -mabi=aapcs-linux -marm -mfloat-abi=softfp -g } */ Can you instead do ? { dg-options -Os -fno-omit-frame-pointer -mapcs } { dg-add-options arm_neon } I don't like this as it as it stands because the test relies on the compiler being configured for neon by default. regards Ramana ChangeLog: 2014-01-16 Zhenqiang Chen zhenqiang.c...@linaro.org PR target/59837 * config/arm/arm.c (arm_emit_vfp_multi_reg_pop): Do not add REG_CFA_ADJUST_CFA NOTE if shrink-wrap is not enabled. testsuite/ChangeLog: 2014-01-16 Zhenqiang Chen zhenqiang.c...@linaro.org * gcc.target/arm/pr59837.c: New testcase. On 15 January 2014 19:56, Ramana Radhakrishnan ramana.radhakrish...@arm.com wrote: Please also create a bugzilla entry for this and use the pr number here. Ramana Sent from Samsung Mobile Original message From: Zhenqiang Chen zhenqiang.c...@linaro.org Date: To: gcc-patches@gcc.gnu.org Cc: Richard Earnshaw richard.earns...@arm.com,Ramana Radhakrishnan ramana.radhakrish...@arm.com Subject: [PATCH, ARM] ICE when building kernel raid6 neon code Hi, The patch fixes ICE when building kernel raid6 neon code. lib/raid6/neon4.c: In function 'raid6_ neon4_gen_syndrome_real': lib/raid6/neon4.c:113:1: internal compiler error: in dwarf2out_frame_debug_adjust_cfa, at dwarf2cfi.c:1090 } https://bugs.launchpad.net/gcc-linaro/+bug/1268893 Root cause: When expanding epilogue, REG_CFA_ADJUST_CFA NOTE is added to handle dwarf info issue for shrink-wrap. But for TARGET_APCS_FRAME, shrink-wrap is disabled. And not all dwarf info in arm_expand_epilogue_apcs_frame are correctly updated. arm_emit_vfp_multi_reg_pop is called by both arm_expand_epilogue_apcs_frame and arm_expand_epilogue. So we should not add the NOTE in arm_emit_vfp_multi_reg_pop if shrink-wrap is not enabled. Boot strap and no make check regression on ARM Chromebook. OK for trunk? Thanks! -Zhenqiang ChangeLog: 2014-01-15 Zhenqiang Chen zhenqiang.c...@linaro.org * config/arm/arm.c (arm_emit_vfp_multi_reg_pop): Do not add REG_CFA_ADJUST_CFA NOTE if shrink-wrap is not enabled. diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c index 18196b3..1ccb796 100644 --- a/gcc/config/arm/arm.c +++ b/gcc/config/arm/arm.c @@ -19890,8 +19890,12 @@ arm_emit_vfp_multi_reg_pop (int first_reg, int num_regs, rtx base_reg) par = emit_insn (par); REG_NOTES (par) = dwarf; - arm_add_cfa_adjust_cfa_note (par, 2 * UNITS_PER_WORD * num_regs, - base_reg, base_reg); + /* REG_CFA_ADJUST_CFA NOTE is added to handle dwarf info issue when + shrink-wrap is enabled. So when shrink-wrap is not enabled, we should + not add the note. */ + if (flag_shrink_wrap) +arm_add_cfa_adjust_cfa_note (par, 2 * UNITS_PER_WORD * num_regs, +base_reg, base_reg); } /* Generate and emit a pattern that will be recognized as LDRD pattern. If even -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782
Re: C vs. C++ breakage on 4.7 (was Re: [Patch, fortran] PR58007: unresolved fixup hell)
On Mon, Jan 27, 2014 at 06:17:38PM +0100, Richard Biener wrote: Huh, so we have C for cross-builds and C++ for bootstraps. No, we use a C host compiler in both cases. Only stages 2 and 3 build with a C++ compiler. And even for stage{2,3} C can be optionally used by asking for it using a configure option. So, please no C++ on the 4.7 branch. Jakub
Re: C vs. C++ breakage on 4.7 (was Re: [Patch, fortran] PR58007: unresolved fixup hell)
Hans-Peter Nilsson h...@bitrange.com wrote: On Mon, 27 Jan 2014, Mikael Morin wrote: Le 27/01/2014 02:56, Hans-Peter Nilsson a écrit : On Sun, 26 Jan 2014, Mikael Morin wrote: Le 18/01/2014 21:17, Mikael Morin a écrit : Well, I guess that due to the touchy nature of the bug, there are cases that work by luck on old versions and fail (by unluck) on newer ones. Thus, I will backport in a few days to 4.8 and 4.7. I added the following hardening to the patch on the 4.8 backport (http://gcc.gnu.org/r207117 and attached) and forward-ported it to trunk (http://gcc.gnu.org/r207118) as well. 4.7 will come in an hour or so. Did you bootstrap test the 4.7 backport? Yes, works like a charm here. Huh, so we have C for cross-builds and C++ for bootstraps. No, we use a C host compiler in both cases. Only stages 2 and 3 build with a C++ compiler. Richard. I wish we could retire that difference *also* on the 4.7 branch (using either C *or* C++ for *both* would be fine with me FWIW). I believe we're now eperiencing more problems than benefits with that difference, now that the migration is over. Looks like you committed C++ code there, in module.c: Alright; can you try the attached patch? Sorry, not at the moment, but I see Janus took care of that (thanks) and it looks pretty obvious to me. It'll be noticed when it's committed... brgds, H-P
[patch] fix libstdc++/59215
This fixes a tsan warning in shared_ptr by replacing the non-atomic load with a call to _M_get_use_count() which does a relaxed atomic load. Tested x86_64-linux, committed to trunk. Will commit to 4.8 soon too. commit a795f4e757d0f0ca11324a2c4f62cbe1bd876ec7 Author: Jonathan Wakely jwak...@redhat.com Date: Mon Jan 27 17:01:25 2014 + PR libstdc++/59215 * include/bits/shared_ptr_base.h (_Sp_counted_base_S_atomic::_M_add_ref_lock()): Use relaxed atomic load. diff --git a/libstdc++-v3/include/bits/shared_ptr_base.h b/libstdc++-v3/include/bits/shared_ptr_base.h index 83724e4..1c3a47d 100644 --- a/libstdc++-v3/include/bits/shared_ptr_base.h +++ b/libstdc++-v3/include/bits/shared_ptr_base.h @@ -233,7 +233,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION _M_add_ref_lock() { // Perform lock-free add-if-not-zero operation. - _Atomic_word __count = _M_use_count; + _Atomic_word __count = _M_get_use_count(); do { if (__count == 0)
Re: [Patch][AArch64] NEON vdup testcases
On 16 January 2014 12:12, Alex Velenko alex.vele...@arm.com wrote: This patch implements test cases for following NEON intrinsics: vdup_lane_f32 vdup_lane_s[8,16] vdup_lane_s[32,64] vdup_n_[p,s,u][8,16] vdup_n_[s,u][32,64] vdupb_lane_[s,u]8 vduph_lane_[s,u]16 vdupd_lane_[f,s,u]64 vdups_lane_[f,s,u]32 vdupq_lane_[f,s][32,64] vdupq_lane_s[8,16] vdup[q]_n_f32 vdupq_n_f64 vdupq_n_[s,p,u][8,16] vdupq_n_[s,u][32,64] +int +__attribute__ ((noinline)) test_vdupq_lane_s16 () The function name should be placed in column1, hence the above should be written: int __attribute__ ((noinline)) test_vdupq_lane_s16 () +/* Covers vdups_lane_f32, vdups_lane_s32, vdups_lane_u32. */ +/* { dg-final { scan-assembler-times dup\\ts\[0-9\]+, v\[0-9\]+\.s\\\[0\\\] 3 } } */ +/* { dg-final { scan-assembler-times dup\\ts\[0-9\]+, v\[0-9\]+\.s\\\[1\\\] 3 } } */ + +#212 /work/tempdev//src/gcc/gcc/testsuite/gcc.target/aarch64/vdup_lane_2.c This should not be here. Cheers /Marcus
Re: [GOOGLE] Adjust profile for AutoFDO
Ok. For future cleanup, It will be better to define a new helper function is_profile_missing_p (cfun) -- which checks entry count for instrumentation based FDO, and something else for autofdo. David On Fri, Jan 24, 2014 at 9:28 PM, Dehao Chen de...@google.com wrote: This patch fixes performance regression for AutoFDO. When the entry block count is 0, which is quite possible in AutoFDO, it can still make right optimization decision. Bootstrapped passed regression test and performance test (improve 0.5% on average). OK for google-4_8? Thanks, Dehao
[jit] Remove GCC_JIT_BINARY_OP_FLOATING_DIVIDE
Committed to branch dmalcolm/jit: gcc/jit/ * libgccjit.h (enum gcc_jit_binary_op): Remove GCC_JIT_BINARY_OP_FLOATING_DIVIDE, which I accidentally added as part of a880c0d9c642730550f39d328f29a1d9935cb07e. --- gcc/jit/ChangeLog.jit | 6 ++ gcc/jit/libgccjit.h | 6 -- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/gcc/jit/ChangeLog.jit b/gcc/jit/ChangeLog.jit index 0868fc3..3e8d2d3 100644 --- a/gcc/jit/ChangeLog.jit +++ b/gcc/jit/ChangeLog.jit @@ -1,3 +1,9 @@ +2014-01-27 David Malcolm dmalc...@redhat.com + + * libgccjit.h (enum gcc_jit_binary_op): Remove + GCC_JIT_BINARY_OP_FLOATING_DIVIDE, which I accidentally added + as part of a880c0d9c642730550f39d328f29a1d9935cb07e. + 2014-01-24 David Malcolm dmalc...@redhat.com * libgccjit.h: Update comments to eliminate the code-creation diff --git a/gcc/jit/libgccjit.h b/gcc/jit/libgccjit.h index 7f4f2d0..fa71518 100644 --- a/gcc/jit/libgccjit.h +++ b/gcc/jit/libgccjit.h @@ -480,12 +480,6 @@ enum gcc_jit_binary_op a floating-point result type indicates floating-point division. */ GCC_JIT_BINARY_OP_DIVIDE, - /* Quotient of division of floating-point values, without rounding; - analogous to: - (EXPR_A) / (EXPR_B) - in C. */ - GCC_JIT_BINARY_OP_FLOATING_DIVIDE, - /* Remainder of division of arithmetic values; analogous to: (EXPR_A) / (EXPR_B) in C. */ -- 1.7.11.7
[RFA][PR 16361] Add warnings for NULL pointer dereferences and such
[ Yes, 16351, it's that old. ] First, as is often the case, this warning is not going to catch everything. Dead code elimination, unreachable code elimination, etc can/will remove NULL pointer dereferences and if that happens we don't get a warning. It also will not catch cases where a NULL value flows out of a PHI into uses in other blocks where it is then dereferenced or otherwise used erroneously. -Wnull-dereference will warn for NULL pointer dereferences. Both those which appear explicitly in the IL and those which occur if NULL value flows from a PHI to a dereference in the same block as the PHI. -Wnull-attribute will warn if NULL is used as an argument to a function call where the callee's attributes have declared the argument must be non-NULL. Similarly for NULL as a return value when the current function has an attribute declaring the function can never return NULL. Similarly for NULL values flowing from a PHI into an argument/return in the same block as the PHI. We utilize the analysis done for the erroneous-paths optimization. The optimizations and warnings can be enabled/disabled independently. The warnings are not enabled by -Wall. The testsuite verifies basic operation by re-using the existing isolation tests. Each test was split into two tests. One which tests the warning (with the optimization explicitly disabled), the other which tests the optimization. Earlier versions of this patch have been bootstrapped and regression tested. The only difference between those earlier versions and this one are the docs additions to the testsuite. As with prior patches of mine that touched common.opt, particular attention to those changes would be appreciated. OK, assuming it passes another round of bootstrapping and regression testing? Jeff diff --git a/gcc/ChangeLog b/gcc/ChangeLog index 95a324c..8ffbc50 100644 --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@ -1,3 +1,17 @@ +2014-01-27 Jeff Law l...@redhat.com + + * common.opt (Wnull-dereference): New option. + (Wnull-attribute): Likewise. + * doc/invoke.texi: Document new warnings. + * gimple-ssa-isolate-paths.c: (find_implicit_erroneous_behaviour): Warn + for NULL dereferences and NULL values flowing into arguments or + return values where an attribute indicates that should never happen. + Do not optimize unless the optimization is enabled. + (find_explicit_erroneous_behaviour): Similarly. + (gate_isolate_erroneous_paths): Run if we want the optimization + or the warning. + + 2014-01-27 Jakub Jelinek ja...@redhat.com PR bootstrap/59934 diff --git a/gcc/common.opt b/gcc/common.opt index d334cf2..dcff512 100644 --- a/gcc/common.opt +++ b/gcc/common.opt @@ -576,6 +576,17 @@ Wlarger-than= Common RejectNegative Joined UInteger Warning -Wlarger-than=number Warn if an object is larger than number bytes +Wnull-dereference +Common Var(warn_null_dereference) Warning +Warn if the compiler detects paths which trigger erroneous or undefined +behaviour due to dereferencing a NULL pointer. + +Wnull-attribute +Common Var(warn_null_attribute) Warning +Warn if the compiler detects paths which trigger erroneous or undefined +behaviour due to passing a NULL value for an argument which must be non-NULL or +if a function returns NULL when it has been declared as must not return NULL. + Wunsafe-loop-optimizations Common Var(warn_unsafe_loop_optimizations) Warning Warn if the loop cannot be optimized due to nontrivial assumptions. diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index 8c620a5..81fb005 100644 --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi @@ -252,6 +252,7 @@ Objective-C and Objective-C++ Dialects}. -Wimplicit -Wimplicit-function-declaration -Wimplicit-int @gol -Winit-self -Winline -Wmaybe-uninitialized @gol -Wno-int-to-pointer-cast -Wno-invalid-offsetof @gol +-Wnull-dereference -Wnull-attribute @gol -Winvalid-pch -Wlarger-than=@var{len} -Wunsafe-loop-optimizations @gol -Wlogical-op -Wlong-long @gol -Wmain -Wmaybe-uninitialized -Wmissing-braces -Wmissing-field-initializers @gol @@ -3946,6 +3947,18 @@ In order to get a warning about an unused function parameter, you must either specify @option{-Wextra -Wunused} (note that @option{-Wall} implies @option{-Wunused}), or separately specify @option{-Wunused-parameter}. +@item -Wnull-dereference +@opindex Wnull-dereference +@opindex Wno-null-dereference +Warn if the compiler detects paths which trigger erroneous or undefined +behaviour due to dereferencing a NULL pointer. + +@item -Wnull-attribute +@opindex Wnull-attribute +@opindex Wno-null-attribute +Warn if the compiler detects paths which trigger erroneous or undefined +behaviour due to passing a NULL value for an argument which must be non-NULL or if a function returns NULL when it has been declared as must not return NULL. + @item -Wuninitialized @opindex Wuninitialized @opindex Wno-uninitialized diff
[jit] Verify argument counts within gcc_jit_context_new_call
Committed to dmalcolm/jit: gcc/jit/ * internal-api (gcc::jit::recording::context::new_call): Verify the argument count of the call against the parameter count of the function, issuing an error if there's a mismatch. * internal-api.h (gcc::jit::recording::function::get_name): New. * (gcc::jit::recording::function::get_params): New. * (gcc::jit::recording::function::is_variadic): New. gcc/testsuite/ * jit.dg/test-error-call-with-not-enough-args.c: New test case. * jit.dg/test-error-call-with-too-many-args.c: New test case. * jit.dg/test-null-passed-to-api.c: Rename to... * jit.dg/test-error-null-passed-to-api.c: ...this, so that error-handling test cases are consistently named. --- gcc/jit/internal-api.c | 20 + gcc/jit/internal-api.h | 4 + .../jit.dg/test-error-call-with-not-enough-args.c | 86 + .../jit.dg/test-error-call-with-too-many-args.c| 88 ++ .../jit.dg/test-error-null-passed-to-api.c | 31 gcc/testsuite/jit.dg/test-null-passed-to-api.c | 31 6 files changed, 229 insertions(+), 31 deletions(-) create mode 100644 gcc/testsuite/jit.dg/test-error-call-with-not-enough-args.c create mode 100644 gcc/testsuite/jit.dg/test-error-call-with-too-many-args.c create mode 100644 gcc/testsuite/jit.dg/test-error-null-passed-to-api.c delete mode 100644 gcc/testsuite/jit.dg/test-null-passed-to-api.c diff --git a/gcc/jit/internal-api.c b/gcc/jit/internal-api.c index 64a0912..cf9195d0 100644 --- a/gcc/jit/internal-api.c +++ b/gcc/jit/internal-api.c @@ -278,6 +278,26 @@ recording::context::new_call (recording::location *loc, function *func, int numargs , recording::rvalue **args) { + int min_num_params = func-get_params ().length (); + bool is_variadic = func-is_variadic (); + if (numargs min_num_params) +{ + add_error ((gcc_jit_context_new_call: + not enough arguments to function \%s\ + (got %i args, expected %i)), +func-get_name ()-c_str (), +numargs, min_num_params); + return NULL; +} + if (numargs min_num_params !is_variadic) +{ + add_error ((gcc_jit_context_new_call: + too many arguments to function \%s\ + (got %i args, expected %i)), +func-get_name ()-c_str (), +numargs, min_num_params); + return NULL; +} recording::rvalue *result = new call (this, loc, func, numargs, args); record (result); return result; diff --git a/gcc/jit/internal-api.h b/gcc/jit/internal-api.h index 15f5918..94c149b 100644 --- a/gcc/jit/internal-api.h +++ b/gcc/jit/internal-api.h @@ -608,6 +608,10 @@ public: new_loop (location *loc, rvalue *boolval); + string * get_name () const { return m_name; } + vecparam * get_params () const { return m_params; } + bool is_variadic () const { return m_is_variadic; } + private: location *m_loc; enum gcc_jit_function_kind m_kind; diff --git a/gcc/testsuite/jit.dg/test-error-call-with-not-enough-args.c b/gcc/testsuite/jit.dg/test-error-call-with-not-enough-args.c new file mode 100644 index 000..4cfa09e --- /dev/null +++ b/gcc/testsuite/jit.dg/test-error-call-with-not-enough-args.c @@ -0,0 +1,86 @@ +#include stdlib.h +#include stdio.h + +#include libgccjit.h + +#include harness.h + +#ifdef __cplusplus +extern C { +#endif + + extern void + called_function (void); + +#ifdef __cplusplus +} +#endif + +void +create_code (gcc_jit_context *ctxt, void *user_data) +{ + /* Let's try to inject the equivalent of: + extern void called_function (int p); + + void + test_caller () + { +called_function (); // missing arg + } + + and verify that the API complains about the missing argument. + */ + gcc_jit_type *void_type = +gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_VOID); + gcc_jit_type *int_type = +gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_INT); + + /* Declare the imported function. */ + gcc_jit_param *param_p = +gcc_jit_context_new_param (ctxt, NULL, int_type, p); + gcc_jit_function *called_fn = +gcc_jit_context_new_function (ctxt, NULL, + GCC_JIT_FUNCTION_IMPORTED, + void_type, + called_function, + 1, param_p, + 0); + + /* Build the test_fn. */ + gcc_jit_function *test_fn = +gcc_jit_context_new_function (ctxt, NULL, + GCC_JIT_FUNCTION_EXPORTED, + void_type, + test_caller, + 0, NULL, + 0); + /* called_function (); */ +
[patch cygwin64]: Fix building *-*-cygwin* target cross-compilers
Hi, I will apply following patch soon, if there aren't any objection. gcc/ChangeLog: 2014-01-27 Kai Tietz kti...@redhat.com * config/i386/cygwin-stdint.h (INT64_TYPE): Make dependent on target architecture instead of host. (UINT64_TYPE, INT_LEAST64_TYPE, INT_FAST16_TYPE, INT_FAST32_TYPE, INT_FAST64_TYPE, UINT_FAST16_TYPE, UINT_FAST32_TYPE, UINT_FAST64_TYPE, INTPTR_TYPE, UINTPTR_TYPE): Likewise. Regards, Kai Index: gcc/config/i386/cygwin-stdint.h === --- gcc/config/i386/cygwin-stdint.h (revision 206924) +++ gcc/config/i386/cygwin-stdint.h (working copy) @@ -24,20 +24,12 @@ #define INT8_TYPE signed char #define INT16_TYPE short int #define INT32_TYPE int -#ifdef __x86_64__ -#define INT64_TYPE long int -#else -#define INT64_TYPE long long int -#endif +#define INT64_TYPE (TARGET_64BIT ? long int : long long int) #define UINT8_TYPE unsigned char #define UINT16_TYPE short unsigned int #define UINT32_TYPE unsigned int -#ifdef __x86_64__ -#define UINT64_TYPE long unsigned int -#else -#define UINT64_TYPE long long unsigned int -#endif +#define UINT64_TYPE (TARGET_64BIT ? long unsigned int : long long unsigned int) /* Minimum-width integer types */ @@ -44,51 +36,26 @@ #define INT_LEAST8_TYPE signed char #define INT_LEAST16_TYPE short int #define INT_LEAST32_TYPE int -#ifdef __x86_64__ -#define INT_LEAST64_TYPE long int -#else -#define INT_LEAST64_TYPE long long int -#endif +#define INT_LEAST64_TYPE (TARGET_64BIT ? long int : long long int) #define UINT_LEAST8_TYPE unsigned char #define UINT_LEAST16_TYPE short unsigned int #define UINT_LEAST32_TYPE unsigned int -#ifdef __x86_64__ -#define UINT_LEAST64_TYPE long unsigned int -#else -#define UINT_LEAST64_TYPE long long unsigned int -#endif +#define UINT_LEAST64_TYPE (TARGET_64BIT ? long unsigned int : long long unsigned int) /* Fastest minimum-width integer types */ #define INT_FAST8_TYPE signed char -#ifdef __x86_64__ -#define INT_FAST16_TYPE long int -#define INT_FAST32_TYPE long int -#define INT_FAST64_TYPE long int -#else -#define INT_FAST16_TYPE int -#define INT_FAST32_TYPE int -#define INT_FAST64_TYPE long long int -#endif +#define INT_FAST16_TYPE (TARGET_64BIT ? long int : int) +#define INT_FAST32_TYPE (TARGET_64BIT ? long int : int) +#define INT_FAST64_TYPE (TARGET_64BIT ? long int : long long int) #define UINT_FAST8_TYPE unsigned char -#ifdef __x86_64__ -#define UINT_FAST16_TYPE long unsigned int -#define UINT_FAST32_TYPE long unsigned int -#define UINT_FAST64_TYPE long unsigned int -#else -#define UINT_FAST16_TYPE unsigned int -#define UINT_FAST32_TYPE unsigned int -#define UINT_FAST64_TYPE long long unsigned int -#endif +#define UINT_FAST16_TYPE (TARGET_64BIT ? long unsigned int : unsigned int) +#define UINT_FAST32_TYPE (TARGET_64BIT ? long unsigned int : unsigned int) +#define UINT_FAST64_TYPE (TARGET_64BIT ? long unsigned int : long long unsigned int) /* Integer types capable of holding object pointers */ -#ifdef __x86_64__ -#define INTPTR_TYPE long int -#define UINTPTR_TYPE long unsigned int -#else -#define INTPTR_TYPE int -#define UINTPTR_TYPE unsigned int -#endif +#define INTPTR_TYPE (TARGET_64BIT ? long int : int) +#define UINTPTR_TYPE (TARGET_64BIT ? long unsigned int : unsigned int)
Re: [PATCH 1/6] [GOMP4] OpenACC 1.0+ support in fortran front-end
Hi, Thomas Schwinge wrote: Regarding my comments, please keep in mind that I don't have a lot of Fortran experience; neither as a user nor as an implementor How about CC-ing fortran@gcc for Fortran patches - it increases the chance that some Fortran maintainer will give some comment on them. (When doing so, please add a line or so stating that it is for the branch and what is OpenACC - it makes it easier for those who haven't followed gcc-patches.) Tobias PS: I might look at the patches myself; however, I have a huge backlog of emails and didn't manage to do anything for GCC in the past month. Thus, don't hold your breath and count rather one some other Fortran maintainer.
[patch] proposed fix for libstdc++/59829
This is the best I've come up with to avoid dereferencing an invalid pointer when calling vector::data() on an empty vector. For C++03 we reurn the vector's pointer type, so can just return the internal pointer, but for C++11 we need to convert that to a raw pointer, which we do by dereferencing, so we must check if it's valid first. Any better suggestions before I commit this? (Tests pass, although I need to adjust some dg-error line numbers before committing it.) commit 60f9bb3b06ea95054d3fb442c9c212e7afe66acc Author: Jonathan Wakely jwak...@redhat.com Date: Mon Jan 27 18:35:17 2014 + PR libstdc++/59829 * include/bits/stl_vector.h (vector::data()): Do not dereference pointers when empty. * testsuite/23_containers/vector/59829.cc: New. diff --git a/libstdc++-v3/include/bits/stl_vector.h b/libstdc++-v3/include/bits/stl_vector.h index f482957..8393242 100644 --- a/libstdc++-v3/include/bits/stl_vector.h +++ b/libstdc++-v3/include/bits/stl_vector.h @@ -880,19 +880,21 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER */ #if __cplusplus = 201103L _Tp* -#else - pointer -#endif data() _GLIBCXX_NOEXCEPT - { return std::__addressof(front()); } + { return empty() ? nullptr : std::__addressof(*this-_M_impl._M_start); } -#if __cplusplus = 201103L const _Tp* + data() const _GLIBCXX_NOEXCEPT + { return empty() ? nullptr : std::__addressof(*this-_M_impl._M_start); } #else + pointer + data() _GLIBCXX_NOEXCEPT + { return this-_M_impl._M_start; } + const_pointer -#endif data() const _GLIBCXX_NOEXCEPT - { return std::__addressof(front()); } + { return this-_M_impl._M_start; } +#endif // [23.2.4.3] modifiers /** diff --git a/libstdc++-v3/testsuite/23_containers/vector/59829.cc b/libstdc++-v3/testsuite/23_containers/vector/59829.cc new file mode 100644 index 000..8d9f39d --- /dev/null +++ b/libstdc++-v3/testsuite/23_containers/vector/59829.cc @@ -0,0 +1,108 @@ +// Copyright (C) 2014 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 even 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/. + +// { dg-options -std=gnu++11 } + +// libstdc++/59829 + +#include vector + +// User-defined pointer type that throws if a null pointer is dereferenced. +templatetypename T +struct Pointer +{ + typedef T element_type; + + // typedefs for iterator_traits + typedef T value_type; + typedef std::ptrdiff_t difference_type; + typedef std::random_access_iterator_tag iterator_category; + typedef Pointer pointer; + typedef T reference; + + T* value; + + explicit Pointer(T* p = nullptr) : value(p) { } + + templatetypename U, typename Requires = decltype((T*)std::declvalU*()) +Pointer(const PointerU p) : value(p.value) { } + + T operator*() const + { +if (!value) + throw nullptr; +return *value; + } + + T* operator-() const { return value; } + + Pointer operator++() { ++value; return *this; } + Pointer operator++(int) { Pointer tmp(*this); ++value; return tmp; } + Pointer operator--() { --value; return *this; } + Pointer operator--(int) { Pointer tmp(*this); --value; return tmp; } + + Pointer operator+=(difference_type n) { value += n; return *this; } + Pointer operator-=(difference_type n) { value -= n; return *this; } + + explicit operator bool() const { return value != nullptr; } + + Pointer operator+(difference_type n) { Pointer p(*this); return p += n; } + Pointer operator-(difference_type n) { Pointer p(*this); return p -= n; } +}; + +templatetypename T +std::ptrdiff_t operator-(PointerT l, PointerT r) +{ return l.value - r.value; } + +templatetypename T +bool operator==(PointerT l, PointerT r) +{ return l.value == r.value; } + +templatetypename T +bool operator!=(PointerT l, PointerT r) +{ return l.value != r.value; } + +templatetypename T +struct Alloc +{ + typedef T value_type; + typedef PointerT pointer; + + Alloc() = default; + templatetypename U +Alloc(const AllocU) { } + + pointer allocate(std::size_t n) + { return pointer(std::allocatorT().allocate(n)); } + + void deallocate(pointer p, std::size_t n) + { std::allocatorT().deallocate(p.value, n); } +}; + +templatetypename T +bool operator==(AllocT l, AllocT r) +{ return true; } + +templatetypename T +bool operator!=(AllocT l, AllocT r) +{ return false; } +
PATCH: PR target/59672: Add -m16 support for x86
Hi, The .code16gcc directive was added to binutils back in 1999: --- '.code16gcc' provides experimental support for generating 16-bit code from gcc, and differs from '.code16' in that 'call', 'ret', 'enter', 'leave', 'push', 'pop', 'pusha', 'popa', 'pushf', and 'popf' instructions default to 32-bit size. This is so that the stack pointer is manipulated in the same way over function calls, allowing access to function parameters at the same stack offsets as in 32-bit mode. '.code16gcc' also automatically adds address size prefixes where necessary to use the 32-bit addressing modes that gcc generates. --- It encodes 32-bit assembly instructions generated by GCC in 16-bit format so that GCC can be used to generate 16-bit instructions. To do that, the .code16gcc directive may be placed at the very beginning of the assembly code. This patch adds -m16 to x86 backend by: 1. Add -m16 and make it mutually exclusive with -m32, -m64 and -mx32. 2. Treat -m16 like -m32 so that --32 is passed to assembler. 3. Output .code16gcc at the very beginning of the assembly code. 4. Turn off 64-bit ISA when -m16 is used. Tested on Linux/x86 and Linux/x86-64. OK for trunk? Thanks. H.J. --- PR target/59672 * config/i386/gnu-user64.h (SPEC_32): Add m16| to m32. (SPEC_X32): Likewise. (SPEC_64): Likewise. * config/i386/i386.c (ix86_option_override_internal): Turn off OPTION_MASK_ISA_64BIT, OPTION_MASK_ABI_X32 and OPTION_MASK_ABI_64 for TARGET_16BIT. (x86_file_start): Output .code16gcc for TARGET_16BIT. * config/i386/i386.h (TARGET_16BIT): New macro. (TARGET_16BIT_P): Likewise. * config/i386/i386.opt: Add m16. * doc/invoke.texi: Document -m16. --- gcc/ChangeLog.m16| 16 gcc/config/i386/gnu-user64.h | 6 +++--- gcc/config/i386/i386.c | 6 ++ gcc/config/i386/i386.h | 2 ++ gcc/config/i386/i386.opt | 6 +- gcc/doc/invoke.texi | 10 -- 6 files changed, 40 insertions(+), 6 deletions(-) create mode 100644 gcc/ChangeLog.m16 diff --git a/gcc/ChangeLog.m16 b/gcc/ChangeLog.m16 new file mode 100644 index 000..05424d9 --- /dev/null +++ b/gcc/ChangeLog.m16 @@ -0,0 +1,16 @@ +gcc/ + +2014-01-23 H.J. Lu hongjiu...@intel.com + + PR target/59672 + * config/i386/gnu-user64.h (SPEC_32): Add m16| to m32. + (SPEC_X32): Likewise. + (SPEC_64): Likewise. + * config/i386/i386.c (ix86_option_override_internal): Turn off + OPTION_MASK_ISA_64BIT, OPTION_MASK_ABI_X32 and OPTION_MASK_ABI_64 + for TARGET_16BIT. + (x86_file_start): Output .code16gcc for TARGET_16BIT. + * config/i386/i386.h (TARGET_16BIT): New macro. + (TARGET_16BIT_P): Likewise. + * config/i386/i386.opt: Add m16. + * doc/invoke.texi: Document -m16. diff --git a/gcc/config/i386/gnu-user64.h b/gcc/config/i386/gnu-user64.h index 8d33483..1c72b41 100644 --- a/gcc/config/i386/gnu-user64.h +++ b/gcc/config/i386/gnu-user64.h @@ -32,12 +32,12 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see done. */ #if TARGET_64BIT_DEFAULT -#define SPEC_32 m32 +#define SPEC_32 m16|m32 #if TARGET_BI_ARCH == 2 #define SPEC_64 m64 -#define SPEC_X32 m32|m64:; +#define SPEC_X32 m16|m32|m64:; #else -#define SPEC_64 m32|mx32:; +#define SPEC_64 m16|m32|mx32:; #define SPEC_X32 mx32 #endif #else diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c index cf79486..c132cd9 100644 --- a/gcc/config/i386/i386.c +++ b/gcc/config/i386/i386.c @@ -3342,6 +3342,10 @@ ix86_option_override_internal (bool main_args_p, opts-x_ix86_isa_flags |= OPTION_MASK_ISA_64BIT; opts-x_ix86_isa_flags = ~OPTION_MASK_ABI_64; } + else if (TARGET_16BIT_P (opts-x_ix86_isa_flags)) +opts-x_ix86_isa_flags = ~(OPTION_MASK_ISA_64BIT + | OPTION_MASK_ABI_X32 + | OPTION_MASK_ABI_64); else if (TARGET_LP64_P (opts-x_ix86_isa_flags)) { /* Always turn on OPTION_MASK_ISA_64BIT and turn off @@ -38815,6 +38819,8 @@ static void x86_file_start (void) { default_file_start (); + if (TARGET_16BIT) +fputs (\t.code16gcc\n, asm_out_file); #if TARGET_MACHO darwin_file_start (); #endif diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h index 580a319..bfb6dc6 100644 --- a/gcc/config/i386/i386.h +++ b/gcc/config/i386/i386.h @@ -135,6 +135,8 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see #define TARGET_LP64_P(x) TARGET_ABI_64_P(x) #define TARGET_X32 TARGET_ABI_X32 #define TARGET_X32_P(x)TARGET_ABI_X32_P(x) +#define TARGET_16BIT TARGET_CODE16 +#define TARGET_16BIT_P(x) TARGET_CODE16_P(x) /* SSE4.1 defines round instructions */ #defineOPTION_MASK_ISA_ROUND OPTION_MASK_ISA_SSE4_1 diff --git a/gcc/config/i386/i386.opt b/gcc/config/i386/i386.opt index 26cd8bb..485ed2a 100644 ---
[patch] proposed fix for libstdc++/59829
This is the best I've come up with to avoid undefined behaviour when calling vector::data() on an empty vector. In C++03 mode we return vector::pointer, so can just return the internal pointer. In C++11 mode we need to dereference it, but only when it's valid. Any suggestions for improvements before I commit it? (Tests pass, but some dg-error line numbers need adjusting) 2014-01-27 Jonathan Wakely jwak...@redhat.com PR libstdc++/59829 * include/bits/stl_vector.h (vector::data()): Do not dereference pointers when empty. commit 60f9bb3b06ea95054d3fb442c9c212e7afe66acc Author: Jonathan Wakely jwak...@redhat.com Date: Mon Jan 27 18:35:17 2014 + PR libstdc++/59829 * include/bits/stl_vector.h (vector::data()): Do not dereference pointers when empty. * testsuite/23_containers/vector/59829.cc: New. diff --git a/libstdc++-v3/include/bits/stl_vector.h b/libstdc++-v3/include/bits/stl_vector.h index f482957..8393242 100644 --- a/libstdc++-v3/include/bits/stl_vector.h +++ b/libstdc++-v3/include/bits/stl_vector.h @@ -880,19 +880,21 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER */ #if __cplusplus = 201103L _Tp* -#else - pointer -#endif data() _GLIBCXX_NOEXCEPT - { return std::__addressof(front()); } + { return empty() ? nullptr : std::__addressof(*this-_M_impl._M_start); } -#if __cplusplus = 201103L const _Tp* + data() const _GLIBCXX_NOEXCEPT + { return empty() ? nullptr : std::__addressof(*this-_M_impl._M_start); } #else + pointer + data() _GLIBCXX_NOEXCEPT + { return this-_M_impl._M_start; } + const_pointer -#endif data() const _GLIBCXX_NOEXCEPT - { return std::__addressof(front()); } + { return this-_M_impl._M_start; } +#endif // [23.2.4.3] modifiers /** diff --git a/libstdc++-v3/testsuite/23_containers/vector/59829.cc b/libstdc++-v3/testsuite/23_containers/vector/59829.cc new file mode 100644 index 000..8d9f39d --- /dev/null +++ b/libstdc++-v3/testsuite/23_containers/vector/59829.cc @@ -0,0 +1,108 @@ +// Copyright (C) 2014 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 even 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/. + +// { dg-options -std=gnu++11 } + +// libstdc++/59829 + +#include vector + +// User-defined pointer type that throws if a null pointer is dereferenced. +templatetypename T +struct Pointer +{ + typedef T element_type; + + // typedefs for iterator_traits + typedef T value_type; + typedef std::ptrdiff_t difference_type; + typedef std::random_access_iterator_tag iterator_category; + typedef Pointer pointer; + typedef T reference; + + T* value; + + explicit Pointer(T* p = nullptr) : value(p) { } + + templatetypename U, typename Requires = decltype((T*)std::declvalU*()) +Pointer(const PointerU p) : value(p.value) { } + + T operator*() const + { +if (!value) + throw nullptr; +return *value; + } + + T* operator-() const { return value; } + + Pointer operator++() { ++value; return *this; } + Pointer operator++(int) { Pointer tmp(*this); ++value; return tmp; } + Pointer operator--() { --value; return *this; } + Pointer operator--(int) { Pointer tmp(*this); --value; return tmp; } + + Pointer operator+=(difference_type n) { value += n; return *this; } + Pointer operator-=(difference_type n) { value -= n; return *this; } + + explicit operator bool() const { return value != nullptr; } + + Pointer operator+(difference_type n) { Pointer p(*this); return p += n; } + Pointer operator-(difference_type n) { Pointer p(*this); return p -= n; } +}; + +templatetypename T +std::ptrdiff_t operator-(PointerT l, PointerT r) +{ return l.value - r.value; } + +templatetypename T +bool operator==(PointerT l, PointerT r) +{ return l.value == r.value; } + +templatetypename T +bool operator!=(PointerT l, PointerT r) +{ return l.value != r.value; } + +templatetypename T +struct Alloc +{ + typedef T value_type; + typedef PointerT pointer; + + Alloc() = default; + templatetypename U +Alloc(const AllocU) { } + + pointer allocate(std::size_t n) + { return pointer(std::allocatorT().allocate(n)); } + + void deallocate(pointer p, std::size_t n) + { std::allocatorT().deallocate(p.value, n); } +}; + +templatetypename T +bool operator==(AllocT l, AllocT r) +{ return true; } +
Re: [patch] proposed fix for libstdc++/59829
Hi, On 27/gen/2014, at 20:38, Jonathan Wakely jwak...@redhat.com wrote: This is the best I've come up with to avoid dereferencing an invalid pointer when calling vector::data() on an empty vector. For C++03 we reurn the vector's pointer type, so can just return the internal pointer, but for C++11 we need to convert that to a raw pointer, which we do by dereferencing, so we must check if it's valid first. Any better suggestions before I commit this? I'm going to say something quite obvious - in principle the C++11 version could become identical at compile time to the simpler C++03 version depending on the types. Not sure if it's worth it, avoiding the conditional operator at run-time... Maybe libc++ does something similar, if I remember correctly Howard's distaste for branches ;) Paolo
Re: [patch] proposed fix for libstdc++/59829
On 27 January 2014 20:12, Marc Glisse wrote: On Mon, 27 Jan 2014, Jonathan Wakely wrote: This is the best I've come up with to avoid dereferencing an invalid pointer when calling vector::data() on an empty vector. For C++03 we reurn the vector's pointer type, so can just return the internal pointer, but for C++11 we need to convert that to a raw pointer, which we do by dereferencing, so we must check if it's valid first. For comparison, libc++ has 2 paths. If pointer really is a pointer, it just returns it, no need to pay for a comparison in that case. And otherwise, it calls _M_start.operator- and crosses its fingers. There is a helper function doing that used throughout the library. Ah yes, I remember Howard posting a get_raw_pointer() function to the reflector that used operator-() on user-defined types ... I don't really like calling that on a potentially invalid pointer though. The user-defined pointer type in my new testcase could just as easily throw if operator- is called on an invalid pointer. As Paolo also mentioned avoiding the branch for built-in pointers I'll do that. (Sorry for the double-post, the first one seemed to disappear and I wasn't sure if it really happened or not, so wrote it again!)
[PING] [PATCH] _Cilk_for for C and C++
Hi Jakub et al., Did you get a chance to look at this _Cilk_for patch? Thanks, Balaji V. Iyer. -Original Message- From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches- ow...@gcc.gnu.org] On Behalf Of Iyer, Balaji V Sent: Friday, January 24, 2014 3:34 PM To: Jakub Jelinek Cc: Jason Merrill; 'Jeff Law'; 'Aldy Hernandez'; 'gcc-patches@gcc.gnu.org'; 'r...@redhat.com' Subject: RE: [PATCH] _Cilk_for for C and C++ -Original Message- From: Jakub Jelinek [mailto:ja...@redhat.com] Sent: Friday, January 24, 2014 2:42 PM To: Iyer, Balaji V Cc: Jason Merrill; 'Jeff Law'; 'Aldy Hernandez'; 'gcc-patches@gcc.gnu.org'; 'r...@redhat.com' Subject: Re: [PATCH] _Cilk_for for C and C++ On Thu, Jan 23, 2014 at 04:38:53PM +, Iyer, Balaji V wrote: This is how I started to think of it at first, but then when I thought about it ... in _Cilk_for unlike the #pragma simd's for, the for statement - not the body - (e.g. _Cilk_for (int ii = 0; ii 10; ii++) doesn't really do anything nor does it belong in the child function. It is really mostly used to calculate the loop count and capture step-size and starting point. The child function has its own loop that will have a step size of 1 regardless of your step size. You use the step-size to find the correct spot. Let me give you an example: _Cilk_for (int ii = 0; ii 10; ii = ii + 2) { Array [ii] = 5; } This is translated to the following (assume grain is something that the user input): data_ptr.start = 0; data_ptr.end = 10; data_ptr.step_size = 2; __cilkrts_cilk_for_32 (child_function, data_ptr, (10-0)/2, grain); Child_function (void *data_ptr, int high, int low) { for (xx = low; xx high; xx++) { Tmp_var = (xx * data_ptr-step_size) + data_ptr-start; // Note: if the _Cilk_for was (ii = 9; ii = 0; ii -= 2), we would have something like this: // Tmp_var = data_ptr-end - (xx * data_ptr-step_size) // The for-loop above won't change. Array[Tmp_var] = 5; } } This isn't really much different from #pragma omp parallel for schedule(runtime, N) (i.e. the combined construct), when it is combined, we also don't emit a call to GOMP_parallel but to some other function to which we pass the number of iterations and chunk size (== grain in Cilk+ terminology), the only (minor) difference is that for OpenMP when you handle the whole low ... high range the child function doesn't exit, but calls a function to give it next pari of low/high and only when that function tells it there is no further work to do, it returns. But, the Cilk+ case is clearly the same thing with just implicit telling there is no further work in the current function. So, I'd strongly prefer if you swap the parallel with Cilk_for, just set the flag that the two are combined like OpenMP already has for tons of constructs, and during expansion you just treat it together. Hi Jakub, What you are suggesting here would require a significant rewrite of the code. This version of _Cilk_for works and it does share significant amount of work with OMP routines as requested by other GCC developers. Given the time constraints, let's try to get this version accepted so that the feature will be available for the users and we will look into moving toward your suggestion when the phase 1 opens again. Thanks, Balaji V. Iyer. Jakub
Re: [PING] [PATCH] _Cilk_for for C and C++
On Mon, Jan 27, 2014 at 08:41:14PM +, Iyer, Balaji V wrote: Did you get a chance to look at this _Cilk_for patch? IMHO it is not as much work as you are fearing, at most a few hours of work to get it right, and well worth doing. So, please at least try it out and if you get stuck with it, explain why. Jakub
[PATCH] Fix comment typo
Just something I noticed while looking at one of our P1 regressions. Installed as obvious. Jeff diff --git a/gcc/ipa-inline.c b/gcc/ipa-inline.c index 12ee84c..5f47e0b 100644 --- a/gcc/ipa-inline.c +++ b/gcc/ipa-inline.c @@ -1597,7 +1597,7 @@ inline_small_functions (void) max_size = compute_max_insns (overall_size); min_size = overall_size; - /* Populate the heeap with all edges we might inline. */ + /* Populate the heap with all edges we might inline. */ FOR_EACH_DEFINED_FUNCTION (node) {
Re: [RFA][PR 16361] Add warnings for NULL pointer dereferences and such
On Mon, Jan 27, 2014 at 11:09 AM, Jeff Law l...@redhat.com wrote: First, as is often the case, this warning is not going to catch everything. Dead code elimination, unreachable code elimination, etc can/will remove NULL pointer dereferences and if that happens we don't get a warning. It also will not catch cases where a NULL value flows out of a PHI into uses in other blocks where it is then dereferenced or otherwise used erroneously. -Wnull-dereference will warn for NULL pointer dereferences. Both those which appear explicitly in the IL and those which occur if NULL value flows from a PHI to a dereference in the same block as the PHI. -Wnull-attribute will warn if NULL is used as an argument to a function call where the callee's attributes have declared the argument must be non-NULL. Similarly for NULL as a return value when the current function has an attribute declaring the function can never return NULL. Similarly for NULL values flowing from a PHI into an argument/return in the same block as the PHI. We utilize the analysis done for the erroneous-paths optimization. The optimizations and warnings can be enabled/disabled independently. The warnings are not enabled by -Wall. I want to raise the usual caution about warnings that are based on optimizations. This leads to different results in different GCC releases, which makes it hard for other packages to use -Werror. However, I admit that this is less of a concern when the warning is not part of -Wall. Ian
[jit] Fix accidental removal of GCC_JIT_BOOL_OPTION_DUMP_GENERATED_CODE
Committed to dmalcolm/jit: gcc/jit/ * internal-api.c (gcc::jit::playback::context::compile): Removal of the code-creation callback (96b218c9a1d5f39fb649e02c0e77586b180e8516) accidentally removed the implementation of GCC_JIT_BOOL_OPTION_DUMP_GENERATED_CODE; reinstate it. --- gcc/jit/ChangeLog.jit | 7 +++ gcc/jit/internal-api.c | 3 +++ 2 files changed, 10 insertions(+) diff --git a/gcc/jit/ChangeLog.jit b/gcc/jit/ChangeLog.jit index 3e8d2d3..5e5f89f 100644 --- a/gcc/jit/ChangeLog.jit +++ b/gcc/jit/ChangeLog.jit @@ -1,5 +1,12 @@ 2014-01-27 David Malcolm dmalc...@redhat.com + * internal-api.c (gcc::jit::playback::context::compile): Removal + of the code-creation callback (96b218c9a1d5f39fb649e02c0e77586b180e8516) + accidentally removed the implementation of + GCC_JIT_BOOL_OPTION_DUMP_GENERATED_CODE; reinstate it. + +2014-01-27 David Malcolm dmalc...@redhat.com + * libgccjit.h (enum gcc_jit_binary_op): Remove GCC_JIT_BINARY_OP_FLOATING_DIVIDE, which I accidentally added as part of a880c0d9c642730550f39d328f29a1d9935cb07e. diff --git a/gcc/jit/internal-api.c b/gcc/jit/internal-api.c index cf9195d0..09b4415 100644 --- a/gcc/jit/internal-api.c +++ b/gcc/jit/internal-api.c @@ -2216,6 +2216,9 @@ compile () return NULL; } + if (get_bool_option (GCC_JIT_BOOL_OPTION_DUMP_GENERATED_CODE)) + dump_generated_code (); + timevar_push (TV_ASSEMBLE); /* Gross hacks follow: -- 1.7.11.7
Re: [Patch, fortran] PR58007: unresolved fixup hell
Le 27/01/2014 09:49, Janus Weil a écrit : Did you bootstrap test the 4.7 backport? Yes, works like a charm here. I also see the build problem (configuring with --enable-languages=c,fortran --disable-bootstrap). I have committed the following as http://gcc.gnu.org/r207152 I made sure it worked even without bootstrap. Mikael Index: ChangeLog === --- ChangeLog (révision 207151) +++ ChangeLog (révision 207152) @@ -1,3 +1,9 @@ +2014-01-27 Mikael Morin mik...@gcc.gnu.org + + PR fortran/58007 + * module.c (skip_list): Don't use default argument value. + (load_derived_extensions, read_module): Update callers. + 2014-01-26 Mikael Morin mik...@gcc.gnu.org PR fortran/58007 Index: module.c === --- module.c (révision 207151) +++ module.c (révision 207152) @@ -3860,12 +3860,12 @@ /* Skip a list between balanced left and right parens. - By setting NEST_LEVEL one assumes that a number of NEST_LEVEL opening parens - have been already parsed by hand, and the remaining of the content is to be - skipped here. The default value is 0 (balanced parens). */ + By setting NEST_LEVEL to a non-zero value one assumes that a number of + NEST_LEVEL opening parens have been already parsed by hand, and the remaining + of the content is to be skipped here. */ static void -skip_list (int nest_level = 0) +skip_list (int nest_level) { int level; @@ -4228,7 +4228,7 @@ if (!info || !derived) { while (peek_atom () != ATOM_RPAREN) - skip_list (); + skip_list (0); continue; } @@ -4465,18 +4465,18 @@ gfc_symbol *sym; get_module_locus (operator_interfaces); /* Skip these for now. */ - skip_list (); + skip_list (0); get_module_locus (user_operators); - skip_list (); - skip_list (); + skip_list (0); + skip_list (0); /* Skip commons, equivalences and derived type extensions for now. */ - skip_list (); - skip_list (); + skip_list (0); + skip_list (0); get_module_locus (extensions); - skip_list (); + skip_list (0); mio_lparen (); @@ -4514,7 +4514,7 @@ if (sym == NULL || (sym-attr.flavor == FL_VARIABLE info-u.rsym.ns !=1)) { - skip_list (); + skip_list (0); continue; } @@ -4531,13 +4531,13 @@ /* First seek to the symbol's component list. */ mio_lparen (); /* symbol opening. */ - skip_list (); /* skip symbol attribute. */ - skip_list (); /* typespec. */ + skip_list (0); /* skip symbol attribute. */ + skip_list (0); /* typespec. */ require_atom (ATOM_INTEGER); /* namespace ref. */ require_atom (ATOM_INTEGER); /* common ref. */ - skip_list (); /* formal args. */ + skip_list (0); /* formal args. */ /* no value. */ - skip_list (); /* array_spec. */ + skip_list (0); /* array_spec. */ require_atom (ATOM_INTEGER); /* result. */ /* not a cray pointer. */ @@ -4562,7 +4562,7 @@ skip_list (1); /* symbol end. */ } else - skip_list (); + skip_list (0); /* Some symbols do not have a namespace (eg. formal arguments), so the automatic unique symtree mechanism must be suppressed @@ -4725,7 +4725,7 @@ if (u == NULL) { - skip_list (); + skip_list (0); continue; }
RE: [PING] [PATCH] _Cilk_for for C and C++
-Original Message- From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches- ow...@gcc.gnu.org] On Behalf Of Jakub Jelinek Sent: Monday, January 27, 2014 3:50 PM To: Iyer, Balaji V Cc: Jason Merrill; 'Jeff Law'; 'Aldy Hernandez'; 'gcc-patches@gcc.gnu.org'; 'r...@redhat.com' Subject: Re: [PING] [PATCH] _Cilk_for for C and C++ On Mon, Jan 27, 2014 at 08:41:14PM +, Iyer, Balaji V wrote: Did you get a chance to look at this _Cilk_for patch? IMHO it is not as much work as you are fearing, at most a few hours of work to get it right, and well worth doing. So, please at least try it out and if you get stuck with it, explain why. Hi Jakub, I tried it that way in the original patch submission for C (http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01369.html), but it hit a dead-end when I was trying to get STL iterators working for C++. This is why I re-structured things this way to get them both working. Thanks, Balaji V. Iyer. Jakub
[C++ patch] for c++/37140
Hi, We fail here to create a typename_type on dependent using declarations. In fact, facing a USING_DECLs on spotted places, either we want to strip non-dependent USING_DECLs or we want to create a typename_type. The attached patch simply propagates the change made to fix c++/14258 through strip_using_decl. Bootstrapped Tested x86_64, OK for trunk and 4.8 / 4.7 ? (even if it is not technically a regression, it is very close to c++/14258 which is anounced fixed in 4.7) 2014-01-25 Fabien Chene fab...@gcc.gnu.org PR c++/37140 * parser.c (cp_parser_nonclass_name): Call strip_using_decl and move the code handling dependent USING_DECLs... * name-lookup.c (strip_using_decl): ...Here. 2014-01-25 Fabien Chene fab...@gcc.gnu.org PR c++/37140 * g++.dg/template/using27.C: New. * g++.dg/template/using28.C: New. * g++.dg/template/using29.C: New. -- Fabien Index: gcc/testsuite/g++.dg/template/using28.C === --- gcc/testsuite/g++.dg/template/using28.C (revision 0) +++ gcc/testsuite/g++.dg/template/using28.C (revision 0) @@ -0,0 +1,17 @@ +// PR c++/37140 + +struct C +{ + static const int block_size = 1; +}; + +template typename T struct A { + typedef C type; +}; + +template typename T struct B : public AT { + using typename AT::type; + static const int block_size = type::block_size; +}; + +template class Bint; Index: gcc/testsuite/g++.dg/template/using27.C === --- gcc/testsuite/g++.dg/template/using27.C (revision 0) +++ gcc/testsuite/g++.dg/template/using27.C (revision 0) @@ -0,0 +1,30 @@ +// PR c++/37140 + +struct X +{ + typedef int nested_type; +}; + +template class T +struct A +{ + typedef X type; +}; + +template class T +struct B : AT +{ + using typename AT::type; + typename type::nested_type x; +}; + +template class T +struct C : BT +{ + using typename BT::type; + typename type::nested_type y; +}; + +template class Aint; +template class Bint; +template class Cint; Index: gcc/testsuite/g++.dg/template/using29.C === --- gcc/testsuite/g++.dg/template/using29.C (revision 0) +++ gcc/testsuite/g++.dg/template/using29.C (revision 0) @@ -0,0 +1,21 @@ +// PR c++/58047 + +template int N +struct print_arg { }; + +struct const_holder { + static const int CONSTANT = 42; +}; + +template typename T +struct identity { + typedef T type; +}; + +template class T +struct test_case : public identityT { + using typename identityT::type; + print_argtype::CONSTANT printer; +}; + +template struct test_caseconst_holder; Index: gcc/cp/name-lookup.c === --- gcc/cp/name-lookup.c (revision 207035) +++ gcc/cp/name-lookup.c (working copy) @@ -406,7 +406,8 @@ pop_bindings_and_leave_scope (void) leave_scope (); } -/* Strip non dependent using declarations. */ +/* Strip non dependent using declarations. If DECL is dependent, + surreptitiously create a typename_type and return it. */ tree strip_using_decl (tree decl) @@ -414,8 +415,29 @@ strip_using_decl (tree decl) if (decl == NULL_TREE) return NULL_TREE; + if (TREE_CODE (decl) != USING_DECL) +return decl; + + if (DECL_DEPENDENT_P (decl) USING_DECL_TYPENAME_P (decl)) +{ + /* We have found a type introduced by a using + declaration at class scope that refers to a dependent + type. + + using typename :: [opt] nested-name-specifier unqualified-id ; + */ + decl = make_typename_type (TREE_TYPE (decl), + DECL_NAME (decl), + typename_type, tf_error); + if (decl != error_mark_node) + decl = TYPE_NAME (decl); + + return decl; +} + while (TREE_CODE (decl) == USING_DECL !DECL_DEPENDENT_P (decl)) decl = USING_DECL_DECLS (decl); + return decl; } Index: gcc/cp/parser.c === --- gcc/cp/parser.c (revision 207035) +++ gcc/cp/parser.c (working copy) @@ -14824,25 +14824,7 @@ cp_parser_nonclass_name (cp_parser* pars /* Look up the type-name. */ type_decl = cp_parser_lookup_name_simple (parser, identifier, token-location); - if (TREE_CODE (type_decl) == USING_DECL) -{ - if (!DECL_DEPENDENT_P (type_decl)) - type_decl = strip_using_decl (type_decl); - else if (USING_DECL_TYPENAME_P (type_decl)) - { - /* We have found a type introduced by a using - declaration at class scope that refers to a dependent - type. - - using typename :: [opt] nested-name-specifier unqualified-id ; - */ - type_decl = make_typename_type (TREE_TYPE (type_decl), - DECL_NAME (type_decl), - typename_type, tf_error); - if (type_decl != error_mark_node) - type_decl = TYPE_NAME (type_decl); - } -} + type_decl = strip_using_decl (type_decl); if (TREE_CODE (type_decl) != TYPE_DECL
Re: [RFA][PR 16361] Add warnings for NULL pointer dereferences and such
On 01/27/14 14:02, Ian Lance Taylor wrote: We utilize the analysis done for the erroneous-paths optimization. The optimizations and warnings can be enabled/disabled independently. The warnings are not enabled by -Wall. I want to raise the usual caution about warnings that are based on optimizations. This leads to different results in different GCC releases, which makes it hard for other packages to use -Werror. Absolutely. It's an issue for any warnings that run after any of the optimization passes (as this one does). There's nothing inherently difficult about running this code earlier, say just after entering SSA form. You'll get a lot more false positives, but more stability from release to release. There's still some things that would come and go due to the limited nature of following values out of PHI nodes in this code. I've got the original analyzer here which was designed prior to the optimization work. It actually uses the propagation engine and would provide much more warning stability from release to release if it were run just after going into SSA form. It's something I hope to get back to during the next stage1 cycle. However, I admit that this is less of a concern when the warning is not part of -Wall. Right. I hadn't actually planned on even doing warnings at this stage, but it became pretty clear that something has needed based on the reactions to the erroneous-path optimizations. jeff
Re: profile mode fix
Indeed, default constructor and copy constructor shall not be noexcept qualified. IMO we should be able to make move constructor noexcept by using a special allocator for the underlying unordered_map that would allow to replace an entry with an other one without requiring a deallocate/allocate. It would be the same kind of allocator keeping a released instance in cache that you already talk about to enhance std::deque behavior especially when used in a std::queue. For 4.9 we could consider that this test is not supported in profile mode and I will work on it for next version. François On 01/26/2014 11:38 AM, Jonathan Wakely wrote: On 26 January 2014 09:43, François Dumont wrote: Hi This is a patch to fix PR 55033 in profile mode. Like in debug mode it was missing noexcept qualifier on move constructor. But don't those functions allocate memory? So they can throw. I agree we want the move constructor to be noexcept anyway, and maybe the default constructor, but why would we want to lie about the copy constructor? I have this patch in my tree that I'm trying to decide whether it should be committed, but if we make the change we should have a comment like this: --- a/libstdc++-v3/include/profile/unordered_base.h +++ b/libstdc++-v3/include/profile/unordered_base.h @@ -160,9 +160,14 @@ namespace __profile __profcxx_hashtable_construct(__uc, __uc.bucket_count()); __profcxx_hashtable_construct2(__uc); } + _Unordered_profile(const _Unordered_profile) : _Unordered_profile() { } - _Unordered_profile(_Unordered_profile) + + // This might actually throw, but for consistency with normal mode + // unordered containers we want the noexcept specification, and will + // std::terminate() if an exception is thrown. + _Unordered_profile(_Unordered_profile) noexcept : _Unordered_profile() { } ~_Unordered_profile() noexcept
Re: Disable accumulate-outgoing-args for Generic and Buldozers
On Fri, Jan 24, 2014 at 10:11:20PM +0100, Jakub Jelinek wrote: On Wed, Jan 01, 2014 at 03:30:04PM +0100, Jan Hubicka wrote: * config/i38/x86-tune.def: Disable X86_TUNE_ACCUMULATE_OUTGOING_ARGS for generic and recent AMD chips Index: config/i386/x86-tune.def === --- config/i386/x86-tune.def(revision 206233) +++ config/i386/x86-tune.def(working copy) @@ -143,7 +143,7 @@ DEF_TUNE (X86_TUNE_REASSOC_FP_TO_PARALLE regression on mgrid due to IRA limitation leading to unecessary use of the frame pointer in 32bit mode. */ DEF_TUNE (X86_TUNE_ACCUMULATE_OUTGOING_ARGS, accumulate_outgoing_args, - m_PPRO | m_P4_NOCONA | m_BONNELL | m_SILVERMONT | m_AMD_MULTIPLE | m_GENERIC) + m_PPRO | m_P4_NOCONA | m_BONNELL | m_SILVERMONT | m_ATHLON_K8) /* X86_TUNE_PROLOGUE_USING_MOVE: Do not use push/pop in prologues that are considered on critical path. */ Are you sure this is a good idea even for 32-bit code (i.e. shouldn't we have separate tunables for 32-bit and 64-bit code)? I admit I haven't performed trunk bootstraps/regtests for 3 days, am doing x86_64 and i686 bootstraps/regtests concurrently and it is yes,rtl checking, but am quite surprised that compared to 3 days ago the bootstrap time of i686-linux (all,obj-c++,go) went up from about 70 minutes or so to 140 minutes today, while the x86_64-linux (all,obj-c++,go,ada) remained basically the same around 2 hours. This is on quad socket Quad-Core AMD Opteron(tm) Processor 8354, perhaps it is just extremely undesirable there. Most likely the big slowdown is var-tracking, at least stage2 insn-recog.o (yes,rtl checking on i686-linux) took = 23 minutes to compile and stage3 = 62 minutes, with 45 minutes from that only spent on compiling insn-recog.o and nothing else. Jakub
Re: Disable accumulate-outgoing-args for Generic and Buldozers
On Mon, Jan 27, 2014 at 11:19:39PM +0100, Jakub Jelinek wrote: Are you sure this is a good idea even for 32-bit code (i.e. shouldn't we have separate tunables for 32-bit and 64-bit code)? I admit I haven't performed trunk bootstraps/regtests for 3 days, am doing x86_64 and i686 bootstraps/regtests concurrently and it is yes,rtl checking, but am quite surprised that compared to 3 days ago the bootstrap time of i686-linux (all,obj-c++,go) went up from about 70 minutes or so to 140 minutes today, while the x86_64-linux (all,obj-c++,go,ada) remained basically the same around 2 hours. This is on quad socket Quad-Core AMD Opteron(tm) Processor 8354, perhaps it is just extremely undesirable there. Most likely the big slowdown is var-tracking, at least stage2 insn-recog.o (yes,rtl checking on i686-linux) took = 23 minutes to compile and stage3 = 62 minutes, with 45 minutes from that only spent on compiling insn-recog.o and nothing else. Note, looking at the previous bootstraps before your change, insn-recog.o was taking = 15-16 minutes to compile both in stage2 and stage3 (the = stands for comparison of oldest *.o file in {,prev-}gcc/ directory and insn-recog.o, but for the latest bootstrap stage3 I remember seeing in top 58 minutes and it was still compiling, haven't looked exactly when it stopped). In any case, most likely it doesn't mean actual slow down in performance of generated code, but medium slowdown in non-g compile time of extreme testcase and -g compile time going wild. Jakub
Re: Disable accumulate-outgoing-args for Generic and Buldozers
On Mon, Jan 27, 2014 at 2:19 PM, Jakub Jelinek ja...@redhat.com wrote: On Fri, Jan 24, 2014 at 10:11:20PM +0100, Jakub Jelinek wrote: On Wed, Jan 01, 2014 at 03:30:04PM +0100, Jan Hubicka wrote: * config/i38/x86-tune.def: Disable X86_TUNE_ACCUMULATE_OUTGOING_ARGS for generic and recent AMD chips Index: config/i386/x86-tune.def === --- config/i386/x86-tune.def(revision 206233) +++ config/i386/x86-tune.def(working copy) @@ -143,7 +143,7 @@ DEF_TUNE (X86_TUNE_REASSOC_FP_TO_PARALLE regression on mgrid due to IRA limitation leading to unecessary use of the frame pointer in 32bit mode. */ DEF_TUNE (X86_TUNE_ACCUMULATE_OUTGOING_ARGS, accumulate_outgoing_args, - m_PPRO | m_P4_NOCONA | m_BONNELL | m_SILVERMONT | m_AMD_MULTIPLE | m_GENERIC) + m_PPRO | m_P4_NOCONA | m_BONNELL | m_SILVERMONT | m_ATHLON_K8) /* X86_TUNE_PROLOGUE_USING_MOVE: Do not use push/pop in prologues that are considered on critical path. */ Are you sure this is a good idea even for 32-bit code (i.e. shouldn't we have separate tunables for 32-bit and 64-bit code)? I admit I haven't performed trunk bootstraps/regtests for 3 days, am doing x86_64 and i686 bootstraps/regtests concurrently and it is yes,rtl checking, but am quite surprised that compared to 3 days ago the bootstrap time of i686-linux (all,obj-c++,go) went up from about 70 minutes or so to 140 minutes today, while the x86_64-linux (all,obj-c++,go,ada) remained basically the same around 2 hours. This is on quad socket Quad-Core AMD Opteron(tm) Processor 8354, perhaps it is just extremely undesirable there. Most likely the big slowdown is var-tracking, at least stage2 insn-recog.o (yes,rtl checking on i686-linux) took = 23 minutes to compile and stage3 = 62 minutes, with 45 minutes from that only spent on compiling insn-recog.o and nothing else. There are also couple of debugging regressions: FAIL: gcc.dg/guality/pr54519-1.c -O2 line 20 y == 25 FAIL: gcc.dg/guality/pr54519-1.c -O2 line 20 z == 6 FAIL: gcc.dg/guality/pr54519-1.c -O2 line 23 y == 117 FAIL: gcc.dg/guality/pr54519-1.c -O2 line 23 z == 8 FAIL: gcc.dg/guality/pr54519-1.c -O3 -fomit-frame-pointer line 20 x == 36 FAIL: gcc.dg/guality/pr54519-1.c -O3 -fomit-frame-pointer line 20 y == 25 FAIL: gcc.dg/guality/pr54519-1.c -O3 -fomit-frame-pointer line 20 z == 6 FAIL: gcc.dg/guality/pr54519-1.c -O3 -g line 20 x == 36 FAIL: gcc.dg/guality/pr54519-1.c -O3 -g line 20 y == 25 FAIL: gcc.dg/guality/pr54519-1.c -O3 -g line 20 z == 6 FAIL: gcc.dg/guality/pr54519-3.c -O2 -flto -fno-use-linker-plugin -flto-partition=none line 20 x == 36 FAIL: gcc.dg/guality/pr54519-3.c -O2 -flto -fno-use-linker-plugin -flto-partition=none line 23 x == 98 FAIL: gcc.dg/guality/pr54519-3.c -O2 line 20 x == 36 FAIL: gcc.dg/guality/pr54519-3.c -O2 line 20 y == 25 FAIL: gcc.dg/guality/pr54519-3.c -O2 line 20 z == 6 FAIL: gcc.dg/guality/pr54519-3.c -O2 line 23 x == 98 FAIL: gcc.dg/guality/pr54519-3.c -O2 line 23 y == 117 FAIL: gcc.dg/guality/pr54519-3.c -O2 line 23 z == 8 FAIL: gcc.dg/guality/pr54519-3.c -O3 -fomit-frame-pointer line 20 x == 36 FAIL: gcc.dg/guality/pr54519-3.c -O3 -fomit-frame-pointer line 20 y == 25 FAIL: gcc.dg/guality/pr54519-3.c -O3 -fomit-frame-pointer line 20 z == 6 FAIL: gcc.dg/guality/pr54519-3.c -O3 -fomit-frame-pointer line 23 x == 98 FAIL: gcc.dg/guality/pr54519-3.c -O3 -fomit-frame-pointer line 23 y == 117 FAIL: gcc.dg/guality/pr54519-3.c -O3 -fomit-frame-pointer line 23 z == 8 FAIL: gcc.dg/guality/pr54519-3.c -O3 -g line 20 x == 36 FAIL: gcc.dg/guality/pr54519-3.c -O3 -g line 20 y == 25 FAIL: gcc.dg/guality/pr54519-3.c -O3 -g line 20 z == 6 FAIL: gcc.dg/guality/pr54519-3.c -O3 -g line 23 x == 98 FAIL: gcc.dg/guality/pr54519-3.c -O3 -g line 23 y == 117 FAIL: gcc.dg/guality/pr54519-3.c -O3 -g line 23 z == 8 FAIL: gcc.dg/guality/pr54693-2.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions line 21 i == v + 1 FAIL: gcc.dg/guality/pr54693-2.c -O3 -fomit-frame-pointer -funroll-loops lin -- H.J.
[Patch, MIPS, testsuite] Checking in obvious testsuite patch
I am checking in this testsuite patch as an obvious fix after checking with Richard Sandiford. Steve Ellcey sell...@mips.com 2014-01-27 Steve Ellcey sell...@mips.com * gcc.target/mips/pr52125.c: Add -mno-optgp option. diff --git a/gcc/testsuite/gcc.target/mips/pr52125.c b/gcc/testsuite/gcc.target/mips/pr52125.c index cfa8d68..2ac8067 100644 --- a/gcc/testsuite/gcc.target/mips/pr52125.c +++ b/gcc/testsuite/gcc.target/mips/pr52125.c @@ -1,4 +1,4 @@ -/* { dg-options addressing=absolute } */ +/* { dg-options -mno-gpopt addressing=absolute } */ int a, b, c, d;
Re: [Patch, i386] Separate Intel processor with expanded ISA
On Mon, Jan 27, 2014 at 10:15 AM, Uros Bizjak ubiz...@gmail.com wrote: +2013-12-29 Allan Sandfeld Jensen sandf...@kde.org Missing space in ChangeLog entry. + * config/i386/i386.c (get_builtin_code_for_version): Separate + Westmere from Nehalem, Ivy Bridge from Sandy Bridge and + Broadwell from Haswell. --- a/gcc/config/i386/i386.c +++ b/gcc/config/i386/i386.c @@ -31298,18 +31298,27 @@ get_builtin_code_for_version (tree decl, tree *predicate_list) priority = P_PROC_SSSE3; break; case PROCESSOR_NEHALEM: - /* We translate arch=corei7 and arch=nehelam to - corei7 so that it will be mapped to M_INTEL_COREI7 - as cpu type to cover all M_INTEL_COREI7_XXXs. */ - arg_str = corei7; + if (new_target-x_ix86_isa_flags OPTION_MASK_ISA_AES) + arg_str = westmere; + else + /* We translate arch=corei7 and arch=nehelam to Trivial typo above: arch=nehalem. OK for mainline with these changes. I have committed slightly reformated patches with following ChangeLog to mainline SVN. 2014-01-27 Allan Sandfeld Jensen sandf...@kde.org * config/i386/i386.c (get_builtin_code_for_version): Separate Westmere from Nehalem, Ivy Bridge from Sandy Bridge and Broadwell from Haswell. testsuite/ChangeLog: 2014-01-27 Allan Sandfeld Jensen sandf...@kde.org * g++.dg/ext/mv16.C: New tests. Uros.
Re: [patch] proposed fix for libstdc++/59829
On 27 January 2014 20:35, Jonathan Wakely wrote: On 27 January 2014 20:12, Marc Glisse wrote: On Mon, 27 Jan 2014, Jonathan Wakely wrote: This is the best I've come up with to avoid dereferencing an invalid pointer when calling vector::data() on an empty vector. For C++03 we reurn the vector's pointer type, so can just return the internal pointer, but for C++11 we need to convert that to a raw pointer, which we do by dereferencing, so we must check if it's valid first. For comparison, libc++ has 2 paths. If pointer really is a pointer, it just returns it, no need to pay for a comparison in that case. And otherwise, it calls _M_start.operator- and crosses its fingers. There is a helper function doing that used throughout the library. Ah yes, I remember Howard posting a get_raw_pointer() function to the reflector that used operator-() on user-defined types ... I don't really like calling that on a potentially invalid pointer though. The user-defined pointer type in my new testcase could just as easily throw if operator- is called on an invalid pointer. As Paolo also mentioned avoiding the branch for built-in pointers I'll do that. How about this? (the testcase remained the same as in the last patch) PR libstdc++/59829 * include/bits/stl_vector.h (vector::data()): Call _M_data_ptr. (vector::_M_data_ptr): New overloaded functions to ensure empty vectors do not dereference the pointer. * testsuite/23_containers/vector/59829.cc: New. diff --git a/libstdc++-v3/include/bits/stl_vector.h b/libstdc++-v3/include/bits/stl_vector.h index f482957..164a7d9 100644 --- a/libstdc++-v3/include/bits/stl_vector.h +++ b/libstdc++-v3/include/bits/stl_vector.h @@ -884,7 +884,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER pointer #endif data() _GLIBCXX_NOEXCEPT - { return std::__addressof(front()); } + { return _M_data_ptr(this-_M_impl._M_start); } #if __cplusplus = 201103L const _Tp* @@ -892,7 +892,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER const_pointer #endif data() const _GLIBCXX_NOEXCEPT - { return std::__addressof(front()); } + { return _M_data_ptr(this-_M_impl._M_start); } // [23.2.4.3] modifiers /** @@ -1468,6 +1468,23 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER } } #endif + +#if __cplusplus = 201103L + templatetypename _Up + _Up* + _M_data_ptr(_Up* __ptr) const + { return __ptr; } + + templatetypename _Ptr + typename std::pointer_traits_Ptr::element_type* + _M_data_ptr(_Ptr __ptr) const + { return empty() ? nullptr : std::__addressof(*__ptr); } +#else + templatetypename _Ptr + _Ptr + _M_data_ptr(_Ptr __ptr) const + { return __ptr; } +#endif };
Re: Disable accumulate-outgoing-args for Generic and Buldozers
On Mon, Jan 27, 2014 at 11:19:39PM +0100, Jakub Jelinek wrote: Are you sure this is a good idea even for 32-bit code (i.e. shouldn't we have separate tunables for 32-bit and 64-bit code)? I admit I haven't performed trunk bootstraps/regtests for 3 days, am doing x86_64 and i686 bootstraps/regtests concurrently and it is yes,rtl checking, but am quite surprised that compared to 3 days ago the bootstrap time of i686-linux (all,obj-c++,go) went up from about 70 minutes or so to 140 minutes today, while the x86_64-linux (all,obj-c++,go,ada) remained basically the same around 2 hours. This is on quad socket Quad-Core AMD Opteron(tm) Processor 8354, perhaps it is just extremely undesirable there. Most likely the big slowdown is var-tracking, at least stage2 insn-recog.o (yes,rtl checking on i686-linux) took = 23 minutes to compile and stage3 = 62 minutes, with 45 minutes from that only spent on compiling insn-recog.o and nothing else. Note, looking at the previous bootstraps before your change, insn-recog.o was taking = 15-16 minutes to compile both in stage2 and stage3 (the = stands for comparison of oldest *.o file in {,prev-}gcc/ directory and insn-recog.o, but for the latest bootstrap stage3 I remember seeing in top 58 minutes and it was still compiling, haven't looked exactly when it stopped). In any case, most likely it doesn't mean actual slow down in performance of generated code, but medium slowdown in non-g compile time of extreme testcase and -g compile time going wild. I wonder if this is just some of --enable-checking tests in dwarf2out going wild or if it is just expensive sanity checking code? I used to have chroot environment for 32bit builds, I will need to re-install it now. Honza Jakub
Re: [google gcc-4_8] Tree Loop Unrolling - Relax code size increase with -O2
Hi David, I had to fix a couple of tests. I have attached the patch with the fixed tests. The fixes are simple. The tests fail due to two reasons: 1) Tests like bmi2-pext32-1a.c fail because the vectorize loop is unrolled and directive { scan-assembler-times bmi2_pext_si3 1 } fails because bmi2_pext_si3 occurs more than once. This is fixed by changing the directive to scan-assembler 2) Tests like bmi2-bzhi64-1a.c fail because the unrolled loop no longer needs the bzhi instruction as this gets folded into a constant since the value is now known for each iteration. In order for this test to make sense, I disabled the unrolling in O2 by setting the code size growth to zero via option --param max-default-completely-peeled-insns=0. All the fixes fell into one of the above two patterns with one exception, pr53265.c. Loop unrolling exposed the array out of bounds access which is now caught. Ok to commit? Thanks Sri On Tue, Jan 21, 2014 at 4:51 PM, Xinliang David Li davi...@google.com wrote: ok. David On Tue, Jan 21, 2014 at 4:46 PM, Sriraman Tallam tmsri...@google.com wrote: On Tue, Jan 21, 2014 at 2:49 PM, Xinliang David Li davi...@google.com wrote: I think it might be better to introduce a new parameter for max peel insn at O2 (e.g, call it MAX_O2_COMPLETELY_PEEL_INSN or MAX_DEFAULT_...), and use the same logic in your patch to override the MAX_COMPLETELY_PEELED_INSN parameter at O2). By so doing, we don't need to have a hard coded factor of 2. Patch attached with that change. Sri In the longer run, we really need better cost/benefit analysis, but that is independent. David On Tue, Jan 21, 2014 at 1:49 PM, Sriraman Tallam tmsri...@google.com wrote: Hi, Currently, tree unrolling pass(cunroll) does not allow any code size growth in O2 mode. Code size growth is permitted only if O3 or funroll-loops/fpeel-loops is used. I have created a patch to allow partial code size increase in O2 mode. With funroll-loops the maximum allowed code growth is 400 unrolled insns. I have set it to 200 unrolled insns in O2 mode. This patch improves an image processing benchmark by 20%. It improves most benchmarks by 1-2%. The code size increase is 1% for all the benchmarks except the image processing benchmark which increases by 6% (perf improves by 20%). I am working on getting this patch reviewed for trunk. Here is the disussion on this: http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02643.html I have incorporated the comments on making the patch simpler. I will follow-up on that patch to trunk by also getting data on limiting complete peeling with O2. Is this ok for the google branch? Thanks Sri Index: gcc/params.def === --- gcc/params.def (revision 207155) +++ gcc/params.def (working copy) @@ -339,6 +339,11 @@ DEFPARAM(PARAM_MAX_COMPLETELY_PEELED_INSNS, max-completely-peeled-insns, The maximum number of insns of a completely peeled loop, 400, 0, 0) +/* The default maximum number of insns of a peeled loop, with -O2. */ +DEFPARAM(PARAM_MAX_DEFAULT_COMPLETELY_PEELED_INSNS, + max-default-completely-peeled-insns, + The maximum number of insns of a completely peeled loop, + 200, 0, 0) /* The maximum number of peelings of a single loop that is peeled completely. */ DEFPARAM(PARAM_MAX_COMPLETELY_PEEL_TIMES, max-completely-peel-times, Index: gcc/opts.c === --- gcc/opts.c (revision 207155) +++ gcc/opts.c (working copy) @@ -855,6 +855,18 @@ finish_options (struct gcc_options *opts, struct g 0, opts-x_param_values, opts_set-x_param_values); } + /* Set PARAM_MAX_COMPLETELY_PEELED_INSNS to the default original value during + -O2 when -funroll-loops and -fpeel-loops are not set. */ + if (optimize == 2 !opts-x_flag_unroll_loops !opts-x_flag_peel_loops + !opts-x_flag_unroll_all_loops) + +{ + maybe_set_param_value + (PARAM_MAX_COMPLETELY_PEELED_INSNS, +PARAM_VALUE (PARAM_MAX_DEFAULT_COMPLETELY_PEELED_INSNS), + opts-x_param_values, opts_set-x_param_values); +} + /* Set PARAM_MAX_STORES_TO_SINK to 0 if either vectorization or if-conversion is disabled. */ if ((!opts-x_flag_tree_loop_vectorize !opts-x_flag_tree_slp_vectorize) Index: gcc/tree-ssa-loop.c === --- gcc/tree-ssa-loop.c (revision 207155) +++ gcc/tree-ssa-loop.c (working copy) @@ -467,7 +467,7 @@ tree_complete_unroll (void) return tree_unroll_loops_completely (flag_unroll_loops || flag_peel_loops - || optimize = 3, true); + || optimize = 2, true); } static bool Index: gcc/testsuite/gcc.target/i386/bmi2-bzhi64-1a.c
Re: [google gcc-4_8] Tree Loop Unrolling - Relax code size increase with -O2
Ok. David On Mon, Jan 27, 2014 at 5:02 PM, Sriraman Tallam tmsri...@google.com wrote: Hi David, I had to fix a couple of tests. I have attached the patch with the fixed tests. The fixes are simple. The tests fail due to two reasons: 1) Tests like bmi2-pext32-1a.c fail because the vectorize loop is unrolled and directive { scan-assembler-times bmi2_pext_si3 1 } fails because bmi2_pext_si3 occurs more than once. This is fixed by changing the directive to scan-assembler 2) Tests like bmi2-bzhi64-1a.c fail because the unrolled loop no longer needs the bzhi instruction as this gets folded into a constant since the value is now known for each iteration. In order for this test to make sense, I disabled the unrolling in O2 by setting the code size growth to zero via option --param max-default-completely-peeled-insns=0. All the fixes fell into one of the above two patterns with one exception, pr53265.c. Loop unrolling exposed the array out of bounds access which is now caught. Ok to commit? Thanks Sri On Tue, Jan 21, 2014 at 4:51 PM, Xinliang David Li davi...@google.com wrote: ok. David On Tue, Jan 21, 2014 at 4:46 PM, Sriraman Tallam tmsri...@google.com wrote: On Tue, Jan 21, 2014 at 2:49 PM, Xinliang David Li davi...@google.com wrote: I think it might be better to introduce a new parameter for max peel insn at O2 (e.g, call it MAX_O2_COMPLETELY_PEEL_INSN or MAX_DEFAULT_...), and use the same logic in your patch to override the MAX_COMPLETELY_PEELED_INSN parameter at O2). By so doing, we don't need to have a hard coded factor of 2. Patch attached with that change. Sri In the longer run, we really need better cost/benefit analysis, but that is independent. David On Tue, Jan 21, 2014 at 1:49 PM, Sriraman Tallam tmsri...@google.com wrote: Hi, Currently, tree unrolling pass(cunroll) does not allow any code size growth in O2 mode. Code size growth is permitted only if O3 or funroll-loops/fpeel-loops is used. I have created a patch to allow partial code size increase in O2 mode. With funroll-loops the maximum allowed code growth is 400 unrolled insns. I have set it to 200 unrolled insns in O2 mode. This patch improves an image processing benchmark by 20%. It improves most benchmarks by 1-2%. The code size increase is 1% for all the benchmarks except the image processing benchmark which increases by 6% (perf improves by 20%). I am working on getting this patch reviewed for trunk. Here is the disussion on this: http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02643.html I have incorporated the comments on making the patch simpler. I will follow-up on that patch to trunk by also getting data on limiting complete peeling with O2. Is this ok for the google branch? Thanks Sri
Re: configure check for flex
On Mon, 27 Jan 2014, Bruce Korb wrote: On Sun, Jan 26, 2014 at 9:38 PM, Hans-Peter Nilsson h...@bitrange.com wrote: On Sun, 8 Dec 2013, Bruce Korb wrote: On 12/08/13 13:06, Gerald Pfeifer wrote: Lovely. Thank you very much! (Looks like nobody replied to this and it isn't committed.) No, flex isn't required to build GCC as a hard and fast rule. It's not required for releases, just when building from a svn checkout (or really: when the flex-generated files are not in the source directory). You'd need some additional conditions. There might be the additional issue that any lex is expected to work too, not just flex. It isn't committed 'cuz nobody said, Okay. I do wish either someone would say, Okay. or come up with something that works. I went to the effort to figure out where things got off the rails and did something that worked for me. Just saying, That won't work without a workable alternative is a bit irritating. There are surely plenty of opportunities around for irritatation! :) Dropped patches surely; I thought I was helpful there. Ungraceful errors from easily identifiable common gotchas definitely, so what you're trying to achieve is IMHO desirable. Patches hacking in something that just happened to work for someone too; I tried to stop that from happening. I do not know the difference between a checkout build and a normal configured build. There's a difference between builds from released tarballs and builds from svn co + contrib/gcc_update, yes. My understanding was that generated files were to be part of the repo and that there was *not* a difference. Nope, fewer generated files in the repo. (Not all of them, not none of them.) If there is, then someone who understands the difference could maybe add some configure infrastructure to test the environment and decide if flex (or lex) was needed, rather than just say, what you did won't work. See is_release in that same configure.ac, that might be the only additional condition that's needed. Happy Hacking. brgds, H-P
Re: C vs. C++ breakage on 4.7 (was Re: [Patch, fortran] PR58007: unresolved fixup hell)
On Mon, 27 Jan 2014, Richard Biener wrote: Huh, so we have C for cross-builds and C++ for bootstraps. No, we use a C host compiler in both cases. Only stages 2 and 3 build with a C++ compiler. Tomatos potatoes! As fortran isn't built until then, it'll be built as C for cross-builds and C++ for native bootstraps. Can we make stage 2 and 3 built with C on the 4.7 branch? Richard. I wish we could retire that difference *also* on the 4.7 branch (using either C *or* C++ for *both* would be fine with me FWIW). I believe we're now eperiencing more problems than benefits with that difference, now that the migration is over. Looks like you committed C++ code there, in module.c: Alright; can you try the attached patch? Sorry, not at the moment, but I see Janus took care of that (thanks) and it looks pretty obvious to me. It'll be noticed when it's committed... brgds, H-P
Re: [PATCH, ARM] ICE when building kernel raid6 neon code
On 28 January 2014 01:07, Ramana Radhakrishnan ramana@googlemail.com wrote: On Thu, Jan 16, 2014 at 5:44 AM, Zhenqiang Chen zhenqiang.c...@linaro.org wrote: Thanks for comments. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59837 The patch with a test case is attached. +/* { dg-options -Os -fno-omit-frame-pointer -mapcs -mabi=aapcs-linux -marm -mfloat-abi=softfp -g } */ Can you instead do ? { dg-options -Os -fno-omit-frame-pointer -mapcs } { dg-add-options arm_neon } I don't like this as it as it stands because the test relies on the compiler being configured for neon by default. Thanks. The test case is updated according to your comments. The patch is also updated to skip dwarf info in function arm_emit_multi_reg_pop when shrink-wrap is not enabled. A new test case (pr59837-1.c) is added to reproduce the issue. And I double check the arm_expand_epilogue_apcs_frame. There is no more function which adds REG_CFA_ADJUST_CFA NOTE. Thanks! -Zhenqiang 2014-01-16 Zhenqiang Chen zhenqiang.c...@linaro.org PR target/59837 * config/arm/arm.c (arm_emit_vfp_multi_reg_pop): Do not add REG_CFA_ADJUST_CFA NOTE if shrink-wrap is not enabled. testsuite/ChangeLog: 2014-01-16 Zhenqiang Chen zhenqiang.c...@linaro.org * gcc.target/arm/pr59837.c: New testcase. On 15 January 2014 19:56, Ramana Radhakrishnan ramana.radhakrish...@arm.com wrote: Please also create a bugzilla entry for this and use the pr number here. Ramana Sent from Samsung Mobile Original message From: Zhenqiang Chen zhenqiang.c...@linaro.org Date: To: gcc-patches@gcc.gnu.org Cc: Richard Earnshaw richard.earns...@arm.com,Ramana Radhakrishnan ramana.radhakrish...@arm.com Subject: [PATCH, ARM] ICE when building kernel raid6 neon code Hi, The patch fixes ICE when building kernel raid6 neon code. lib/raid6/neon4.c: In function 'raid6_ neon4_gen_syndrome_real': lib/raid6/neon4.c:113:1: internal compiler error: in dwarf2out_frame_debug_adjust_cfa, at dwarf2cfi.c:1090 } https://bugs.launchpad.net/gcc-linaro/+bug/1268893 Root cause: When expanding epilogue, REG_CFA_ADJUST_CFA NOTE is added to handle dwarf info issue for shrink-wrap. But for TARGET_APCS_FRAME, shrink-wrap is disabled. And not all dwarf info in arm_expand_epilogue_apcs_frame are correctly updated. arm_emit_vfp_multi_reg_pop is called by both arm_expand_epilogue_apcs_frame and arm_expand_epilogue. So we should not add the NOTE in arm_emit_vfp_multi_reg_pop if shrink-wrap is not enabled. Boot strap and no make check regression on ARM Chromebook. OK for trunk? Thanks! -Zhenqiang ChangeLog: 2014-01-15 Zhenqiang Chen zhenqiang.c...@linaro.org * config/arm/arm.c (arm_emit_vfp_multi_reg_pop): Do not add REG_CFA_ADJUST_CFA NOTE if shrink-wrap is not enabled. diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c index 18196b3..1ccb796 100644 --- a/gcc/config/arm/arm.c +++ b/gcc/config/arm/arm.c @@ -19890,8 +19890,12 @@ arm_emit_vfp_multi_reg_pop (int first_reg, int num_regs, rtx base_reg) par = emit_insn (par); REG_NOTES (par) = dwarf; - arm_add_cfa_adjust_cfa_note (par, 2 * UNITS_PER_WORD * num_regs, - base_reg, base_reg); + /* REG_CFA_ADJUST_CFA NOTE is added to handle dwarf info issue when + shrink-wrap is enabled. So when shrink-wrap is not enabled, we should + not add the note. */ + if (flag_shrink_wrap) +arm_add_cfa_adjust_cfa_note (par, 2 * UNITS_PER_WORD * num_regs, +base_reg, base_reg); } /* Generate and emit a pattern that will be recognized as LDRD pattern. If even -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c index fc81bf6..4758c3b 100644 --- a/gcc/config/arm/arm.c +++ b/gcc/config/arm/arm.c @@ -19816,7 +19816,7 @@ arm_emit_multi_reg_pop (unsigned long saved_regs_mask) par = emit_insn (par); REG_NOTES (par) = dwarf; - if (!return_in_pc) + if (!return_in_pc flag_shrink_wrap) arm_add_cfa_adjust_cfa_note (par, UNITS_PER_WORD * num_regs, stack_pointer_rtx, stack_pointer_rtx); } @@ -19890,8 +19890,12 @@ arm_emit_vfp_multi_reg_pop (int first_reg, int num_regs, rtx base_reg) par = emit_insn (par); REG_NOTES (par) = dwarf; - arm_add_cfa_adjust_cfa_note (par, 2 * UNITS_PER_WORD * num_regs, - base_reg, base_reg); + /*
C++ PATCH for c++/59097 (ICE with invalid array bound)
maybe_constant_value doesn't deal well with void expressions, and we shouldn't expect it to. Tested x86_64-pc-linux-gnu, applying to trunk and 4.8. commit 0d1fe0783012b1e43b630f526f90e3a9cd6be434 Author: Jason Merrill ja...@redhat.com Date: Mon Jan 27 10:01:30 2014 -0500 PR c++/59097 * decl.c (compute_array_index_type): Don't call maybe_constant_value for a non-integral expression. diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c index 38f2de0..7ebb05d 100644 --- a/gcc/cp/decl.c +++ b/gcc/cp/decl.c @@ -8262,7 +8262,9 @@ compute_array_index_type (tree name, tree size, tsubst_flags_t complain) abi_1_itype = error_mark_node; } - size = maybe_constant_value (size); + if (INTEGRAL_OR_UNSCOPED_ENUMERATION_TYPE_P (type)) + size = maybe_constant_value (size); + if (!TREE_CONSTANT (size)) size = osize; } diff --git a/gcc/testsuite/g++.dg/ext/stmtexpr15.C b/gcc/testsuite/g++.dg/ext/stmtexpr15.C new file mode 100644 index 000..83a831c --- /dev/null +++ b/gcc/testsuite/g++.dg/ext/stmtexpr15.C @@ -0,0 +1,7 @@ +// PR c++/59097 +// { dg-options } + +void foo() +{ + int x[({ return; })]; // { dg-error non-integral } +}
C++ PATCH for c++/58837 (ICE on invalid static_assert)
This testcase uses the name of a non-static member function as a truthvalue, which is ill-formed and confuses c_common_truthvalue_conversion. Avoid the ICE by explicitly comparing it to nullptr, which will get the invalid use of member function error we want. Tested x86_64-pc-linux-gnu, applying to trunk and 4.8. commit 44c3240b029ab9f7bfb2a1a64245ea8ef3af9a49 Author: Jason Merrill ja...@redhat.com Date: Mon Jan 27 10:11:11 2014 -0500 PR c++/58837 * typeck.c (cp_truthvalue_conversion): Use explicit comparison for FUNCTION_DECL. diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c index 78090a7..b7ece1b 100644 --- a/gcc/cp/typeck.c +++ b/gcc/cp/typeck.c @@ -5182,7 +5182,9 @@ tree cp_truthvalue_conversion (tree expr) { tree type = TREE_TYPE (expr); - if (TYPE_PTRDATAMEM_P (type)) + if (TYPE_PTRDATAMEM_P (type) + /* Avoid ICE on invalid use of non-static member function. */ + || TREE_CODE (expr) == FUNCTION_DECL) return build_binary_op (EXPR_LOCATION (expr), NE_EXPR, expr, nullptr_node, 1); else if (TYPE_PTR_P (type) || TYPE_PTRMEMFUNC_P (type)) diff --git a/gcc/testsuite/g++.dg/cpp0x/static_assert9.C b/gcc/testsuite/g++.dg/cpp0x/static_assert9.C new file mode 100644 index 000..fccaa44 --- /dev/null +++ b/gcc/testsuite/g++.dg/cpp0x/static_assert9.C @@ -0,0 +1,7 @@ +// PR c++/58837 +// { dg-require-effective-target c++11 } + +void f(); +static_assert(f, ); +struct A {}; +static_assert(A::~A, ); // { dg-error non-static member function }
C++ PATCH for c++/58814 (ICE with volatile vector)
stabilize_expr can't deal with a volatile vector variable; it tries to stabilize a glvalue with side-effects by storing its address in a temporary and then dereferencing that, but if the type of the reference is volatile then that doesn't actually help at all. In this case, there's a simple solution: force the rhs to be an rvalue before trying to stabilize it. In that case, stabilize_expr knows it can just copy the value into a temporary. Tested x86_64-pc-linux-gnu, applying to trunk and 4.8. commit 63317e9a0f674e06909cfb31262f7b37631f74e6 Author: Jason Merrill ja...@redhat.com Date: Mon Jan 27 10:37:03 2014 -0500 PR c++/58814 * typeck.c (cp_build_modify_expr): Make the RHS an rvalue before stabilizing. diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c index b7ece1b..6268f7b 100644 --- a/gcc/cp/typeck.c +++ b/gcc/cp/typeck.c @@ -7399,8 +7399,7 @@ cp_build_modify_expr (tree lhs, enum tree_code modifycode, tree rhs, side effect associated with any single compound assignment operator. -- end note ] */ lhs = stabilize_reference (lhs); - if (TREE_SIDE_EFFECTS (rhs)) - rhs = mark_rvalue_use (rhs); + rhs = rvalue (rhs); rhs = stabilize_expr (rhs, init); newrhs = cp_build_binary_op (input_location, modifycode, lhs, rhs, diff --git a/gcc/testsuite/g++.dg/ext/vector25.C b/gcc/testsuite/g++.dg/ext/vector25.C new file mode 100644 index 000..6c1f5d0 --- /dev/null +++ b/gcc/testsuite/g++.dg/ext/vector25.C @@ -0,0 +1,6 @@ +volatile int i __attribute__((vector_size(8))); + +void foo() +{ + i += i; +}
C++ PATCHes for Core 1288 and c++/58812 (ICE with excess braces)
The first patch implements core DR 1288, which adjusts the list-initialization rules so that an initializer-list containing a single element of the same type as the target is treated as the initializer by itself. The second patch expands the excess braces diagnostic to cover reference initialization as well as scalar, and thereby avoids an ICE when trying to convert them. Tested x86_64-pc-linux-gnu. First patch applied to trunk, second to both trunk and 4.8. commit 516bb653326cd0ec8eb17c17c358eb0f8ed17e79 Author: Jason Merrill ja...@redhat.com Date: Mon Jan 27 11:05:01 2014 -0500 Core DR 1288 * call.c (reference_binding): Only elide braces if the single element is reference-related. diff --git a/gcc/cp/call.c b/gcc/cp/call.c index 2c77973..7d6e621 100644 --- a/gcc/cp/call.c +++ b/gcc/cp/call.c @@ -1460,16 +1460,29 @@ reference_binding (tree rto, tree rfrom, tree expr, bool c_cast_p, int flags, if (expr BRACE_ENCLOSED_INITIALIZER_P (expr)) { maybe_warn_cpp0x (CPP0X_INITIALIZER_LISTS); + /* DR 1288: Otherwise, if the initializer list has a single element + of type E and ... [T's] referenced type is reference-related to E, + the object or reference is initialized from that element... */ + if (CONSTRUCTOR_NELTS (expr) == 1) + { + tree elt = CONSTRUCTOR_ELT (expr, 0)-value; + if (error_operand_p (elt)) + return NULL; + tree etype = TREE_TYPE (elt); + if (reference_related_p (to, etype)) + { + expr = elt; + from = etype; + goto skip; + } + } + /* Otherwise, if T is a reference type, a prvalue temporary of the + type referenced by T is copy-list-initialized or + direct-list-initialized, depending on the kind of initialization + for the reference, and the reference is bound to that temporary. */ conv = implicit_conversion (to, from, expr, c_cast_p, flags, complain); - if (!CLASS_TYPE_P (to) - CONSTRUCTOR_NELTS (expr) == 1) - { - expr = CONSTRUCTOR_ELT (expr, 0)-value; - if (error_operand_p (expr)) - return NULL; - from = TREE_TYPE (expr); - } +skip:; } if (TREE_CODE (from) == REFERENCE_TYPE) diff --git a/gcc/testsuite/g++.dg/cpp0x/initlist22.C b/gcc/testsuite/g++.dg/cpp0x/initlist22.C index f913aeb..19aefd3 100644 --- a/gcc/testsuite/g++.dg/cpp0x/initlist22.C +++ b/gcc/testsuite/g++.dg/cpp0x/initlist22.C @@ -1,4 +1,4 @@ -// Core issue 934 +// Core issue 934/1288 // { dg-options -std=c++11 } int i; @@ -13,12 +13,12 @@ struct A { int i; } a; A r5 { i }; // { dg-error } reference to temporary A r6 { i }; // OK, aggregate initialization of temporary -A r7 { a }; // { dg-error } invalid aggregate initializer for A -A r8 { a }; // { dg-error } invalid aggregate initializer for A +A r7 { a }; // OK, direct-initialization +A r8 { a }; // { dg-error lvalue } binding to lvalue struct B { B(int); int i; } b(0); B r9 { i }; // { dg-error } reference to temporary B r10 { i }; // OK, make temporary with B(int) constructor -B r11 { b }; // { dg-error } reference to temporary -B r12 { b }; // OK, make temporary with copy constructor +B r11 { b }; // OK, direct-initialization +B r12 { b }; // { dg-error lvalue } binding to lvalue commit f6d43f1f8f3c233f916025837d246aba9e78fa65 Author: Jason Merrill ja...@redhat.com Date: Mon Jan 27 11:16:14 2014 -0500 PR c++/58812 * call.c (convert_like_real): Give helpful error about excess braces for ck_rvalue of scalar type. diff --git a/gcc/cp/call.c b/gcc/cp/call.c index 7d6e621..b72f2d4 100644 --- a/gcc/cp/call.c +++ b/gcc/cp/call.c @@ -5879,9 +5879,11 @@ convert_like_real (conversion *convs, tree expr, tree fn, int argnum, convs-kind != ck_ambig (convs-kind != ck_ref_bind || convs-user_conv_p) - convs-kind != ck_rvalue + (convs-kind != ck_rvalue + || SCALAR_TYPE_P (totype)) convs-kind != ck_base) { + bool complained = false; conversion *t = convs; /* Give a helpful error if this is bad because of excess braces. */ @@ -5889,7 +5891,13 @@ convert_like_real (conversion *convs, tree expr, tree fn, int argnum, SCALAR_TYPE_P (totype) CONSTRUCTOR_NELTS (expr) 0 BRACE_ENCLOSED_INITIALIZER_P (CONSTRUCTOR_ELT (expr, 0)-value)) - permerror (loc, too many braces around initializer for %qT, totype); + { + complained = permerror (loc, too many braces around initializer + for %qT, totype); + while (BRACE_ENCLOSED_INITIALIZER_P (expr) + CONSTRUCTOR_NELTS (expr) == 1) + expr = CONSTRUCTOR_ELT (expr, 0)-value; + } for (; t ; t = next_conversion (t)) { @@ -5925,9 +5933,10 @@ convert_like_real (conversion *convs, tree expr, tree fn, int argnum, else if (t-kind == ck_identity) break; } - if (permerror (loc, invalid conversion from %qT to %qT, -TREE_TYPE (expr), totype) - fn) + if (!complained) + complained = permerror (loc, invalid conversion
C++ PATCH for c++/58639 (infinite recursion with {} initialization of self-reference)
Missing initializers in an aggregate initialization mean that the members with no explicit initializer are themselves initialized from {}, which more or less means value-initialization. But that's ill-formed for a reference, so we don't need to recurse forever. Tested x86_64-pc-linux-gnu, applying to trunk, 4.7 and 4.8. commit e7ed4fa2b0d9d0d1a49fb7b5cbbdaff3649db7cb Author: Jason Merrill ja...@redhat.com Date: Mon Jan 27 15:12:10 2014 -0500 PR c++/59823 * call.c (reference_binding): Pass LOOKUP_NO_TEMP_BIND for list-initialization. A conversion to rvalue ref that involves an lvalue-rvalue conversion is bad. (convert_like_real): Give helpful error message. diff --git a/gcc/cp/call.c b/gcc/cp/call.c index b3db840..f6566cf 100644 --- a/gcc/cp/call.c +++ b/gcc/cp/call.c @@ -1484,7 +1484,7 @@ reference_binding (tree rto, tree rfrom, tree expr, bool c_cast_p, int flags, direct-list-initialized, depending on the kind of initialization for the reference, and the reference is bound to that temporary. */ conv = implicit_conversion (to, from, expr, c_cast_p, - flags, complain); + flags|LOOKUP_NO_TEMP_BIND, complain); skip:; } @@ -1637,9 +1637,9 @@ reference_binding (tree rto, tree rfrom, tree expr, bool c_cast_p, int flags, /* [dcl.init.ref] - Otherwise, the reference shall be to a non-volatile const type. - - Under C++0x, [8.5.3/5 dcl.init.ref] it may also be an rvalue reference */ + Otherwise, the reference shall be an lvalue reference to a + non-volatile const type, or the reference shall be an rvalue + reference. */ if (!CP_TYPE_CONST_NON_VOLATILE_P (to) !TYPE_REF_IS_RVALUE (rto)) return NULL; @@ -1677,7 +1677,16 @@ reference_binding (tree rto, tree rfrom, tree expr, bool c_cast_p, int flags, /* This reference binding, unlike those above, requires the creation of a temporary. */ conv-need_temporary_p = true; - conv-rvaluedness_matches_p = TYPE_REF_IS_RVALUE (rto); + if (TYPE_REF_IS_RVALUE (rto)) +{ + conv-rvaluedness_matches_p = 1; + /* In the second case, if the reference is an rvalue reference and + the second standard conversion sequence of the user-defined + conversion sequence includes an lvalue-to-rvalue conversion, the + program is ill-formed. */ + if (conv-user_conv_p next_conversion (conv)-kind == ck_rvalue) + conv-bad_p = 1; +} return conv; } @@ -5881,7 +5890,7 @@ convert_like_real (conversion *convs, tree expr, tree fn, int argnum, convs-kind != ck_list convs-kind != ck_ambig (convs-kind != ck_ref_bind - || convs-user_conv_p) + || (convs-user_conv_p next_conversion (convs)-bad_p)) (convs-kind != ck_rvalue || SCALAR_TYPE_P (totype)) convs-kind != ck_base) @@ -6173,7 +6182,8 @@ convert_like_real (conversion *convs, tree expr, tree fn, int argnum, if (convs-bad_p !next_conversion (convs)-bad_p) { gcc_assert (TYPE_REF_IS_RVALUE (ref_type) - real_lvalue_p (expr)); + (real_lvalue_p (expr) + || next_conversion(convs)-kind == ck_rvalue)); error_at (loc, cannot bind %qT lvalue to %qT, TREE_TYPE (expr), totype); diff --git a/gcc/testsuite/g++.dg/cpp0x/overload3.C b/gcc/testsuite/g++.dg/cpp0x/overload3.C new file mode 100644 index 000..661d1f3 --- /dev/null +++ b/gcc/testsuite/g++.dg/cpp0x/overload3.C @@ -0,0 +1,18 @@ +// PR c++/59823 +// { dg-options -std=c++11 } +// { dg-do run } + +struct X { }; + +void f(X); + +struct wrap +{ + operator const X() const; +}; + +int main() +{ + wrap w; + f(w);// { dg-error lvalue } +}
C++ PATCH for c++/58606 (ICE with partial specialization in variadic template)
We had been representing a template non-type parameter as the plain TEMPLATE_PARM_INDEX in the CLASSTYPE_TI_ARGS of the template, even for a reference. But when we substitute into that, the reference automatically decays, so it gets wrapped in an INDIRECT_REF that then doesn't compare the same as the TEMPLATE_PARM_INDEX by itself. We've worked around that in tsubst_template_arg by stripping the INDIRECT_REF again, but tsubst_pack_expansion wasn't doing that. Rather than add the same code there, I decided to call convert_from_reference when building the TI_ARGS, so that we don't need any special handling later. Tested x86_64-pc-linux-gnu, applying to trunk and 4.8. commit 598166a22b0b94663860c279dd6a51fc8e73eb74 Author: Jason Merrill ja...@redhat.com Date: Mon Jan 27 13:12:05 2014 -0500 PR c++/58606 * pt.c (template_parm_to_arg): Call convert_from_reference. (tsubst_template_arg): Don't strip reference refs. diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c index 4414e49..661143a 100644 --- a/gcc/cp/pt.c +++ b/gcc/cp/pt.c @@ -3854,6 +3854,7 @@ template_parm_to_arg (tree t) SET_NON_DEFAULT_TEMPLATE_ARGS_COUNT (vec, TREE_VEC_LENGTH (vec)); #endif + t = convert_from_reference (t); TREE_VEC_ELT (vec, 0) = make_pack_expansion (t); t = make_node (NONTYPE_ARGUMENT_PACK); @@ -9281,10 +9282,6 @@ tsubst_template_arg (tree t, tree args, tsubst_flags_t complain, tree in_decl) /*integral_constant_expression_p=*/true); if (!(complain tf_warning)) --c_inhibit_evaluation_warnings; - /* Preserve the raw-reference nature of T. */ - if (TREE_TYPE (t) TREE_CODE (TREE_TYPE (t)) == REFERENCE_TYPE - REFERENCE_REF_P (r)) - r = TREE_OPERAND (r, 0); } return r; } diff --git a/gcc/testsuite/g++.dg/cpp0x/variadic146.C b/gcc/testsuite/g++.dg/cpp0x/variadic146.C new file mode 100644 index 000..0c91db5 --- /dev/null +++ b/gcc/testsuite/g++.dg/cpp0x/variadic146.C @@ -0,0 +1,9 @@ +// PR c++/58606 +// { dg-require-effective-target c++11 } + +templateint...I struct A +{ + templatetypename struct B; + + templatetypename T struct BT* {}; +};
C++ PATCH for c++/58504 (ICE with trait in default template arg)
We were tsubsting trait arguments wrong: a type gets tsubst, not tsubst_copy. Tested x86_64-pc-linux-gnu, applying to trunk, 4.7, 4.8. commit bf602b5f571b47d41ee271fea8d7c6dfa11433ec Author: Jason Merrill ja...@redhat.com Date: Mon Jan 27 13:29:01 2014 -0500 PR c++/58504 * pt.c (tsubst_copy_and_build) [TRAIT_EXPR]: Use tsubst for types. diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c index 661143a..47d07db 100644 --- a/gcc/cp/pt.c +++ b/gcc/cp/pt.c @@ -14974,12 +14974,12 @@ tsubst_copy_and_build (tree t, case TRAIT_EXPR: { - tree type1 = tsubst_copy (TRAIT_EXPR_TYPE1 (t), args, - complain, in_decl); + tree type1 = tsubst (TRAIT_EXPR_TYPE1 (t), args, + complain, in_decl); tree type2 = TRAIT_EXPR_TYPE2 (t); if (type2) - type2 = tsubst_copy (type2, args, complain, in_decl); + type2 = tsubst (type2, args, complain, in_decl); RETURN (finish_trait_expr (TRAIT_EXPR_KIND (t), type1, type2)); } diff --git a/gcc/testsuite/g++.dg/ext/traits1.C b/gcc/testsuite/g++.dg/ext/traits1.C new file mode 100644 index 000..24099e5 --- /dev/null +++ b/gcc/testsuite/g++.dg/ext/traits1.C @@ -0,0 +1,4 @@ +// PR c++/58504 + +templatebool = __has_nothrow_assign(void) struct A {}; +A a;
C++ PATCH for c++/54652 (ICE with repeated typedef/attribute)
Since duplicate_decls throws away the new decl before returning 1, we need to make sure that we don't have anything pointing to it. In a TYPE_DECL, the type points back to the decl via TYPE_NAME, so we always need to choose the type from the olddecl. Tested x86_64-pc-linux-gnu, applying to trunk and 4.8. commit 9dd7f9667b090b7e8c045eecb8b16db6930204eb Author: Jason Merrill ja...@redhat.com Date: Mon Jan 27 14:16:36 2014 -0500 PR c++/54652 * decl.c (duplicate_decls): Always use oldtype for TYPE_DECL. diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c index 7ebb05d..c93c783 100644 --- a/gcc/cp/decl.c +++ b/gcc/cp/decl.c @@ -1926,9 +1926,9 @@ duplicate_decls (tree newdecl, tree olddecl, bool newdecl_is_friend) /* Merge the data types specified in the two decls. */ newtype = merge_types (TREE_TYPE (newdecl), TREE_TYPE (olddecl)); - /* If merge_types produces a non-typedef type, just use the old type. */ - if (TREE_CODE (newdecl) == TYPE_DECL - newtype == DECL_ORIGINAL_TYPE (newdecl)) + /* For typedefs use the old type, as the new type's DECL_NAME points + at newdecl, which will be ggc_freed. */ + if (TREE_CODE (newdecl) == TYPE_DECL) newtype = oldtype; if (VAR_P (newdecl)) diff --git a/gcc/testsuite/g++.dg/ext/attrib48.C b/gcc/testsuite/g++.dg/ext/attrib48.C new file mode 100644 index 000..19a9959 --- /dev/null +++ b/gcc/testsuite/g++.dg/ext/attrib48.C @@ -0,0 +1,6 @@ +// PR c++/54652 + +typedef unsigned L __attribute__ ((aligned)); +typedef unsigned L __attribute__ ((aligned)); + +L l;
C++ PATCH for c++/59823 (wrong overload resolution)/DR 1138
In the original testcase we were failing to prefer the copy assignment (which can take the result of the conversion operator directly) to a copy constructor followed by move assignment. The best way to fix this was to make the latter ill-formed, as it is supposed to be under DR 1138: just as you can't bind an rvalue reference to an lvalue variable, you can't bind it to the lvalue result of a conversion op either. Tested x86_64-pc-linux-gnu, applying to trunk. commit ea7984932ac06b3899c0d7be78f7197f1c40421d Author: Jason Merrill ja...@redhat.com Date: Mon Jan 27 15:12:10 2014 -0500 PR c++/59823 Core DR 1138 * call.c (reference_binding): Pass LOOKUP_NO_TEMP_BIND for list-initialization. A conversion to rvalue ref that involves an lvalue-rvalue conversion is bad. (convert_like_real): Give helpful error message. diff --git a/gcc/cp/call.c b/gcc/cp/call.c index b3db840..f6566cf 100644 --- a/gcc/cp/call.c +++ b/gcc/cp/call.c @@ -1484,7 +1484,7 @@ reference_binding (tree rto, tree rfrom, tree expr, bool c_cast_p, int flags, direct-list-initialized, depending on the kind of initialization for the reference, and the reference is bound to that temporary. */ conv = implicit_conversion (to, from, expr, c_cast_p, - flags, complain); + flags|LOOKUP_NO_TEMP_BIND, complain); skip:; } @@ -1637,9 +1637,9 @@ reference_binding (tree rto, tree rfrom, tree expr, bool c_cast_p, int flags, /* [dcl.init.ref] - Otherwise, the reference shall be to a non-volatile const type. - - Under C++0x, [8.5.3/5 dcl.init.ref] it may also be an rvalue reference */ + Otherwise, the reference shall be an lvalue reference to a + non-volatile const type, or the reference shall be an rvalue + reference. */ if (!CP_TYPE_CONST_NON_VOLATILE_P (to) !TYPE_REF_IS_RVALUE (rto)) return NULL; @@ -1677,7 +1677,16 @@ reference_binding (tree rto, tree rfrom, tree expr, bool c_cast_p, int flags, /* This reference binding, unlike those above, requires the creation of a temporary. */ conv-need_temporary_p = true; - conv-rvaluedness_matches_p = TYPE_REF_IS_RVALUE (rto); + if (TYPE_REF_IS_RVALUE (rto)) +{ + conv-rvaluedness_matches_p = 1; + /* In the second case, if the reference is an rvalue reference and + the second standard conversion sequence of the user-defined + conversion sequence includes an lvalue-to-rvalue conversion, the + program is ill-formed. */ + if (conv-user_conv_p next_conversion (conv)-kind == ck_rvalue) + conv-bad_p = 1; +} return conv; } @@ -5881,7 +5890,7 @@ convert_like_real (conversion *convs, tree expr, tree fn, int argnum, convs-kind != ck_list convs-kind != ck_ambig (convs-kind != ck_ref_bind - || convs-user_conv_p) + || (convs-user_conv_p next_conversion (convs)-bad_p)) (convs-kind != ck_rvalue || SCALAR_TYPE_P (totype)) convs-kind != ck_base) @@ -6173,7 +6182,8 @@ convert_like_real (conversion *convs, tree expr, tree fn, int argnum, if (convs-bad_p !next_conversion (convs)-bad_p) { gcc_assert (TYPE_REF_IS_RVALUE (ref_type) - real_lvalue_p (expr)); + (real_lvalue_p (expr) + || next_conversion(convs)-kind == ck_rvalue)); error_at (loc, cannot bind %qT lvalue to %qT, TREE_TYPE (expr), totype); diff --git a/gcc/testsuite/g++.dg/cpp0x/overload3.C b/gcc/testsuite/g++.dg/cpp0x/overload3.C new file mode 100644 index 000..e521b35 --- /dev/null +++ b/gcc/testsuite/g++.dg/cpp0x/overload3.C @@ -0,0 +1,17 @@ +// PR c++/59823 +// { dg-options -std=c++11 } + +struct X { }; + +void f(X); + +struct wrap +{ + operator const X() const; +}; + +int main() +{ + wrap w; + f(w);// { dg-error lvalue } +}
Re: [C++ patch] for c++/37140
On 01/27/2014 04:28 PM, Fabien Chêne wrote: + if (DECL_DEPENDENT_P (decl) USING_DECL_TYPENAME_P (decl)) +{ + /* We have found a type introduced by a using +declaration at class scope that refers to a dependent +type. + +using typename :: [opt] nested-name-specifier unqualified-id ; + */ + decl = make_typename_type (TREE_TYPE (decl), +DECL_NAME (decl), +typename_type, tf_error); + if (decl != error_mark_node) + decl = TYPE_NAME (decl); + + return decl; +} + while (TREE_CODE (decl) == USING_DECL !DECL_DEPENDENT_P (decl)) decl = USING_DECL_DECLS (decl); Shouldn't the new code be after the while loop? Jason
[PATCH][PING] Fix for PR59600 (prohibit inlining if no_sanitize_address)
Original Message Subject: [PATCH] Fix for PR59600 Date: Tue, 21 Jan 2014 14:42:31 +0400 From: Yury Gribov y.gri...@samsung.com To: GCC Patches gcc-patches@gcc.gnu.org Hi, This patch fixes the problem reported in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59600 : functions with mismatching no_sanitize_address attributes should not be considered for inlining, otherwise the meaning of no_sanitize_address will not be preserved. I didn't get feedback in Bugzilla so I'm sending the patch here. Bootstrapped/regtested on x64. -Y gcc/ChangeLog: 2014-01-21 ygribov ygri...@samsung.com * cif-code.def (OPTION_MISMATCH): New CIF code. * ipa-inline.c (report_inline_failed_reason): Handle mismatched sanitization attributes. (sanitize_attrs_match_for_inline_p): New function. (can_inline_edge_p): Likewise. gcc/testsuite/ChangeLog: 2014-01-21 ygribov ygri...@samsung.com * gcc.dg/asan/nosanitize-and-inline.c: : New test. diff --git a/gcc/cif-code.def b/gcc/cif-code.def index f1df5a0..1418f8e 100644 --- a/gcc/cif-code.def +++ b/gcc/cif-code.def @@ -109,3 +109,6 @@ DEFCIFCODE(OPTIMIZATION_MISMATCH, N_(optimization level attribute mismatch)) /* We can't inline because the callee refers to comdat-local symbols. */ DEFCIFCODE(USES_COMDAT_LOCAL, N_(callee refers to comdat-local symbols)) + +/* We can't inline because of mismatched options. */ +DEFCIFCODE(OPTION_MISMATCH, N_(option mismatch)) diff --git a/gcc/ipa-inline.c b/gcc/ipa-inline.c index 12ee84c..9118561 100644 --- a/gcc/ipa-inline.c +++ b/gcc/ipa-inline.c @@ -234,7 +234,25 @@ report_inline_failed_reason (struct cgraph_edge *e) } } -/* Decide if we can inline the edge and possibly update + /* Decide whether sanitizer-related attributes allow inlining. */ + +static bool +sanitize_attrs_match_for_inline_p (const_tree caller, const_tree callee) +{ + /* Don't care if sanitizer is disabled */ + if (!(flag_sanitize SANITIZE_ADDRESS)) +return true; + + if (!caller || !callee) +return true; + + return lookup_attribute (no_sanitize_address, + DECL_ATTRIBUTES (caller)) == +lookup_attribute (no_sanitize_address, + DECL_ATTRIBUTES (callee)); +} + + /* Decide if we can inline the edge and possibly update inline_failed reason. We check whether inlining is possible at all and whether caller growth limits allow doing so. @@ -327,6 +345,12 @@ can_inline_edge_p (struct cgraph_edge *e, bool report, e-inline_failed = CIF_TARGET_OPTION_MISMATCH; inlinable = false; } + /* Don't inline a function with mismatched sanitization attributes. */ + else if (!sanitize_attrs_match_for_inline_p (e-caller-decl, callee-decl)) +{ + e-inline_failed = CIF_OPTION_MISMATCH; + inlinable = false; +} /* Check if caller growth allows the inlining. */ else if (!DECL_DISREGARD_INLINE_LIMITS (callee-decl) !disregard_limits diff --git a/gcc/testsuite/gcc.dg/asan/nosanitize-and-inline.c b/gcc/testsuite/gcc.dg/asan/nosanitize-and-inline.c index e69de29..5853801 100644 --- a/gcc/testsuite/gcc.dg/asan/nosanitize-and-inline.c +++ b/gcc/testsuite/gcc.dg/asan/nosanitize-and-inline.c @@ -0,0 +1,57 @@ +/* { dg-do run } */ + +/* This is a simplified version of what Emacs does internally, + when marking its stack. */ + +static unsigned long sum; +static void *stack_base; + +/* A simple substitute for what Emacs actually does. */ +static void +mark_maybe_pointer (void *p) +{ + sum ^= (unsigned long) p; +} + +static inline void __attribute__ ((no_sanitize_address)) +mark_memory (void **start, void **end) +{ + void **pp; + + if (end start) +{ + void **tem = start; + start = end; + end = tem; +} + + for (pp = start; pp end; pp++) +{ + /* This is the dereference that we don't want sanitized. */ + void *p = *pp; + + mark_maybe_pointer (p); +} +} + +static void +mark_stack (void) +{ + void *end; + mark_memory (stack_base, end); +} + +void +garbage_collect (void) +{ + mark_stack (); +} + +int +main (void) +{ + void *dummy; + stack_base = dummy; + garbage_collect (); + return 0; +}
Re: Disable accumulate-outgoing-args for Generic and Buldozers
On Tue, Jan 28, 2014 at 12:56:28AM +0100, Jan Hubicka wrote: On Mon, Jan 27, 2014 at 11:19:39PM +0100, Jakub Jelinek wrote: Are you sure this is a good idea even for 32-bit code (i.e. shouldn't we have separate tunables for 32-bit and 64-bit code)? I admit I haven't performed trunk bootstraps/regtests for 3 days, am doing x86_64 and i686 bootstraps/regtests concurrently and it is yes,rtl checking, but am quite surprised that compared to 3 days ago the bootstrap time of i686-linux (all,obj-c++,go) went up from about 70 minutes or so to 140 minutes today, while the x86_64-linux (all,obj-c++,go,ada) remained basically the same around 2 hours. This is on quad socket Quad-Core AMD Opteron(tm) Processor 8354, perhaps it is just extremely undesirable there. Most likely the big slowdown is var-tracking, at least stage2 insn-recog.o (yes,rtl checking on i686-linux) took = 23 minutes to compile and stage3 = 62 minutes, with 45 minutes from that only spent on compiling insn-recog.o and nothing else. Note, looking at the previous bootstraps before your change, insn-recog.o was taking = 15-16 minutes to compile both in stage2 and stage3 (the = stands for comparison of oldest *.o file in {,prev-}gcc/ directory and insn-recog.o, but for the latest bootstrap stage3 I remember seeing in top 58 minutes and it was still compiling, haven't looked exactly when it stopped). In any case, most likely it doesn't mean actual slow down in performance of generated code, but medium slowdown in non-g compile time of extreme testcase and -g compile time going wild. I wonder if this is just some of --enable-checking tests in dwarf2out going wild or if it is just expensive sanity checking code? I used to have chroot environment for 32bit builds, I will need to re-install it now. variable tracking :2914.85 (83%) usr 1.88 ( 7%) sys2931.22 (82%) wall 80844 kB ( 3%) ggc var-tracking dataflow : 18.19 ( 1%) usr 0.19 ( 1%) sys 18.49 ( 1%) wall 10899 kB ( 0%) ggc var-tracking emit : 29.41 ( 1%) usr 0.11 ( 0%) sys 29.65 ( 1%) wall 148128 kB ( 6%) ggc TOTAL :3525.9725.73 3570.33 2321043 kB So, strangely both vt_find_locations and vt_emit_notes, typically the most expensive ones, are quite unexpensive and most of the time is spent elsewhere, in vt_initialize? Jakub
Re: Two build != host fixes
On Fri, Jan 24, 2014 at 10:34:10AM -0700, Jeff Law wrote: Of course, then your question becomes, why exclude CPPFLAGS? (And if CPPFLAGS needs to be excluded here, then I should have just used CPPFLAGS=-DGENERATOR_FILE for the recursive configure call..) I'm not sure now, I'll have to do some digging. Also as to why @INCINTL@ was removed, when gettext is potentially needed for the gen programs. Thanks. My inclination is to go forward with this hunk as well, with any tweaks you find after investigating the situation around CPPFLAGS. I committed the configure.ac change as is and restored CPPFLAGS and @INCINTL@ to the Makefile.in BUILD_CPPFLAGS. CPPFLAGS is set from the top level makefile CPPFLAGS_FOR_TARGET. It's questionable whether using CPPFLAGS_FOR_TARGET is really correct for BUILD_CPPFLAGS but leaving it in is probably safer. Who knows what weird use is being made of CPPFLAGS_FOR_TARGET? @INCINTL@ is set to -I${top_builddir}/../intl when someone configures using --with-included-gettext. It seems reasonable to me that -with-included-gettext affect both build and host. Thanks everyone for your patience. -- Alan Modra Australia Development Lab, IBM
Re: [Patch, fortran] PR58007: unresolved fixup hell
Le 27/01/2014 02:56, Hans-Peter Nilsson a écrit : On Sun, 26 Jan 2014, Mikael Morin wrote: Le 18/01/2014 21:17, Mikael Morin a écrit : Well, I guess that due to the touchy nature of the bug, there are cases that work by luck on old versions and fail (by unluck) on newer ones. Thus, I will backport in a few days to 4.8 and 4.7. I added the following hardening to the patch on the 4.8 backport (http://gcc.gnu.org/r207117 and attached) and forward-ported it to trunk (http://gcc.gnu.org/r207118) as well. 4.7 will come in an hour or so. Did you bootstrap test the 4.7 backport? Yes, works like a charm here. Looks like you committed C++ code there, in module.c: ... 3867 static void 3868 skip_list (int nest_level = 0) 3869 { ... This breaks build. In 4.7 gcc is still C, at least for cross-builds (cris-elf but unimportant): Alright; can you try the attached patch? Mikael Index: module.c === --- module.c (révision 207119) +++ module.c (copie de travail) @@ -3865,7 +3865,7 @@ find_symbol (gfc_symtree *st, const char *name, skipped here. The default value is 0 (balanced parens). */ static void -skip_list (int nest_level = 0) +skip_list (int nest_level) { int level; @@ -4228,7 +4228,7 @@ load_derived_extensions (void) if (!info || !derived) { while (peek_atom () != ATOM_RPAREN) - skip_list (); + skip_list (0); continue; } @@ -4465,18 +4465,18 @@ read_module (void) gfc_symbol *sym; get_module_locus (operator_interfaces); /* Skip these for now. */ - skip_list (); + skip_list (0); get_module_locus (user_operators); - skip_list (); - skip_list (); + skip_list (0); + skip_list (0); /* Skip commons, equivalences and derived type extensions for now. */ - skip_list (); - skip_list (); + skip_list (0); + skip_list (0); get_module_locus (extensions); - skip_list (); + skip_list (0); mio_lparen (); @@ -4514,7 +4514,7 @@ read_module (void) if (sym == NULL || (sym-attr.flavor == FL_VARIABLE info-u.rsym.ns !=1)) { - skip_list (); + skip_list (0); continue; } @@ -4531,13 +4531,13 @@ read_module (void) /* First seek to the symbol's component list. */ mio_lparen (); /* symbol opening. */ - skip_list (); /* skip symbol attribute. */ - skip_list (); /* typespec. */ + skip_list (0); /* skip symbol attribute. */ + skip_list (0); /* typespec. */ require_atom (ATOM_INTEGER); /* namespace ref. */ require_atom (ATOM_INTEGER); /* common ref. */ - skip_list (); /* formal args. */ + skip_list (0); /* formal args. */ /* no value. */ - skip_list (); /* array_spec. */ + skip_list (0); /* array_spec. */ require_atom (ATOM_INTEGER); /* result. */ /* not a cray pointer. */ @@ -4562,7 +4562,7 @@ read_module (void) skip_list (1); /* symbol end. */ } else - skip_list (); + skip_list (0); /* Some symbols do not have a namespace (eg. formal arguments), so the automatic unique symtree mechanism must be suppressed @@ -4725,7 +4725,7 @@ read_module (void) if (u == NULL) { - skip_list (); + skip_list (0); continue; }
Re: [Patch, fortran] PR58007: unresolved fixup hell
Did you bootstrap test the 4.7 backport? Yes, works like a charm here. I also see the build problem (configuring with --enable-languages=c,fortran --disable-bootstrap). Looks like you committed C++ code there, in module.c: ... 3867 static void 3868 skip_list (int nest_level = 0) 3869 { ... This breaks build. In 4.7 gcc is still C, at least for cross-builds (cris-elf but unimportant): Alright; can you try the attached patch? Does appear to fix the build problem. Did not check the testsuite ... Cheers, Janus
Re: [Patch, i386] Separate Intel processor with expanded ISA
Hello! +2013-12-29 Allan Sandfeld Jensen sandf...@kde.org Missing space in ChangeLog entry. + * config/i386/i386.c (get_builtin_code_for_version): Separate + Westmere from Nehalem, Ivy Bridge from Sandy Bridge and + Broadwell from Haswell. --- a/gcc/config/i386/i386.c +++ b/gcc/config/i386/i386.c @@ -31298,18 +31298,27 @@ get_builtin_code_for_version (tree decl, tree *predicate_list) priority = P_PROC_SSSE3; break; case PROCESSOR_NEHALEM: - /* We translate arch=corei7 and arch=nehelam to - corei7 so that it will be mapped to M_INTEL_COREI7 - as cpu type to cover all M_INTEL_COREI7_XXXs. */ - arg_str = corei7; + if (new_target-x_ix86_isa_flags OPTION_MASK_ISA_AES) + arg_str = westmere; + else + /* We translate arch=corei7 and arch=nehelam to Trivial typo above: arch=nehalem. OK for mainline with these changes. Thanks, Uros.
[PATCH - obvious] Remove unused create_gimple_tmp declaration
Hi, I was playing about with an old patch and found that the implementation of create_gimple_tmp was removed by this patch: http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01694.html But that its declaration was left in gimple-builder.h. A quick grep shows that this was the only remaining mention of create_gimple_tmp. I've checked in this obvious patch deleting the declaration as revision 207127, after a bootstrap on x86_64 with no regressions. Thanks, James --- 2014-01-27 James Greenhalgh james.greenha...@arm.com * gimple-builder.h (create_gimple_tmp): Delete. diff --git a/gcc/gimple-builder.h b/gcc/gimple-builder.h index a00d979..1b5afdc 100644 --- a/gcc/gimple-builder.h +++ b/gcc/gimple-builder.h @@ -21,7 +21,6 @@ along with GCC; see the file COPYING3. If not see #ifndef GCC_GIMPLE_BUILDER_H #define GCC_GIMPLE_BUILDER_H -tree create_gimple_tmp (tree, tree lhs = NULL_TREE); gimple build_assign (enum tree_code, tree, int, tree lhs = NULL_TREE); gimple build_assign (enum tree_code, gimple, int, tree lhs = NULL_TREE); gimple build_assign (enum tree_code, tree, tree, tree lhs = NULL_TREE);
[ARM Documentation] Clarify -mcpu, -mtune, -march
Hi, I've tripped myself over with these three options too many times, actually, their behaviour is very simple. This patch clarifies the language used to describe the options, and puts them in a logical order. I'm happy to reword again if this is still not clear. OK? Thanks, James --- gcc/ 2014-01-27 James Greenhalgh james.greenha...@arm.com PR target/59718 * doc/invoke.texi (-march=): Clarify documentation for ARM. (-mtune=): Likewise. (-mcpu=): Likewise. diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index 8c620a5..38a55a0 100644 --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi @@ -12221,11 +12221,35 @@ option should only be used if you require compatibility with code for big-endian ARM processors generated by versions of the compiler prior to 2.8. This option is now deprecated. -@item -mcpu=@var{name} -@opindex mcpu -This specifies the name of the target ARM processor. GCC uses this name -to determine what kind of instructions it can emit when generating -assembly code. Permissible names are: @samp{arm2}, @samp{arm250}, +@item -march=@var{name} +@opindex march +This specifies the name of the target ARM architecture. GCC uses this +name to determine what kind of instructions it can emit when generating +assembly code. This option can be used in conjunction with or instead +of the @option{-mcpu=} option. Permissible names are: @samp{armv2}, +@samp{armv2a}, @samp{armv3}, @samp{armv3m}, @samp{armv4}, @samp{armv4t}, +@samp{armv5}, @samp{armv5t}, @samp{armv5e}, @samp{armv5te}, +@samp{armv6}, @samp{armv6j}, +@samp{armv6t2}, @samp{armv6z}, @samp{armv6zk}, @samp{armv6-m}, +@samp{armv7}, @samp{armv7-a}, @samp{armv7-r}, @samp{armv7-m}, +@samp{armv8-a}, @samp{armv8-a+crc}, +@samp{iwmmxt}, @samp{iwmmxt2}, @samp{ep9312}. + +@option{-march=armv8-a+crc} enables code generation for the ARMv8-A +architecture together with the optional CRC32 extensions. + +@option{-march=native} causes the compiler to auto-detect the architecture +of the build computer. At present, this feature is only supported on +Linux, and not all architectures are recognized. If the auto-detect is +unsuccessful the option has no effect. + +@item -mtune=@var{name} +@opindex mtune +This option specifies the name of the target ARM processor for +which GCC should tune the performance of the code. +For some ARM implementations better performance can be obtained by using +this option. +Permissible names are: @samp{arm2}, @samp{arm250}, @samp{arm3}, @samp{arm6}, @samp{arm60}, @samp{arm600}, @samp{arm610}, @samp{arm620}, @samp{arm7}, @samp{arm7m}, @samp{arm7d}, @samp{arm7dm}, @samp{arm7di}, @samp{arm7dmi}, @samp{arm70}, @samp{arm700}, @@ -12259,26 +12283,6 @@ Additionally, this option can specify that GCC should tune the performance of the code for a big.LITTLE system. Permissible names are: @samp{cortex-a15.cortex-a7}, @samp{cortex-a57.cortex-a53}. -@option{-mcpu=generic-@var{arch}} is also permissible, and is -equivalent to @option{-march=@var{arch} -mtune=generic-@var{arch}}. -See @option{-mtune} for more information. - -@option{-mcpu=native} causes the compiler to auto-detect the CPU -of the build computer. At present, this feature is only supported on -Linux, and not all architectures are recognized. If the auto-detect is -unsuccessful the option has no effect. - -@item -mtune=@var{name} -@opindex mtune -This option is very similar to the @option{-mcpu=} option, except that -instead of specifying the actual target processor type, and hence -restricting which instructions can be used, it specifies that GCC should -tune the performance of the code as if the target were of the type -specified in this option, but still choosing the instructions it -generates based on the CPU specified by a @option{-mcpu=} option. -For some ARM implementations better performance can be obtained by using -this option. - @option{-mtune=generic-@var{arch}} specifies that GCC should tune the performance for a blend of processors within architecture @var{arch}. The aim is to generate code that run well on the current most popular @@ -12291,24 +12295,21 @@ of the build computer. At present, this feature is only supported on Linux, and not all architectures are recognized. If the auto-detect is unsuccessful the option has no effect. -@item -march=@var{name} -@opindex march -This specifies the name of the target ARM architecture. GCC uses this -name to determine what kind of instructions it can emit when generating -assembly code. This option can be used in conjunction with or instead -of the @option{-mcpu=} option. Permissible names are: @samp{armv2}, -@samp{armv2a}, @samp{armv3}, @samp{armv3m}, @samp{armv4}, @samp{armv4t}, -@samp{armv5}, @samp{armv5t}, @samp{armv5e}, @samp{armv5te}, -@samp{armv6}, @samp{armv6j}, -@samp{armv6t2}, @samp{armv6z}, @samp{armv6zk}, @samp{armv6-m}, -@samp{armv7}, @samp{armv7-a}, @samp{armv7-r}, @samp{armv7-m}, -@samp{armv8-a}, @samp{armv8-a+crc}, -@samp{iwmmxt},
Re: [PATCH i386 11/8] [AVX512] [2/2] Add missing packed PF gathers/scatters.
Hello, On 23 Jan 14:22, Uros Bizjak wrote: (define_expand avx512pf_scatterpfmodedf [(unspec [(match_operand:avx512fmaskmode 0 register_or_constm1_operand) (mem:DF (match_par_dup 5 [(match_operand 2 vsib_address_operand) (match_operand:VI4_256_8_512 1 register_operand) (match_operand:SI 3 const1248_operand)])) (match_operand:SI 4 const_0_to_1_operand)] UNSPEC_SCATTER_PREFETCH)] We have this correspondence between, say, main and index modes: SF - (V16SI, V8DI) DF - (V8SI , V8DI) It looks to me that you should use V16SF and V8DF instead of SF and DF modes here. I didn't find existing attributes with necessary mapping, so I invented new. Other than this, the patch looks OK to me. Please wait a day if Jakub has any remark here. Patch in the bottom and I'll check it in this evening (MS time) if no objections. (will update ChangeLog adding new mode attributes) -- Thanks, K gcc/config/i386/avx512pfintrin.h | 113 +++-- gcc/config/i386/i386-builtin-types.def | 2 + gcc/config/i386/i386.c | 37 - gcc/config/i386/sse.md | 176 +++-- gcc/testsuite/gcc.target/i386/avx-1.c | 4 + .../gcc.target/i386/avx512pf-vgatherpf0dpd-1.c | 15 ++ .../gcc.target/i386/avx512pf-vgatherpf0qpd-1.c | 15 ++ .../gcc.target/i386/avx512pf-vgatherpf1dpd-1.c | 15 ++ .../gcc.target/i386/avx512pf-vgatherpf1qpd-1.c | 15 ++ .../gcc.target/i386/avx512pf-vscatterpf0dpd-1.c| 17 ++ .../gcc.target/i386/avx512pf-vscatterpf0qpd-1.c| 17 ++ .../gcc.target/i386/avx512pf-vscatterpf1dpd-1.c| 17 ++ .../gcc.target/i386/avx512pf-vscatterpf1qpd-1.c| 17 ++ gcc/testsuite/gcc.target/i386/sse-14.c | 4 + gcc/testsuite/gcc.target/i386/sse-22.c | 5 + gcc/testsuite/gcc.target/i386/sse-23.c | 4 + 16 files changed, 442 insertions(+), 31 deletions(-) diff --git a/gcc/config/i386/avx512pfintrin.h b/gcc/config/i386/avx512pfintrin.h index b8c0110..bc7598e 100644 --- a/gcc/config/i386/avx512pfintrin.h +++ b/gcc/config/i386/avx512pfintrin.h @@ -48,74 +48,157 @@ typedef unsigned short __mmask16; #ifdef __OPTIMIZE__ extern __inline void __attribute__ ((__gnu_inline__, __always_inline__, __artificial__)) +_mm512_mask_prefetch_i32gather_pd (__m256i index, __mmask8 mask, + void *addr, int scale, int hint) +{ + __builtin_ia32_gatherpfdpd (mask, (__v8si) index, (long long const *) addr, + scale, hint); +} + +extern __inline void +__attribute__ ((__gnu_inline__, __always_inline__, __artificial__)) _mm512_mask_prefetch_i32gather_ps (__m512i index, __mmask16 mask, - int const *addr, int scale, int hint) + void *addr, int scale, int hint) +{ + __builtin_ia32_gatherpfdps (mask, (__v16si) index, (int const *) addr, + scale, hint); +} + +extern __inline void +__attribute__ ((__gnu_inline__, __always_inline__, __artificial__)) +_mm512_mask_prefetch_i64gather_pd (__m512i index, __mmask8 mask, + void *addr, int scale, int hint) { - __builtin_ia32_gatherpfdps (mask, (__v16si) index, addr, scale, hint); + __builtin_ia32_gatherpfqpd (mask, (__v8di) index, (long long const *) addr, + scale, hint); } extern __inline void __attribute__ ((__gnu_inline__, __always_inline__, __artificial__)) _mm512_mask_prefetch_i64gather_ps (__m512i index, __mmask8 mask, - int const *addr, int scale, int hint) + void *addr, int scale, int hint) { - __builtin_ia32_gatherpfqps (mask, (__v8di) index, addr, scale, hint); + __builtin_ia32_gatherpfqps (mask, (__v8di) index, (int const *) addr, + scale, hint); } extern __inline void __attribute__ ((__gnu_inline__, __always_inline__, __artificial__)) -_mm512_prefetch_i32scatter_ps (int const *addr, __m512i index, int scale, +_mm512_prefetch_i32scatter_pd (void *addr, __m256i index, int scale, int hint) { - __builtin_ia32_scatterpfdps ((__mmask16) 0x, (__v16si) index, addr, scale, - hint); + __builtin_ia32_scatterpfdpd ((__mmask8) 0xFF, (__v8si) index, + (long long const *)addr, scale, hint); +} + +extern __inline void +__attribute__ ((__gnu_inline__, __always_inline__, __artificial__)) +_mm512_prefetch_i32scatter_ps (void *addr, __m512i index, int scale, + int hint) +{ + __builtin_ia32_scatterpfdps ((__mmask16) 0x, (__v16si) index, (int const *) addr, + scale, hint); +} + +extern __inline void +__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
[PATCH][ARM]Add support for armv7ve into gcc
Hi all, This patch is a amendment and rebase of a previous patch: http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02365.html No new __ARM_ARCH_7VE__ is defined. Instead, __ARM_ARCH_7A__ is defined with additional extensions (e.g. __ARM_ARCH_EXT_IDIV__) when arch is set to armv7ve. This patch will add armv7ve support to gcc. Armv7ve is basically a armv7-a architecture profile with Virtualization Extensions. Additional test cases are also added. With this patch and to keep backward compatibility with old assembler, the following asm header will be generated when -march=armv7ve option is presented. .arch armv7-a .arch_extension virt .arch_extension idiv .arch_extension sec .arch_extension mp Okay for trunk? Regards, Renlin Li gcc/ChangeLog: 2014-01-27 Renlin Li renlin...@arm.com * config/arm/arm-arches.def (ARM_ARCH): Add armv7ve arch. * config/arm/arm.c (FL_FOR_ARCH7VE): New. (arm_file_start): Generate correct asm header for armv7ve. * config/arm/bpabi.h: Add multilib support for armv7ve. * config/arm/driver-arm.c: Change the architectures of cortex-a7 and cortex-a15 to armv7ve. * config/arm/t-aprofile: Add multilib support for armv7ve. * doc/invoke.texi: Docuemnt -march=armv7ve. gcc/testsuite/ChangeLog: 2014-01-27 Renlin Li renlin...@arm.com * gcc.target/arm/ftest-armv7ve-arm.c: New. * gcc.target/arm/ftest-armv7ve-thumb.c: New. * lib/target-supports.exp: New armfunc, armflag and armdef for armv7ve. diff --git a/gcc/config/arm/arm-arches.def b/gcc/config/arm/arm-arches.def index ac543ee..9adb791 100644 --- a/gcc/config/arm/arm-arches.def +++ b/gcc/config/arm/arm-arches.def @@ -50,6 +50,7 @@ ARM_ARCH(armv6-m, cortexm1, 6M, FL_FOR_ARCH6M) ARM_ARCH(armv6s-m, cortexm1, 6M, FL_FOR_ARCH6M) ARM_ARCH(armv7, cortexa8, 7, FL_CO_PROC | FL_FOR_ARCH7) ARM_ARCH(armv7-a, cortexa8, 7A, FL_CO_PROC | FL_FOR_ARCH7A) +ARM_ARCH(armv7ve, cortexa8, 7A, FL_CO_PROC | FL_FOR_ARCH7VE) ARM_ARCH(armv7-r, cortexr4, 7R, FL_CO_PROC | FL_FOR_ARCH7R) ARM_ARCH(armv7-m, cortexm3, 7M, FL_CO_PROC | FL_FOR_ARCH7M) ARM_ARCH(armv7e-m, cortexm4, 7EM, FL_CO_PROC | FL_FOR_ARCH7EM) diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c index 142db45..e8f4941 100644 --- a/gcc/config/arm/arm.c +++ b/gcc/config/arm/arm.c @@ -764,11 +764,11 @@ static int thumb_call_reg_needed; #define FL_FOR_ARCH6M (FL_FOR_ARCH6 ~FL_NOTM) #define FL_FOR_ARCH7 ((FL_FOR_ARCH6T2 ~FL_NOTM) | FL_ARCH7) #define FL_FOR_ARCH7A (FL_FOR_ARCH7 | FL_NOTM | FL_ARCH6K) +#define FL_FOR_ARCH7VE (FL_FOR_ARCH7A | FL_THUMB_DIV | FL_ARM_DIV) #define FL_FOR_ARCH7R (FL_FOR_ARCH7A | FL_THUMB_DIV) #define FL_FOR_ARCH7M (FL_FOR_ARCH7 | FL_THUMB_DIV) #define FL_FOR_ARCH7EM (FL_FOR_ARCH7M | FL_ARCH7EM) -#define FL_FOR_ARCH8A (FL_FOR_ARCH7 | FL_ARCH6K | FL_ARCH8 | FL_THUMB_DIV \ - | FL_ARM_DIV | FL_NOTM) +#define FL_FOR_ARCH8A (FL_FOR_ARCH7VE | FL_ARCH8) /* The bits in this mask specify which instructions we are allowed to generate. */ @@ -27849,20 +27849,34 @@ arm_file_start (void) const char *fpu_name; if (arm_selected_arch) { - const char* pos = strchr (arm_selected_arch-name, '+'); - if (pos) + /* armv7ve doesn't support any extensions. */ + if (strcmp (arm_selected_arch-name, armv7ve) == 0) { - char buf[15]; - gcc_assert (strlen (arm_selected_arch-name) - = sizeof (buf) / sizeof (*pos)); - strncpy (buf, arm_selected_arch-name, - (pos - arm_selected_arch-name) * sizeof (*pos)); - buf[pos - arm_selected_arch-name] = '\0'; - asm_fprintf (asm_out_file, \t.arch %s\n, buf); - asm_fprintf (asm_out_file, \t.arch_extension %s\n, pos + 1); + /* Keep backward compatability for assemblers + which don't support armv7ve. */ + asm_fprintf (asm_out_file, \t.arch armv7-a\n); + asm_fprintf (asm_out_file, \t.arch_extension virt\n); + asm_fprintf (asm_out_file, \t.arch_extension idiv\n); + asm_fprintf (asm_out_file, \t.arch_extension sec\n); + asm_fprintf (asm_out_file, \t.arch_extension mp\n); } else - asm_fprintf (asm_out_file, \t.arch %s\n, arm_selected_arch-name); + { + const char* pos = strchr (arm_selected_arch-name, '+'); + if (pos) + { + char buf[15]; + gcc_assert (strlen (arm_selected_arch-name) + = sizeof (buf) / sizeof (*pos)); + strncpy (buf, arm_selected_arch-name, +(pos - arm_selected_arch-name) * sizeof (*pos)); + buf[pos - arm_selected_arch-name] = '\0'; + asm_fprintf (asm_out_file, \t.arch %s\n, buf); + asm_fprintf (asm_out_file, \t.arch_extension %s\n, pos + 1); + } + else + asm_fprintf (asm_out_file, \t.arch %s\n, arm_selected_arch-name); + } } else if (strncmp (arm_selected_cpu-name, generic, 7) == 0) asm_fprintf (asm_out_file, \t.arch %s\n, arm_selected_cpu-name + 8); diff --git
Re: [PATCH i386 11/8] [AVX512] [2/2] Add missing packed PF gathers/scatters.
On Mon, Jan 27, 2014 at 11:09 AM, Kirill Yukhin kirill.yuk...@gmail.com wrote: (define_expand avx512pf_scatterpfmodedf [(unspec [(match_operand:avx512fmaskmode 0 register_or_constm1_operand) (mem:DF (match_par_dup 5 [(match_operand 2 vsib_address_operand) (match_operand:VI4_256_8_512 1 register_operand) (match_operand:SI 3 const1248_operand)])) (match_operand:SI 4 const_0_to_1_operand)] UNSPEC_SCATTER_PREFETCH)] We have this correspondence between, say, main and index modes: SF - (V16SI, V8DI) DF - (V8SI , V8DI) It looks to me that you should use V16SF and V8DF instead of SF and DF modes here. I didn't find existing attributes with necessary mapping, so I invented new. Other than this, the patch looks OK to me. Please wait a day if Jakub has any remark here. Patch in the bottom and I'll check it in this evening (MS time) if no objections. (will update ChangeLog adding new mode attributes) -- Thanks, K gcc/config/i386/avx512pfintrin.h | 113 +++-- gcc/config/i386/i386-builtin-types.def | 2 + gcc/config/i386/i386.c | 37 - gcc/config/i386/sse.md | 176 +++-- gcc/testsuite/gcc.target/i386/avx-1.c | 4 + .../gcc.target/i386/avx512pf-vgatherpf0dpd-1.c | 15 ++ .../gcc.target/i386/avx512pf-vgatherpf0qpd-1.c | 15 ++ .../gcc.target/i386/avx512pf-vgatherpf1dpd-1.c | 15 ++ .../gcc.target/i386/avx512pf-vgatherpf1qpd-1.c | 15 ++ .../gcc.target/i386/avx512pf-vscatterpf0dpd-1.c| 17 ++ .../gcc.target/i386/avx512pf-vscatterpf0qpd-1.c| 17 ++ .../gcc.target/i386/avx512pf-vscatterpf1dpd-1.c| 17 ++ .../gcc.target/i386/avx512pf-vscatterpf1qpd-1.c| 17 ++ gcc/testsuite/gcc.target/i386/sse-14.c | 4 + gcc/testsuite/gcc.target/i386/sse-22.c | 5 + gcc/testsuite/gcc.target/i386/sse-23.c | 4 + 16 files changed, 442 insertions(+), 31 deletions(-) -(define_expand avx512pf_gatherpfmode +;; Packed float variants +(define_mode_attr GATHER_SCATTER_SF_MEM_MODE + [(V8DI V8SF) (V16SI V16SF)]) +(define_mode_attr GATHER_SCATTER_DF_MEM_MODE + [(V8DI V8DF) (V8SI V8DF)]) You actually don't need this attribute, since it always declares V8DF. Just use V8DF mode in the patterns instead. (no need to repost the patch due to this trivial removal). Uros.
Re: [PATCH] [GOMP4] OpenACC 1.0+ support in fortran front-end
Hi, Thomas! Thank you for your review. I agree with all your notes. I'm going to reuse your implementation of data clauses, add minimal GIMPLE infrastructure, and then resend patches. -- Ilmir.
Re: [RFC][gomp4] Offloading patches (1/3): Add '-fopenmp_target' option
On 01/22/2014 11:53 AM, Andrey Turetskiy wrote: We have some testcases, but they require XeonPhi hardware and a working libgomp plugin. Our current version of the plugin depends on some libraries, that are not open-sourced yet, so currently we can’t share it. However, you could examine what these patches do, making the following steps: 1) Build GCC with patches: http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01484.html http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01485.html http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01486.html http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01896.html 2) Set environment variables (e.g. for two ‘targets’): export OFFLOAD_TARGET_NAMES=mic:hsail (for now names don’t really matter) export OFFLOAD_TARGET_COMPILERS=./gcc:./gcc(use GCC with patches above as target compiler, because it must support the -fopenmp_target option) 3) Build any example with #pragma omp target (e.g. see attachment): ./gcc -flto -fopenmp test.c -o test.exe Options -flto and -fopenmp are necessary for using. Now you have a binary with target images embedded and tables properly filled. You can’t run it due to reasons mentioned above, though you could examine it with objdump/nm/readelf to see new sections and their content: there will be .offload_image_section with ‘target’ code and .offload_func_table_section with ‘target’ function table. I played around with this for a while last week. To have a slightly more realistic scenario where the offload compiler is for a different target, I built an aarch64-linux compiler and used that in OFFLOAD_TARGET_COMPILERS. This exposed some problems. + /* Run gcc for target. */ + obstack_init (argv_obstack); + obstack_ptr_grow (argv_obstack, compiler); + obstack_ptr_grow (argv_obstack, -shared); + obstack_ptr_grow (argv_obstack, -fPIC); + obstack_ptr_grow (argv_obstack, -xlto); + obstack_ptr_grow (argv_obstack, -fopenmp_target); + obstack_ptr_grow (argv_obstack, -o); + obstack_ptr_grow (argv_obstack, target_image_file_name); Since environment variables such as GCC_EXEC_PREFIX and COMPILER_PATH are set at this point, the compiler we're running here won't find the correct lto1 - best case it doesn't find anything, worst case it finds the lto1 for the host compiler and produces an image for the host, not the target (this fails with an arm compiler since the host assembler doesn't understand -meabi=5, but it could silently do the wrong thing with other offload toolchains). Once I worked around this by unsetting the environment variables around this compiler invocation here, the next problem is exposed - the code tries to link together files compiled for the target (created by the code quoted above) and the host (the _omp_descr file, I believe). Linker errors ensue. As mentioned before, I think all this target-specific code has no place in lto-wrapper to begin with. For ptx, we're going to require some quite different mechanisms, so I think it might be best to invoke a new tool, maybe called $target-gen-offload, which knows how to produce an image that can be linked into the host executable. Different offload targets can then use different strategies to produce such an image. Probably each such image should contain its own code to register itself with libgomp, so that we don't have to construct a table. Some other observations: * is OFFLOAD_TARGET_NAMES actually useful, or would any string generated at link time suffice? * Is the user expected to set OFFLOAD_TARGET_COMPILERS, or should this be done by the gcc driver, possibly based on command line options (I'd much prefer that)? * Do we actually need an -fopenmp-target option? The way I imagine it (and which was somewhat present in the Makefile patches I posted last year) is that an offload compiler is specially configured to know that that's how it will be used, and to know what the host architecture is. A $target-gen-offload could then be built with knowledge of the host architecture and installed in the host compiler's libexec install directory. I think I'll need to implement my own set of mechanisms for ptx, since this code doesn't seem suitable for inclusion in its current state. I'll try to take on board some of the ideas I've found here in the hope that we'll converge on something that works for everybody. Bernd
libstdc++ PATCH for c++/41174, c++/59224, Core DR 475
DR 475 clarified that uncaught_exception shouldn't return true until we are done creating the exception object and enter the unwinder: http://open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#475 Fixed by moving the adjustment of the uncaughtExceptions count from the allocation to the throw. Tested x86_64-pc-linux-gnu, applying to trunk and 4.8. commit 97c1a72915840d1d466c228f0bcb13ee8e006acc Author: Jason Merrill ja...@redhat.com Date: Fri Jan 24 13:52:44 2014 -0500 Core DR 475 PR c++/41174 PR c++/59224 * libsupc++/eh_throw.cc (__cxa_throw): Set uncaughtExceptions. * libsupc++/eh_alloc.cc (__cxa_allocate_dependent_exception) (__cxa_allocate_exception): Don't set it here. diff --git a/gcc/testsuite/g++.dg/eh/uncaught1.C b/gcc/testsuite/g++.dg/eh/uncaught1.C index afbf5af4..e96af33 100644 --- a/gcc/testsuite/g++.dg/eh/uncaught1.C +++ b/gcc/testsuite/g++.dg/eh/uncaught1.C @@ -13,7 +13,7 @@ struct Check { static Check const data[] = { { 0, 0, false }, // construct [0] - { 1, 0, true }, // [1] = [0] + { 1, 0, false }, // [1] = [0] { 0, 0, true }, // destruct [0] { 2, 1, true }, // [2] = [1] { 2, 2, true }, // destruct [2] diff --git a/gcc/testsuite/g++.dg/eh/uncaught4.C b/gcc/testsuite/g++.dg/eh/uncaught4.C new file mode 100644 index 000..227d11b --- /dev/null +++ b/gcc/testsuite/g++.dg/eh/uncaught4.C @@ -0,0 +1,29 @@ +// PR c++/41174 +// { dg-do run } + +#include exception + +#define assert(E) if (!(E)) __builtin_abort(); + +struct e { + e() + { +assert( !std::uncaught_exception() ); +try { + throw 1; +} catch (int i) { + assert( !std::uncaught_exception() ); + throw; +} + } +}; + +int main() +{ + try { +throw e(); + } catch (int i) { +assert( !std::uncaught_exception() ); + } + assert( !std::uncaught_exception() ); +} diff --git a/libstdc++-v3/libsupc++/eh_alloc.cc b/libstdc++-v3/libsupc++/eh_alloc.cc index 01eed97..752f5db 100644 --- a/libstdc++-v3/libsupc++/eh_alloc.cc +++ b/libstdc++-v3/libsupc++/eh_alloc.cc @@ -129,12 +129,6 @@ __cxxabiv1::__cxa_allocate_exception(std::size_t thrown_size) _GLIBCXX_NOTHROW std::terminate (); } - // We have an uncaught exception as soon as we allocate memory. This - // yields uncaught_exception() true during the copy-constructor that - // initializes the exception object. See Issue 475. - __cxa_eh_globals *globals = __cxa_get_globals (); - globals-uncaughtExceptions += 1; - memset (ret, 0, sizeof (__cxa_refcounted_exception)); return (void *)((char *)ret + sizeof (__cxa_refcounted_exception)); @@ -191,12 +185,6 @@ __cxxabiv1::__cxa_allocate_dependent_exception() _GLIBCXX_NOTHROW std::terminate (); } - // We have an uncaught exception as soon as we allocate memory. This - // yields uncaught_exception() true during the copy-constructor that - // initializes the exception object. See Issue 475. - __cxa_eh_globals *globals = __cxa_get_globals (); - globals-uncaughtExceptions += 1; - memset (ret, 0, sizeof (__cxa_dependent_exception)); return ret; diff --git a/libstdc++-v3/libsupc++/eh_throw.cc b/libstdc++-v3/libsupc++/eh_throw.cc index ffd28d8..e9a34e2 100644 --- a/libstdc++-v3/libsupc++/eh_throw.cc +++ b/libstdc++-v3/libsupc++/eh_throw.cc @@ -62,6 +62,9 @@ __cxxabiv1::__cxa_throw (void *obj, std::type_info *tinfo, { PROBE2 (throw, obj, tinfo); + __cxa_eh_globals *globals = __cxa_get_globals (); + globals-uncaughtExceptions += 1; + // Definitely a primary. __cxa_refcounted_exception *header = __get_refcounted_exception_header_from_obj (obj);
C vs. C++ breakage on 4.7 (was Re: [Patch, fortran] PR58007: unresolved fixup hell)
On Mon, 27 Jan 2014, Mikael Morin wrote: Le 27/01/2014 02:56, Hans-Peter Nilsson a écrit : On Sun, 26 Jan 2014, Mikael Morin wrote: Le 18/01/2014 21:17, Mikael Morin a écrit : Well, I guess that due to the touchy nature of the bug, there are cases that work by luck on old versions and fail (by unluck) on newer ones. Thus, I will backport in a few days to 4.8 and 4.7. I added the following hardening to the patch on the 4.8 backport (http://gcc.gnu.org/r207117 and attached) and forward-ported it to trunk (http://gcc.gnu.org/r207118) as well. 4.7 will come in an hour or so. Did you bootstrap test the 4.7 backport? Yes, works like a charm here. Huh, so we have C for cross-builds and C++ for bootstraps. I wish we could retire that difference *also* on the 4.7 branch (using either C *or* C++ for *both* would be fine with me FWIW). I believe we're now eperiencing more problems than benefits with that difference, now that the migration is over. Looks like you committed C++ code there, in module.c: Alright; can you try the attached patch? Sorry, not at the moment, but I see Janus took care of that (thanks) and it looks pretty obvious to me. It'll be noticed when it's committed... brgds, H-P
Re: [PATCH] [GOMP4] OpenACC 1.0+ support in fortran front-end
Hi! On Mon, 27 Jan 2014 17:12:04 +0400, Ilmir Usmanov i.usma...@samsung.com wrote: Thank you for your review. You're welcome. Hopefully the merge from trunk into gomp-4_0-branch that I just committed doesn't cause you additional work -- but as I told in my other email, there were no conflicts visible, so I hope that'll be an easy update. Otherwise, I'm happy to assist. I agree with all your notes. I'm going to reuse your implementation of data clauses, add minimal GIMPLE infrastructure, and then resend patches. Likewise, if you have any comments on my patch series for »initial support for OpenACC data clauses«, I'd like to hear them. And otherwise, as you state that you'd base your work on this, it probably makes sense if I commit my patches soon? (I now also have to rebase my patches onto the updated gomp-4_0-branch.) Grüße, Thomas pgpPzeUtDwQM9.pgp Description: PGP signature
[gomp4] Merge trunk r206958 (was: gomp-4_0-branch)
Hi! On Fri, 24 Jan 2014 18:24:56 +0100, I wrote: Jakub suggested (and I agree) the first thing to be done on gomp-4_0-branch is a merge from trunk, which he hasn't done for a long time. I have prepared this yesterday morning, and have it ready for commit, but... In r207132, I have now committed a merge of trunk r206958 (2014-01-23). Compared to a pristine trunk r206958 build, there is one regression: FAIL: g++.dg/gomp/declare-simd-1.C -std=c++98 (internal compiler error) FAIL: g++.dg/gomp/declare-simd-1.C -std=c++11 (internal compiler error) [...]/build/gcc/testsuite/g++/../../xg++ -B[...]/build/gcc/testsuite/g++/../../ [...]/source/gcc/testsuite/g++.dg/gomp/declare-simd-1.C -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ -I[...]/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I[...]/build/x86_64-unknown-linux-gnu/libstdc++-v3/include -I[...]/source/libstdc++-v3/libsupc++ -I[...]/source/libstdc++-v3/include/backward -I[...]/source/libstdc++-v3/testsuite/util -fmessage-length=0 -std=c++98 -fopenmp -S -o declare-simd-1.s [...]/source/gcc/testsuite/g++.dg/gomp/declare-simd-1.C:243:1: internal compiler error: in estimate_function_body_sizes, at ipa-inline-analysis.c:2403 0xa19664 estimate_function_body_sizes ../../source/gcc/ipa-inline-analysis.c:2403 0xa19ef1 compute_inline_parameters(cgraph_node*, bool) ../../source/gcc/ipa-inline-analysis.c:2797 0xa1a200 inline_analyze_function ../../source/gcc/ipa-inline-analysis.c:3790 0x865a10 cgraph_call_function_insertion_hooks(cgraph_node*) ../../source/gcc/cgraph.c:405 0xacc652 simd_clone_create ../../source/gcc/omp-low.c:11600 0xacc652 expand_simd_clones ../../source/gcc/omp-low.c:12370 0xacc652 ipa_omp_simd_clone ../../source/gcc/omp-low.c:12410 0xacc652 execute ../../source/gcc/omp-low.c:12443 In my understanding, the only gomp-4_0-branch-specific change that is a candidate to cause this is r205214 (Ilya Tocar, commited by Kirill Yukhin) for LTO streaming. As I couldn't easily tell what's wrong (all changes from r205214 are still present; there were no obvious conflicts), could you guys please have a look at that one? ..., now Samsung have posted, http://news.gmane.org/find-root.php?message_id=%3C52E158EF.9050009%40samsung.com%3E, patches for OpenACC support for Fortran, which likely will be conflicting with the trunk merge The good news is that the merge in fact doesn't cause any conflicts (that is, when applying that patch series on top of the new r207132) -- but I have not built and tested it. Grüße, Thomas pgpc1lcTW0twN.pgp Description: PGP signature
Re: [ARM] fix big.LITTLE spec rewriting
On 21/01/14 10:52, James Greenhalgh wrote: + names passed from the commend line will be in ARGV, we want s/commend/command. Otherwise OK if no regressions. Thanks, Ramana
Re: patch to fix PR59915
Vladimir Makarov wrote: The following patch fixes http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59915 The patch was successfully bootstrapped and tested on x86/x86-64 and ppc64 (with -mlra). Committed as rev. 207007. 2014-01-23 Vladimir Makarov vmaka...@redhat.com PR regression/59915 * lra-constraints.c (simplify_operand_subreg): Spill pseudo if there is a danger of looping. Hi Vladimir, Thanks for the fix. This fixes some of the regressions in the C-testsuite. However I'm seeing similar fails in the fortran testsuite that I didn't include in the original bug report(sorry!). I've raised http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59959. It would be great if you could have a look. Thanks, Tejas.
Re: configure check for flex
On Sun, Jan 26, 2014 at 9:38 PM, Hans-Peter Nilsson h...@bitrange.com wrote: On Sun, 8 Dec 2013, Bruce Korb wrote: On 12/08/13 13:06, Gerald Pfeifer wrote: Lovely. Thank you very much! (Looks like nobody replied to this and it isn't committed.) No, flex isn't required to build GCC as a hard and fast rule. It's not required for releases, just when building from a svn checkout (or really: when the flex-generated files are not in the source directory). You'd need some additional conditions. There might be the additional issue that any lex is expected to work too, not just flex. It isn't committed 'cuz nobody said, Okay. I do wish either someone would say, Okay. or come up with something that works. I went to the effort to figure out where things got off the rails and did something that worked for me. Just saying, That won't work without a workable alternative is a bit irritating. I do not know the difference between a checkout build and a normal configured build. My understanding was that generated files were to be part of the repo and that there was *not* a difference. If there is, then someone who understands the difference could maybe add some configure infrastructure to test the environment and decide if flex (or lex) was needed, rather than just say, what you did won't work.
[Ada] Only functions can have Ghost convention
This implements the rule in SPARK RM 6.1.6 which specifies that only functions may have convention Ghost explicitly specified. This test program shows error messages not previously given (compiled with -gnatc -gnatj60) 1. package Ghost_Illegal_1 2. with SPARK_Mode 3. is 4.-- TU: 6.1.6 LR 5.-- Only functions can be explicitly 6.-- declared with Convention = Ghost. 7. 8.Ghost_Var : Integer | Ghost_Var may not have Ghost convention, only functions are permitted to have Ghost convention 9. with Convention = Ghost; 10. 11.X : exception | X may not have Ghost convention, only functions are permitted to have Ghost convention 12. with Convention = Ghost; 13. 14.procedure Ghost_Proc | Ghost_Proc may not have Ghost convention, only functions are permitted to have Ghost convention 15. with Convention = Ghost; 16. 17.function Ghost_Func return Boolean 18. with Convention = Ghost; 19. end Ghost_Illegal_1; Tested on x86_64-pc-linux-gnu, committed on trunk 2014-01-27 Robert Dewar de...@adacore.com * sem_prag.adb (Set_Convention_From_Pragma): Check that convention Ghost can only apply to functions. * einfo.ads, einfo.adb (Is_Ghost_Subprogram): Add clarifying comment. Index: einfo.ads === --- einfo.ads (revision 207120) +++ einfo.ads (working copy) @@ -2343,11 +2343,15 @@ --Is_Ghost_Entity (synthesized) -- Applies to all entities. Yields True for a subprogram or a whole --- object that has convention Ghost. +-- object that has convention Ghost. For now only functions can have +-- Ghost convention, so this will be false for other than functions, +-- but we expect that to change in the future. --Is_Ghost_Subprogram (synthesized) -- Applies to all entities. Yields True for a subprogram that has a Ghost --- convention. +-- convention. Note: for now, only ghost functions are allowed, so this +-- will always be false for procedures, but that is expected to change in +-- the future. --Is_Hidden (Flag57) -- Defined in all entities. Set for all entities declared in the Index: einfo.adb === --- einfo.adb (revision 207120) +++ einfo.adb (working copy) @@ -6886,6 +6886,10 @@ -- Is_Ghost_Entity -- - + -- Note: coding below allows for ghost variables. They are not currently + -- implemented, so we will always get False for variables, but that is + -- expected to change in the future. + function Is_Ghost_Entity (Id : E) return B is begin if Present (Id) and then Ekind (Id) = E_Variable then Index: sem_prag.adb === --- sem_prag.adb(revision 207134) +++ sem_prag.adb(working copy) @@ -6029,7 +6029,8 @@ -- Set convention in entity E, and also flag that the entity has a -- convention pragma. If entity is for a private or incomplete type, -- also set convention and flag on underlying type. This procedure - -- also deals with the special case of C_Pass_By_Copy convention. + -- also deals with the special case of C_Pass_By_Copy convention, + -- and error checks for inappropriate convention specification. --- -- Diagnose_Multiple_Pragmas -- @@ -6191,6 +6192,16 @@ procedure Set_Convention_From_Pragma (E : Entity_Id) is begin +-- Ghost convention is allowed only for functions + +if Ekind (E) /= E_Function and then C = Convention_Ghost then + Error_Msg_N + ( may not have Ghost convention, E); + Error_Msg_N + (\only functions are permitted to have Ghost convention, E); + return; +end if; + -- Ada 2005 (AI-430): Check invalid attempt to change convention -- for an overridden dispatching operation. Technically this is -- an amendment and should only be done in Ada 2005 mode. However, @@ -6201,11 +6212,11 @@ and then Present (Overridden_Operation (E)) and then C /= Convention (Overridden_Operation (E)) then - -- An attempt to override a subprogram with a ghost subprogram + -- An attempt to override a function with a ghost function -- appears as a mismatch in conventions. if C = Convention_Ghost then - Error_Msg_N (ghost subprogram cannot be overriding, E); + Error_Msg_N (ghost function cannot
[C++ Patch] PR 51219
Hi, as explained by Richard in the audit trail of the duplicate c++/54808, the problem here is that the type checking code notices that we are initializing the unnamed bit-field with a bare integer_zero_node. Calling here too cp_convert_and_check works. Tested x86_64-linux (probably not worth backporting because, as explained, can only happen with checking enabled) Thanks, Paolo. /// /cp 2014-01-27 PR c++/51219 * typeck2.c (process_init_constructor_record): Use cp_convert_and_check for unnamed bit-fields. /testsuite 2014-01-27 PR c++/51219 * g++.dg/init/bitfield5.C: New. Index: cp/typeck2.c === --- cp/typeck2.c(revision 207127) +++ cp/typeck2.c(working copy) @@ -1269,8 +1269,10 @@ process_init_constructor_record (tree type, tree i if (!DECL_NAME (field) DECL_C_BIT_FIELD (field)) { - flags |= picflag_from_initializer (integer_zero_node); - CONSTRUCTOR_APPEND_ELT (v, field, integer_zero_node); + next = cp_convert_and_check (TREE_TYPE (field), integer_zero_node, + complain); + flags |= picflag_from_initializer (next); + CONSTRUCTOR_APPEND_ELT (v, field, next); continue; } Index: testsuite/g++.dg/init/bitfield5.C === --- testsuite/g++.dg/init/bitfield5.C (revision 0) +++ testsuite/g++.dg/init/bitfield5.C (working copy) @@ -0,0 +1,12 @@ +// PR c++/51219 + +struct A +{ + int i; + int : 8; +}; + +void foo() +{ + A a = { 0 }; +}
[PATCH] Fix bootstrap/59934
As discussed in the PR, when a port does not have partial integer or vector integer modes, expmed_mode_index will not be called with those modes. However, our VRP analysis isn't aware of those constraints and has to assume the MODE_PARTIAL_INT and MODE_VECTOR_INT cases could be used. That in turn can cause a false positive array index out of range warning, which is causing the s390 and PA ports to fail to bootstrap. This patch almost restores the s390x bootstrap -- it's currently failing building libjava in stage3. [ ... ] from ../../../../../../gcc/libjava/classpath/tools/sun/rmi/rmic/Main.java:58, from built-in:3: ../../../../../../gcc/libjava/classpath/tools/external/asm/org/objectweb/asm/util/TraceMethodVisitor.java:286:0: note: non-delegitimized UNSPEC UNSPEC_PLTOFF (12) found in variable location gcj: internal compiler error: Segmentation fault (program jc1) 0x80010353 execute ../../gcc/gcc/gcc.c:2841 0x8001060d do_spec_1 ../../gcc/gcc/gcc.c:4641 0x8001394d process_brace_body ../../gcc/gcc/gcc.c:5924 0x8001394d handle_braces ../../gcc/gcc/gcc.c:5838 [ ... ] Regardless, this patch from Jakub is clearly a step forward and I believe it's highly unlikely to be the root cause of this stage3 error. I also bootstrapped and regression tested the patch on x86-64-unknown-linux-gnu. Installed on the trunk. Andreas -- if you could help with debugging the stage3 libjava compilation failure, it'd be greatly appreciated. Thanks, Jeff diff --git a/gcc/ChangeLog b/gcc/ChangeLog index 8405b2e..95a324c 100644 --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@ -1,3 +1,10 @@ +2014-01-27 Jakub Jelinek ja...@redhat.com + + PR bootstrap/59934 + * expmed.h (expmed_mode_index): Rework so that analysis and optimziers + know when the MODE_PARTIAL_INT and MODE_VECTOR_INT cases can never be + reached. + 2014-01-27 James Greenhalgh james.greenha...@arm.com * common/config/arm/arm-common.c diff --git a/gcc/expmed.h b/gcc/expmed.h index 9681e41..4d01d1f 100644 --- a/gcc/expmed.h +++ b/gcc/expmed.h @@ -221,12 +221,21 @@ expmed_mode_index (enum machine_mode mode) case MODE_INT: return mode - MIN_MODE_INT; case MODE_PARTIAL_INT: - return mode - MIN_MODE_PARTIAL_INT + NUM_MODE_INT; + /* If there are no partial integer modes, help the compiler +to figure out this will never happen. See PR59934. */ + if (MIN_MODE_PARTIAL_INT != VOIDmode) + return mode - MIN_MODE_PARTIAL_INT + NUM_MODE_INT; + break; case MODE_VECTOR_INT: - return mode - MIN_MODE_VECTOR_INT + NUM_MODE_IP_INT; + /* If there are no vector integer modes, help the compiler +to figure out this will never happen. See PR59934. */ + if (MIN_MODE_VECTOR_INT != VOIDmode) + return mode - MIN_MODE_VECTOR_INT + NUM_MODE_IP_INT; + break; default: - gcc_unreachable (); + break; } + gcc_unreachable (); } /* Return a pointer to a boolean contained in EOC indicating whether