Re: [PATCH] [GOMP4] OpenACC 1.0+ support in fortran front-end

2014-01-27 Thread Ilmir Usmanov

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

2014-01-27 Thread Arnaud Charlet
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

2014-01-27 Thread Arnaud Charlet
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

2014-01-27 Thread Arnaud Charlet
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

2014-01-27 Thread Arnaud Charlet
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

2014-01-27 Thread Arnaud Charlet
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).

2014-01-27 Thread Arnaud Charlet
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

2014-01-27 Thread Ramana Radhakrishnan
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)

2014-01-27 Thread Jakub Jelinek
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)

2014-01-27 Thread Richard Biener
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

2014-01-27 Thread Jonathan Wakely

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

2014-01-27 Thread Marcus Shawcroft
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

2014-01-27 Thread Xinliang David Li
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

2014-01-27 Thread David Malcolm
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

2014-01-27 Thread Jeff Law


[ 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

2014-01-27 Thread David Malcolm
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

2014-01-27 Thread Kai Tietz
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

2014-01-27 Thread Tobias Burnus

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

2014-01-27 Thread Jonathan Wakely

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

2014-01-27 Thread H.J. Lu
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

2014-01-27 Thread Jonathan Wakely

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

2014-01-27 Thread Paolo Carlini
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

2014-01-27 Thread Jonathan Wakely
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++

2014-01-27 Thread Iyer, Balaji V
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++

2014-01-27 Thread Jakub Jelinek
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

2014-01-27 Thread Jeff Law


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

2014-01-27 Thread Ian Lance Taylor
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

2014-01-27 Thread David Malcolm
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

2014-01-27 Thread Mikael Morin
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++

2014-01-27 Thread Iyer, Balaji V
 -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

2014-01-27 Thread Fabien Chêne
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

2014-01-27 Thread Jeff Law

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

2014-01-27 Thread François Dumont
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

2014-01-27 Thread Jakub Jelinek
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

2014-01-27 Thread Jakub Jelinek
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

2014-01-27 Thread H.J. Lu
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

2014-01-27 Thread Steve Ellcey

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

2014-01-27 Thread Uros Bizjak
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

2014-01-27 Thread Jonathan Wakely
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

2014-01-27 Thread Jan Hubicka
 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

2014-01-27 Thread Sriraman Tallam
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

2014-01-27 Thread Xinliang David Li
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

2014-01-27 Thread Hans-Peter Nilsson
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)

2014-01-27 Thread Hans-Peter Nilsson
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

2014-01-27 Thread Zhenqiang Chen
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)

2014-01-27 Thread Jason Merrill
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)

2014-01-27 Thread Jason Merrill
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)

2014-01-27 Thread Jason Merrill
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)

2014-01-27 Thread Jason Merrill
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)

2014-01-27 Thread Jason Merrill
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)

2014-01-27 Thread Jason Merrill
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)

2014-01-27 Thread Jason Merrill
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)

2014-01-27 Thread Jason Merrill
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

2014-01-27 Thread Jason Merrill
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

2014-01-27 Thread Jason Merrill

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)

2014-01-27 Thread Yury Gribov



 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

2014-01-27 Thread Jakub Jelinek
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

2014-01-27 Thread Alan Modra
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

2014-01-27 Thread Mikael Morin
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

2014-01-27 Thread Janus Weil
 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

2014-01-27 Thread Uros Bizjak
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

2014-01-27 Thread James Greenhalgh

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

2014-01-27 Thread James Greenhalgh

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.

2014-01-27 Thread Kirill Yukhin
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

2014-01-27 Thread Renlin Li

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.

2014-01-27 Thread Uros Bizjak
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

2014-01-27 Thread Ilmir Usmanov

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

2014-01-27 Thread Bernd Schmidt

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

2014-01-27 Thread Jason Merrill
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)

2014-01-27 Thread Hans-Peter Nilsson
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

2014-01-27 Thread Thomas Schwinge
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)

2014-01-27 Thread Thomas Schwinge
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

2014-01-27 Thread Ramana Radhakrishnan

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

2014-01-27 Thread Tejas Belagod

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

2014-01-27 Thread Bruce Korb
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

2014-01-27 Thread Arnaud Charlet
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

2014-01-27 Thread Paolo Carlini

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

2014-01-27 Thread Jeff Law


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