Re: [patch, libgfortran] PR55818 Reading a REAL from a file which doesn't end in a new line fails

[Tobias Burnus]

Jerry DeLisle wrote:
This updated patch addresses the issues with infinities, nans, 
characters, and valid reals.

And complex.


OK for trunk?
Test case attached.


Thanks for the patch. It looks okay (with a ChangeLog).

However, I found yet another case which is not handled, namely reals 
with exponentials such as "1.0e3". Hopefully, we have then covered all 
cases.



open(99, file="test.dat", access="stream", form="unformatted", status="new")
write(99) "1.0e3"
close(99)
!or: stream
open(99, file="test.dat",access="sequential", form="formatted", 
status="old")

read (99,*, iostat=stat) var
if (stat /= 0 .or. var /= 1000) call abort()
close(99)


Tobias

[Ada] gnatmake -s -fstack-check

[Arnaud Charlet]

As -fstack-check is an alias for -fstack-check=specific and the longer
switch is now recorded in the ALI file, this patch make sure that when
-fstack-check is used, gnatmake -s will no longer recompiles all the
sources.
The test for this is to invoke several time gnatmake -s -fstack-check on
the same sources without modification of the sources. There should be no
compilation starting with the second invocation.

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

2013-01-02  Vincent Celier  

* switch-m.adb (Normalize_Compiler_Switches): Record the
complete switch -fstack-check=specific instead of its shorter
alias -fstack-check.

Index: switch-m.adb
===
--- switch-m.adb(revision 194776)
+++ switch-m.adb(working copy)
@@ -214,6 +214,12 @@
then
   Add_Switch_Component (Switch_Chars);
 
+   --  Special case for -fstack-check (alias for
+   --  -fstack-check=specific)
+
+   elsif Switch_Chars = "-fstack-check" then
+  Add_Switch_Component ("-fstack-check=specific");
+
--  Take only into account switches that are transmitted to
--  gnat1 by the gcc driver and stored by gnat1 in the ALI file.
 

[Ada] Convention for operations of generlc formals with unknown discriminants

[Arnaud Charlet]

RM 6.3.1 (8) specifies that the operations inherited by a generic formal
tagged derived type with unknown discriminants have convention Intrinsic.
As a consequence, attribute 'Access cannot be applied to suvh an operation.

This rule also makes it impossible to override an inherited operation of a
type derived from such a formal type (a not uncommon usage), so in fact it
probably needs to be relaxed. The straightforward solution adopted here is to
say that the primitives of a type derived from such a formal type take their
convention from the primitive operation of the ultimate non-generic ancestor.

Compiling no_access.adb in ada 2005 mode  must be rejected with the message:

no_access.adb:22:12: prefix of "Access" attribute cannot be intrinsic

---
procedure No_Access is
  package P is
 type Root is tagged null record;
 procedure Proc (X : Root);
  end P;

  package body P is
 procedure Proc (X : Root) is begin null; end; 
  end P;

  generic
 type Formal (<>) is new P.Root with private;
 Value : Formal;
  package G is
 procedure Rien;
  end G;

  package body G is
 procedure Rien is
 begin
--  attribute reference is illegal because inherited Proc is intrinsic
if Proc'access = null then null; end if;
 end;

 Thing : Formal := Value;

  begin
 Proc (Thing);
  end G;

begin
  null;
end;
---

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

2013-01-02  Ed Schonberg  

* sem_ch3.adb (Derive_Subprogram): Enforce RM 6.3.1 (8):
if the derived type is a tagged generic formal type with
unknown discriminants, the inherited operation has convention
Intrinsic. As such, the 'Access attribute cannot be applied to it.

Index: sem_ch3.adb
===
--- sem_ch3.adb (revision 194776)
+++ sem_ch3.adb (working copy)
@@ -13320,8 +13320,29 @@
   --  of the parent subprogram (a requirement of AI-117). Derived
   --  subprograms of untagged types simply get convention Ada by default.
 
+  --  If the derived type is a tagged generic formal type with unknown
+  --  discriminants, its convention is intrinsic (RM 6.3.1 (8)).
+
+  --  However, if the type is derived from a generic formal, the further
+  --  inherited subprogram has the convention of the non-generic ancestor.
+  --  Otherwise there would be no way to override the operation.
+  --  (This is subject to forthcoming ARG discussions).
+
   if Is_Tagged_Type (Derived_Type) then
- Set_Convention (New_Subp, Convention (Parent_Subp));
+ if Is_Generic_Type (Derived_Type)
+   and then Has_Unknown_Discriminants (Derived_Type)
+ then
+Set_Convention (New_Subp, Convention_Intrinsic);
+
+ else
+if Is_Generic_Type (Parent_Type)
+  and then Has_Unknown_Discriminants (Parent_Type)
+then
+   Set_Convention (New_Subp, Convention (Alias (Parent_Subp)));
+else
+   Set_Convention (New_Subp, Convention (Parent_Subp));
+end if;
+ end if;
   end if;
 
   --  Predefined controlled operations retain their name even if the parent
@@ -1,9 +13354,9 @@
 
   if Is_Controlled (Parent_Type)
 and then
-  (Chars (Parent_Subp) = Name_Initialize
-or else Chars (Parent_Subp) = Name_Adjust
-or else Chars (Parent_Subp) = Name_Finalize)
+  (Chars (Parent_Subp) = Name_Initialize or else
+   Chars (Parent_Subp) = Name_Adjust or else
+   Chars (Parent_Subp) = Name_Finalize)
 and then Is_Hidden (Parent_Subp)
 and then not Is_Visibly_Controlled (Parent_Type)
   then
@@ -13377,14 +13398,14 @@
   elsif Ada_Version >= Ada_2005
 and then (Is_Abstract_Subprogram (Alias (New_Subp))
or else (Is_Tagged_Type (Derived_Type)
-and then Etype (New_Subp) = Derived_Type
-and then not Is_Null_Extension (Derived_Type))
+ and then Etype (New_Subp) = Derived_Type
+ and then not Is_Null_Extension (Derived_Type))
or else (Is_Tagged_Type (Derived_Type)
-and then Ekind (Etype (New_Subp)) =
+ and then Ekind (Etype (New_Subp)) =
E_Anonymous_Access_Type
-and then Designated_Type (Etype (New_Subp)) =
-   Derived_Type
-and then not Is_Null_Extension (Derived_Type)))
+ and then Designated_Type (Etype (New_Subp)) =
+Derived_Type
+ and then not Is_Null_Extension (Derived_Type)))
 and then No (Actual_Subp)
   then
 

[Ada] Preconditions and postconditions on subprogram bodies

[Arnaud Charlet]

This patch implements properly pre- and postconditions that are given in
subprogram bodies that have no previous specification.

Executing:

   gnatmake -q -gnat12a pre_on_baas
   pre_on_baas

must yield:

before
P called
after

--
pragma Ada_2012;
pragma Check_Policy (Precondition, Check);
with Ada.Text_IO; use Ada.Text_IO;

procedure Pre_On_BaaS is

   function F (S : String)  return Boolean is
   begin
  Put_Line (S);
  return True;
   end F;

   procedure P with
  Pre => F ("before"),
  Post => F ("after")
   is
   begin
  Put_Line ("P called");
   end P;

begin
   P;
end Pre_On_BaaS;

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

2013-01-02  Ed Schonberg  

* sem_ch13.adb (Analyze_Aspect_Specifications): If the aspect
appears on a subprogram body that acts as a spec, place the
corresponding pragma in the declarations of the body, so that
e.g. pre/postcondition checks can be generated appropriately.

Index: sem_ch13.adb
===
--- sem_ch13.adb(revision 194777)
+++ sem_ch13.adb(working copy)
@@ -1606,6 +1606,17 @@
 
   if Nkind (Parent (N)) = N_Compilation_Unit then
  Add_Global_Declaration (Aitem);
+
+  --  If it is a subprogram body, add pragmas to list of
+  --  declarations in body.
+
+  elsif Nkind (N) = N_Subprogram_Body then
+ if No (Declarations (N)) then
+Set_Declarations (N, New_List);
+ end if;
+
+ Append (Aitem, Declarations (N));
+
   else
  Insert_After (N, Aitem);
   end if;

[Ada] Debug information for code generated for pragma Check

[Arnaud Charlet]

This change corrects an anomaly in the source locations produced in debug
information for code implementing a pragma Check that could cause incorrect
coverage analyses.

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

2013-01-02  Thomas Quinot  

* exp_prag.adb (Expand_Pragma_Check): The statements generated
for the pragma must have the sloc of the pragma, not the
sloc of the condition, otherwise this creates anomalies in the
generated debug information that confuse coverage analysis tools.

Index: exp_prag.adb
===
--- exp_prag.adb(revision 194781)
+++ exp_prag.adb(working copy)
@@ -274,18 +274,18 @@
--
 
procedure Expand_Pragma_Check (N : Node_Id) is
+  Loc  : constant Source_Ptr := Sloc (N);
+  --  Location of the pragma node. Note: it is important to use this
+  --  location (and not the location of the expression) for the generated
+  --  statements, otherwise the implicit return statement in the body
+  --  of a pre/postcondition subprogram may inherit the source location
+  --  of part of the expression, which causes confusing debug information
+  --  to be generated, which interferes with coverage analysis tools.
+
   Cond : constant Node_Id := Arg2 (N);
   Nam  : constant Name_Id := Chars (Arg1 (N));
   Msg  : Node_Id;
 
-  Loc  : constant Source_Ptr := Sloc (First_Node (Cond));
-  --  Source location used in the case of a failed assertion. Note that
-  --  the source location of the expression is not usually the best choice
-  --  here. For example, it gets located on the last AND keyword in a
-  --  chain of boolean expressiond AND'ed together. It is best to put the
-  --  message on the first character of the assertion, which is the effect
-  --  of the First_Node call here.
-
begin
   --  We already know that this check is enabled, because otherwise the
   --  semantic pass dealt with rewriting the assertion (see Sem_Prag)
@@ -362,7 +362,15 @@
 
  else
 declare
-   Msg_Loc : constant String := Build_Location_String (Loc);
+   Msg_Loc : constant String :=
+   Build_Location_String (Sloc (First_Node (Cond)));
+   --  Source location used in the case of a failed assertion:
+   --  point to the failing condition, not Loc. Note that the
+   --  source location of the expression is not usually the best
+   --  choice here. For example, it gets located on the last AND
+   --  keyword in a chain of boolean expressiond AND'ed together.
+   --  It is best to put the message on the first character of the
+   --  condition, which is the effect of the First_Node call here.
 
 begin
Name_Len := 0;

[Ada] A prefixed view of a subprogram has convention Intrinsic

[Arnaud Charlet]

This patch enforces the rule given in 6.3.1 (10.1/2): a prefixed view of a
subprogram is intrinsic, because the compiler has to generate a wrapper for any
call to it. If the name in a subprogram renaming is a prefixed view, the entity
is thus intrinsic, and 'Access cannot be applied to it.

Compiling the following must be rejected with:

main.adb:6:36: prefix of "Access" attribute cannot be intrinsic

---
with Some_Package;
procedure Main is
   Message: Some_Package.Message_Type;
   procedure Print renames Message.Print;  -- this has convention intrinsic,
   -- see RM 6.3.1(10.1/2)
   Method_Ref: access procedure := Print'Access;
-- thus taking 'Access should be illegal
begin
   Method_Ref.all;
end;
---
package Some_Package is
   type Message_Type is tagged null record;
   procedure Print (Message: in Message_Type);
end Some_Package;

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

2013-01-02  Ed Schonberg  

* sem_ch8.adb (Analyze_Primitive_Renamed_Operation): The prefixed
view of a subprogram has convention Intrnnsic, and a renaming
of a prefixed view cannot be the prefix of an Access attribute.

Index: sem_ch8.adb
===
--- sem_ch8.adb (revision 194776)
+++ sem_ch8.adb (working copy)
@@ -397,8 +397,10 @@
   New_S   : Entity_Id;
   Is_Body : Boolean);
--  If the renamed entity in a subprogram renaming is a primitive operation
-   --  or a class-wide operation in prefix form, save the target object, which
-   --  must be added to the list of actuals in any subsequent call.
+   --  or a class-wide operation in prefix form, save the target object,
+   --  which must be added to the list of actuals in any subsequent call.
+   --  The renaming operation is intrinsic because the compiler must in
+   --  fact generate a wrapper for it (6.3.1 (10 1/2)).
 
function Applicable_Use (Pack_Name : Node_Id) return Boolean;
--  Common code to Use_One_Package and Set_Use, to determine whether use
@@ -1602,6 +1604,10 @@
   --  match. The first formal of the renamed entity is skipped because it
   --  is the target object in any subsequent call.
 
+  --
+  -- Conforms --
+  --
+
   function Conforms
 (Subp : Entity_Id;
  Ctyp : Conformance_Type) return Boolean
@@ -1634,6 +1640,8 @@
  return True;
   end Conforms;
 
+   --  Start of processing for Analyze_Renamed_Primitive_Operation
+
begin
   if not Is_Overloaded (Selector_Name (Name (N))) then
  Old_S := Entity (Selector_Name (Name (N)));
@@ -1681,6 +1689,14 @@
 if not Conforms (Old_S, Mode_Conformant) then
Error_Msg_N ("mode conformance error in renaming", N);
 end if;
+
+--  Enforce the rule given in (RM 6.3.1 (10.1/2)): a prefixed
+--  view of a subprogram is intrinsic, because the compiler has
+--  to generate a wrapper for any call to it. If the name in a
+--  subprogram renaming is a prefixed view, the entity is thus
+--  intrinsic, and 'Access cannot be applied to it.
+
+Set_Convention (New_S, Convention_Intrinsic);
  end if;
 
  --  Inherit_Renamed_Profile (New_S, Old_S);

[Ada] Wrong evaluation order for AND THEN in Pre/Post on library subprogram

[Arnaud Charlet]

This change fixes the circuitry that processes Pre/Post aspects. Previously
when an AND THEN expression was used in such an aspect on a library level
subprogram, the operands would be evaluated in the wrong order.

Test case:

$ gnatmake -q call_p
$ ./call_p
F( 1) -> TRUE
F( 2) -> TRUE
P called
F( 1) -> TRUE
F( 2) -> FALSE
Exception name: SYSTEM.ASSERTIONS.ASSERT_FAILURE
Message: failed precondition from p.ads:2

-- gnat.adc
pragma Ada_2012;
pragma Check_Policy (Precondition, Check);

-- sources
with Ada.Exceptions;
with Ada.Text_IO; use Ada.Text_IO;

with Split_Pre_Order;
with P;

procedure Call_P is
begin
   Split_Pre_Order.Pre_Array := (1 => True, 2 => True);
   P;

   Split_Pre_Order.Pre_Array (2) := False;
   begin
  P;
   exception
  when E : others =>
 Put_Line (Ada.Exceptions.Exception_Information (E));
   end;
end Call_P;
with Ada.Text_IO; use Ada.Text_IO;
procedure P is
begin
   Put_Line ("P called");
end P;
with Split_Pre_Order;
procedure P with Pre => Split_Pre_Order.F (1) and then Split_Pre_Order.F (2);
pragma Ada_2012;
with Ada.Exceptions;
with Ada.Text_IO; use Ada.Text_IO;
pragma Check_Policy (Precondition, Check);

procedure Split_Pre_Order is
   Pre_Array : array (1 .. 2) of Boolean;

   function F (Index : Integer) return Boolean is
  Result : constant Boolean := Pre_Array (Index);
   begin
  Put_Line ("F(" & Index'Img & ") -> " & Result'Img);
  return Result;
   end F;

   procedure P with Pre => F (1) and then F (2);

   procedure P is
   begin
  Put_Line ("P called");
   end P;

begin
   Pre_Array := (1 => True, 2 => True);
   P;

   Pre_Array := (1 => True, 2 => False);
   begin
  P;
   exception
  when E : others=>
 Put_Line ("Exception raised: "
   & Ada.Exceptions.Exception_Information (E));
   end;
end Split_Pre_Order;

with Ada.Text_IO; use Ada.Text_IO;

package body Split_Pre_Order is
   function F (Index : Integer) return Boolean is
  Result : constant Boolean := Pre_Array (Index);
   begin
  Put_Line ("F(" & Index'Img & ") -> " & Result'Img);
  return Result;
   end F;
end Split_Pre_Order;
package Split_Pre_Order is
   Pre_Array : array (1 .. 2) of Boolean;
   function F (Index : Integer) return Boolean;
end Split_Pre_Order;

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

2013-01-02  Thomas Quinot  

* sem_ch13.adb (Analyze_Aspect_Specifications): For a Pre/Post
aspect that applies to a library subprogram, prepend corresponding
pragma to the Pragmas_After list, in order for split AND THEN
sections to be processed in the expected order.

Index: sem_ch13.adb
===
--- sem_ch13.adb(revision 194782)
+++ sem_ch13.adb(working copy)
@@ -1602,11 +1602,22 @@
   --  with delay of visibility for the expression analysis.
 
   --  If the entity is a library-level subprogram, the pre/
-  --  postconditions must be treated as late pragmas.
+  --  postconditions must be treated as late pragmas. Note
+  --  that they must be prepended, not appended, to the list,
+  --  so that split AND THEN sections are processed in the
+  --  correct order.
 
   if Nkind (Parent (N)) = N_Compilation_Unit then
- Add_Global_Declaration (Aitem);
+ declare
+Aux : constant Node_Id := Aux_Decls_Node (Parent (N));
+ begin
+if No (Pragmas_After (Aux)) then
+   Set_Pragmas_After (Aux, New_List);
+end if;
 
+Prepend (Aitem, Pragmas_After (Aux));
+ end;
+
   --  If it is a subprogram body, add pragmas to list of
   --  declarations in body.
 
@@ -1930,7 +1941,7 @@
 
   else
  if No (Pragmas_After (Aux)) then
-Set_Pragmas_After (Aux, Empty_List);
+Set_Pragmas_After (Aux, New_List);
  end if;
 
  Append (Aitem, Pragmas_After (Aux));

[Ada] Implement tagging of warning messages

[Arnaud Charlet]

This patch implements the -gnatw.d switch to activate tagging of warning
messages. With this switch set, warning messages will have a tag at the
end which is one of:

   [-gnatw?]   ? in a .. z
   [-gnatw.?]  ? in a .. z
   [enabled by default]

So, similar to the tags emitted by GCC for other languages.

The patch enables the general mechanism (using new insertion tags ??
and ?x?). So far only a few messages have been tagged, but eventually
we will tag as many warning messages as possible. The following source
program is compiled with -gnatj.p.d -gnatj70:

 1. function warndoc (a, b, c : integer) return integer is
 2.x : string := %abc%;
 |
>>> warning: use of "%" is an obsolescent feature (RM
J.2(4)), use """ instead [-gnatwj]

 3. begin
 4.if b > 0 then
   |
>>> warning: "return" statement missing following this
statement, Program_Error may be raised at run time
[enabled by default]

 5.   return warndoc (b, a, c);
 |
>>> warning: actuals for this call may be in wrong order
[-gnatw.p]

 6.end if;
 7. end;

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

2013-01-02  Robert Dewar  

* err_vars.ads (Warning_Doc_Switch): New flag.
* errout.adb (Error_Msg_Internal): Implement new warning flag
doc tag stuff (Set_Msg_Insertion_Warning): New procedure.
* errout.ads: Document new insertion sequences ?? ?x? ?.x?
* erroutc.adb (Output_Msg_Text): Handle ?? and ?x? warning doc
tag stuff.
* erroutc.ads (Warning_Msg_Char): New variable.
(Warn_Chr): New field in error message object.
* errutil.adb (Error_Msg): Set Warn_Chr in error message object.
* sem_ch13.adb: Minor reformatting.
* warnsw.adb: Add handling for -gnatw.d and -gnatw.D
(Warning_Doc_Switch).
* warnsw.ads: Add handling of -gnatw.d/.D switches (warning
doc tag).

Index: err_vars.ads
===
--- err_vars.ads(revision 194776)
+++ err_vars.ads(working copy)
@@ -88,6 +88,12 @@
--  Source_Reference line, then this is initialized to No_Source_File,
--  to force an initial reference to the real source file name.
 
+   Warning_Doc_Switch : Boolean := False;
+   --  If this is set True, then the ??/?x?/?.x? sequences in error messages
+   --  are active (see errout.ads for details). If this switch is False, then
+   --  these sequences are ignored (i.e. simply equivalent to a single ?). The
+   --  -gnatw.d switch sets this flag True, -gnatw.D sets this flag False.
+

-- Error Message Insertion Parameters --

@@ -133,7 +139,9 @@
--  before any call to Error_Msg_xxx with a < insertion character present.
--  Setting is irrelevant if no < insertion character is present. Note
--  that it is not necessary to reset this after using it, since the proper
-   --  procedure is always to set it before issuing such a message.
+   --  procedure is always to set it before issuing such a message. Note that
+   --  the warning documentation tag is always [enabled by default] in the
+   --  case where this flag is True.
 
Error_Msg_String : String (1 .. 4096);
Error_Msg_Strlen : Natural;
Index: sem_res.adb
===
--- sem_res.adb (revision 194776)
+++ sem_res.adb (working copy)
@@ -3095,7 +3095,7 @@
 
if Wrong_Order then
   Error_Msg_N
-("actuals for this call may be in wrong order?", N);
+("?P?actuals for this call may be in wrong order", N);
end if;
 end;
  end;
Index: warnsw.adb
===
--- warnsw.adb  (revision 194776)
+++ warnsw.adb  (working copy)
@@ -22,9 +22,9 @@
 -- Extensive contributions were provided by Ada Core Technologies Inc.  --
 --  --
 --
+with Err_Vars; use Err_Vars;
+with Opt;  use Opt;
 
-with Opt; use Opt;
-
 package body Warnsw is
 

@@ -52,6 +52,12 @@
  when 'C' =>
 Warn_On_Unrepped_Components := False;
 
+ when 'd' =>
+Warning_Doc_Switch := True;
+
+ when 'D' =>
+Warning_Doc_Switch := False;
+
  when 'e' =>
 Address_Clause_Overlay_Warnings := True;
 Check_Unreferenced  := True;
Index: errout.adb
===
--- errout.adb  (revision 194776)
++

[Ada] Implement pragma Check_Float_Overflow

[Arnaud Charlet]

On most targets, Machine_Overflows is false for built in floating-point
types, and unconstrained floating-point types like Float do not raise an
exception on overflow, instead they generate infinities or in some cases,
NaN's. Check_Float_Overflow is a configuration pragma that sets a mode in
which the result of all operators on unconstrained float values is checked
to make sure it is in the base range, and an exception is raised if not.
The switch -gnateF also sets Check_Float_Overflow mode.

The following program:

 1. with Text_IO; use Text_IO;
 2. procedure FptOV is
 3.X : Float := Float'Last;
 4.Y : Float;
 5.subtype MF is Float range Float'Range;
 6.XF : MF := MF'Last;
 7.YF : MF;
 8. begin
 9.begin
10.   YF := XF + XF;
11.exception
12.   when Constraint_Error =>
13.  Put_Line ("exception for MF");
14.end;
15.begin
16.   Y := X + X;
17.exception
18.   when Constraint_Error =>
19.  Put_Line ("exception for Float");
20.end;
21. end FptOV;

With switch -gnateF generates

exception for MF
exception for Float

without this switch, it only generates

exception for MF.

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

2013-01-02  Robert Dewar  

* checks.adb (Apply_Scalar_Range_Check): Implement Check_Float_Overflow.
* opt.ads, opt.adb: Handle flags Check_Float_Overflow[_Config].
* par-prag.adb: Add dummy entry for pragma Check_Float_Overflow.
* sem_prag.adb: Implement pragma Check_Float_Overflow.
* snames.ads-tmpl: Add entries for pragma Check_Float_Overflow.
* switch-c.adb: Recognize -gnateF switch.
* tree_io.ads: Update ASIS version number.
* gnat_rm.texi: Add documentation of pragma Check_Float_Overflow.

Index: checks.adb
===
--- checks.adb  (revision 194787)
+++ checks.adb  (working copy)
@@ -2692,15 +2692,24 @@
   Is_Unconstrained_Subscr_Ref :=
 Is_Subscr_Ref and then not Is_Constrained (Arr_Typ);
 
-  --  Always do a range check if the source type includes infinities and
-  --  the target type does not include infinities. We do not do this if
-  --  range checks are killed.
+  --  Special checks for floating-point type
 
-  if Is_Floating_Point_Type (S_Typ)
-and then Has_Infinities (S_Typ)
-and then not Has_Infinities (Target_Typ)
-  then
- Enable_Range_Check (Expr);
+  if Is_Floating_Point_Type (S_Typ) then
+
+ --  Always do a range check if the source type includes infinities and
+ --  the target type does not include infinities. We do not do this if
+ --  range checks are killed.
+
+ if Has_Infinities (S_Typ)
+   and then not Has_Infinities (Target_Typ)
+ then
+Enable_Range_Check (Expr);
+
+ --  Always do a range check for operators if option set
+
+ elsif Check_Float_Overflow and then Nkind (Expr) in N_Op then
+Enable_Range_Check (Expr);
+ end if;
   end if;
 
   --  Return if we know expression is definitely in the range of the target
@@ -2780,15 +2789,14 @@
   --  only if this is not a conversion between integer and real types.
 
   if not Is_Unconstrained_Subscr_Ref
+and then Is_Discrete_Type (S_Typ) = Is_Discrete_Type (Target_Typ)
 and then
-   Is_Discrete_Type (S_Typ) = Is_Discrete_Type (Target_Typ)
-and then
   (In_Subrange_Of (S_Typ, Target_Typ, Fixed_Int)
  or else
Is_In_Range (Expr, Target_Typ,
 Assume_Valid => True,
-Fixed_Int => Fixed_Int,
-Int_Real  => Int_Real))
+Fixed_Int=> Fixed_Int,
+Int_Real => Int_Real))
   then
  return;
 
@@ -2800,12 +2808,18 @@
  Bad_Value;
  return;
 
+  --  Floating-point case
   --  In the floating-point case, we only do range checks if the type is
   --  constrained. We definitely do NOT want range checks for unconstrained
   --  types, since we want to have infinities
 
   elsif Is_Floating_Point_Type (S_Typ) then
- if Is_Constrained (S_Typ) then
+
+  --  Normally, we only do range checks if the type is constrained. We do
+  --  NOT want range checks for unconstrained types, since we want to have
+  --  infinities. Override this decision in Check_Float_Overflow mode.
+
+ if Is_Constrained (S_Typ) or else Check_Float_Overflow then
 Enable_Range_Check (Expr);
  end if;
 
@@ -5650,22 +5664,24 @@
   --  First special case, if the source type is already within the range
   --  of the target type, then no check is needed (probably we should have
   --  stopped Do_Range_Check from being

Re: [C++ Patch] PR 54526 (again)

[Jakub Jelinek]

Hi!

On Sun, Oct 28, 2012 at 12:27:40PM +0100, Paolo Carlini wrote:
> --- gcc/cp/parser.c   (revision 192887)
> +++ gcc/cp/parser.c   (working copy)
> @@ -12655,9 +12655,8 @@ cp_parser_template_id (cp_parser *parser,
>/* Otherwise, emit an error about the invalid digraph, but continue
>parsing because we got our argument list.  In C++11 do not emit
>any error, per 2.5/3.  */

Shouldn't the "In C++11 do not emit"... sentence be removed from the comment
as well?

> -  if (cxx_dialect < cxx0x
> -   && permerror (next_token->location,
> - "%<<::%> cannot begin a template-argument list"))
> +  if (permerror (next_token->location,
> +  "%<<::%> cannot begin a template-argument list"))
>   {
> static bool hint = false;
> inform (next_token->location,

> --- libcpp/lex.c  (revision 192887)
> +++ libcpp/lex.c  (working copy)
> @@ -2291,6 +2291,25 @@ _cpp_lex_direct (cpp_reader *pfile)
> if (*buffer->cur == ':')
>   {
> buffer->cur++;
> +
> +   /* C++11 - 2.5 p3, bullet 2.  */
> +   if (CPP_OPTION (pfile, cplusplus)
> +   && (CPP_OPTION (pfile, lang) == CLK_CXX11
> +   || CPP_OPTION (pfile, lang) == CLK_GNUCXX11))
> + {
> +   if (*buffer->cur == ':')
> + {
> +   buffer->cur++;
> +   if (*buffer->cur != ':' && *buffer->cur != '>')
> + {
> +   --buffer->cur;
> +   --buffer->cur;
> +   break;
> + }
> +   --buffer->cur;

I'd say way too many ++/-- above.  I'd write it as:

- buffer->cur++;
+
+ /* C++11 - 2.5 p3, bullet 2.  */
+ if (CPP_OPTION (pfile, cplusplus)
+ && (CPP_OPTION (pfile, lang) == CLK_CXX11
+ || CPP_OPTION (pfile, lang) == CLK_GNUCXX11)
+ && buffer->cur[1] == ':'
+ && buffer->cur[2] != ':' && buffer->cur[2] != '>')
+   break;
+
+ buffer->cur++;

Jakub

[Ada] Illegal forward reference in pragma Postcondition

[Arnaud Charlet]

This patch ensures that the boolean expression of pragma Postcondition is
preanalyzed at the point of declaration when the pragma appears inside a
subprogram body.


-- Source --


--  main.adb

procedure Main is
   pragma Postcondition (X'Old = 1);
   X : Integer := 0;
begin
   X := 2;
end Main;

-
-- Compilation --
-

$ gcc -c -gnata main.adb
main.adb:2:26: "X" is undefined

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

2013-01-02  Hristian Kirtchev  

* sem_attr.adb (Analyze_Attribute): Skip the special _Parent
scope generated for subprogram inlining purposes while trying
to locate the enclosing function.
* sem_prag.adb (Analyze_Pragma): Preanalyze the boolean
expression of pragma Postcondition when the pragma comes from
source and appears inside a subprogram body.

Index: sem_prag.adb
===
--- sem_prag.adb(revision 194788)
+++ sem_prag.adb(working copy)
@@ -12748,7 +12748,6 @@
 
  when Pragma_Postcondition => Postcondition : declare
 In_Body : Boolean;
-pragma Warnings (Off, In_Body);
 
  begin
 GNAT_Pragma;
@@ -12756,10 +12755,22 @@
 Check_At_Most_N_Arguments (2);
 Check_Optional_Identifier (Arg1, Name_Check);
 
---  All we need to do here is call the common check procedure,
---  the remainder of the processing is found in Sem_Ch6/Sem_Ch7.
+--  Verify the proper placement of the pragma. The remainder of the
+--  processing is found in Sem_Ch6/Sem_Ch7.
 
 Check_Precondition_Postcondition (In_Body);
+
+--  When the pragma is a source contruct and appears inside a body,
+--  preanalyze the boolean_expression to detect illegal forward
+--  references:
+
+--procedure P is
+--   pragma Postcondition (X'Old ...);
+--   X : ...
+
+if Comes_From_Source (N) and then In_Body then
+   Preanalyze_Spec_Expression (Expression (Arg1), Any_Boolean);
+end if;
  end Postcondition;
 
  --
Index: sem_attr.adb
===
--- sem_attr.adb(revision 194786)
+++ sem_attr.adb(working copy)
@@ -4586,11 +4586,26 @@
  --  During pre-analysis, Prag is the enclosing pragma node if any
 
   begin
- --  Find enclosing scopes, excluding loops
+ --  Find the proper enclosing scope
 
  CS := Current_Scope;
- while Ekind (CS) = E_Loop loop
-CS := Scope (CS);
+ while Present (CS) loop
+
+--  Skip generated loops
+
+if Ekind (CS) = E_Loop then
+   CS := Scope (CS);
+
+--  Skip the special _Parent scope generated to capture references
+--  to formals during the process of subprogram inlining.
+
+elsif Ekind (CS) = E_Function
+  and then Chars (CS) = Name_uParent
+then
+   CS := Scope (CS);
+else
+   exit;
+end if;
  end loop;
 
  PS := Scope (CS);

[Ada] Improvements to sprint for conditional expressions

[Arnaud Charlet]

This change improves the circuitry that produces a source-like rendition
for an Ada tree by omitting the generation of extraneous parentheses around
conditional expressions, and removing an extraneous ELSE keyword.

The following compilation must produce the indicated output:
$ gcc -c -gnat12 -gnatG condexpr_sprint.adb
Source recreated from tree for Condexpr_Sprint (body)


procedure condexpr_sprint (b : boolean; i : integer) is
   type r is record
  bb : boolean := (if b then b);
  ii : integer := (case i is when 1 => 1, when others => 2);
   end record;
begin
   null;
end condexpr_sprint;

condexpr_sprint.adb:2:04: declaration expected

procedure Condexpr_Sprint (B : Boolean; I : Integer) is
   zz --  Purposely introduce a serious error here to prevent further analysis

   type R is record
  BB : Boolean := (if B then B);
  II : Integer := (case I is when 1 => 1, when others => 2);
   end record;
begin
   null;
end Condexpr_Sprint;

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

2013-01-02  Thomas Quinot  

* sprint.adb (Sprint_Node_Actual): Do not add extra parens for
a conditional expression (CASE or IF expression) that already
has parens. Also omit ELSE keyword for an IF expression without
an ELSE part.

Index: sprint.adb
===
--- sprint.adb  (revision 194776)
+++ sprint.adb  (working copy)
@@ -1159,14 +1159,19 @@
 
  when N_Case_Expression =>
 declare
-   Alt : Node_Id;
+   Has_Parens : constant Boolean := Paren_Count (Node) > 0;
+   Alt: Node_Id;
 
 begin
--  The syntax for case_expression does not include parentheses,
--  but sometimes parentheses are required, so unconditionally
-   --  generate them here.
+   --  generate them here unless already present.
 
-   Write_Str_With_Col_Check_Sloc ("(case ");
+   if not Has_Parens then
+  Write_Char ('(');
+   end if;
+
+   Write_Str_With_Col_Check_Sloc ("case ");
Sprint_Node (Expression (Node));
Write_Str_With_Col_Check (" is");
 
@@ -1178,7 +1183,9 @@
   Write_Char (',');
end loop;
 
-   Write_Char (')');
+   if not Has_Parens then
+  Write_Char (')');
+   end if;
 end;
 
  when N_Case_Expression_Alternative =>
@@ -1963,15 +1970,19 @@
 
  when N_If_Expression =>
 declare
-   Condition : constant Node_Id := First (Expressions (Node));
-   Then_Expr : constant Node_Id := Next (Condition);
+   Has_Parens : constant Boolean := Paren_Count (Node) > 0;
+   Condition  : constant Node_Id := First (Expressions (Node));
+   Then_Expr  : constant Node_Id := Next (Condition);
 
 begin
--  The syntax for if_expression does not include parentheses,
--  but sometimes parentheses are required, so unconditionally
-   --  generate them here.
+   --  generate them here unless already present.
 
-   Write_Str_With_Col_Check_Sloc ("(if ");
+   if not Has_Parens then
+  Write_Char ('(');
+   end if;
+   Write_Str_With_Col_Check_Sloc ("if ");
Sprint_Node (Condition);
Write_Str_With_Col_Check (" then ");
 
@@ -1979,11 +1990,16 @@
 
if Present (Then_Expr) then
   Sprint_Node (Then_Expr);
-  Write_Str_With_Col_Check (" else ");
-  Sprint_Node (Next (Then_Expr));
+
+  if Present (Next (Then_Expr)) then
+ Write_Str_With_Col_Check (" else ");
+ Sprint_Node (Next (Then_Expr));
+  end if;
end if;
 
-   Write_Char (')');
+   if not Has_Parens then
+  Write_Char (')');
+   end if;
 end;
 
  when N_If_Statement =>

[PATCH] Fix PR55784

[Richard Biener]

This supposedly fixes PR55784 according to people running into the
issue.  We need to add GMPINC to the include paths everywhere as
we now include gmp.h from system.h.

Bootstrap and regtest running on x86_64-unknown-linux-gnu.

Ada bits approved by Eric in bugzilla.

Richard.

2013-01-02  Richard Biener  

PR bootstrap/55784
* configure.ac: Add $GMPINC to CFLAGS/CXXFLAGS.
* configure: Regenerate.

ada/
* gcc-interface/Makefile.in: Add $(GMPINC) to includes.

Index: gcc/configure.ac
===
*** gcc/configure.ac(revision 194787)
--- gcc/configure.ac(working copy)
*** AM_LANGINFO_CODESET
*** 1098,1106 
  
  # We will need to find libiberty.h and ansidecl.h
  saved_CFLAGS="$CFLAGS"
! CFLAGS="$CFLAGS -I${srcdir} -I${srcdir}/../include"
  saved_CXXFLAGS="$CXXFLAGS"
! CXXFLAGS="$CXXFLAGS -I${srcdir} -I${srcdir}/../include"
  gcc_AC_CHECK_DECLS(getenv atol asprintf sbrk abort atof getcwd getwd \
strsignal strstr stpcpy strverscmp \
errno snprintf vsnprintf vasprintf malloc realloc calloc \
--- 1098,1106 
  
  # We will need to find libiberty.h and ansidecl.h
  saved_CFLAGS="$CFLAGS"
! CFLAGS="$CFLAGS -I${srcdir} -I${srcdir}/../include $GMPINC"
  saved_CXXFLAGS="$CXXFLAGS"
! CXXFLAGS="$CXXFLAGS -I${srcdir} -I${srcdir}/../include $GMPINC"
  gcc_AC_CHECK_DECLS(getenv atol asprintf sbrk abort atof getcwd getwd \
strsignal strstr stpcpy strverscmp \
errno snprintf vsnprintf vasprintf malloc realloc calloc \
Index: gcc/configure
===
*** gcc/configure   (revision 194787)
--- gcc/configure   (working copy)
*** $as_echo "#define HAVE_LANGINFO_CODESET
*** 10321,10329 
  
  # We will need to find libiberty.h and ansidecl.h
  saved_CFLAGS="$CFLAGS"
! CFLAGS="$CFLAGS -I${srcdir} -I${srcdir}/../include"
  saved_CXXFLAGS="$CXXFLAGS"
! CXXFLAGS="$CXXFLAGS -I${srcdir} -I${srcdir}/../include"
  for ac_func in getenv atol asprintf sbrk abort atof getcwd getwd \
strsignal strstr stpcpy strverscmp \
errno snprintf vsnprintf vasprintf malloc realloc calloc \
--- 10321,10329 
  
  # We will need to find libiberty.h and ansidecl.h
  saved_CFLAGS="$CFLAGS"
! CFLAGS="$CFLAGS -I${srcdir} -I${srcdir}/../include $GMPINC"
  saved_CXXFLAGS="$CXXFLAGS"
! CXXFLAGS="$CXXFLAGS -I${srcdir} -I${srcdir}/../include $GMPINC"
  for ac_func in getenv atol asprintf sbrk abort atof getcwd getwd \
strsignal strstr stpcpy strverscmp \
errno snprintf vsnprintf vasprintf malloc realloc calloc \
Index: gcc/ada/gcc-interface/Makefile.in
===
*** gcc/ada/gcc-interface/Makefile.in   (revision 194787)
--- gcc/ada/gcc-interface/Makefile.in   (working copy)
*** endif
*** 273,279 
  # Both . and srcdir are used, in that order,
  # so that tm.h and config.h will be found in the compilation
  # subdirectory rather than in the source directory.
! INCLUDES = -I- -I. -I.. -I$(srcdir)/ada -I$(srcdir) -I$(srcdir)/../include
  
  ADA_INCLUDES = -I- -I. -I$(srcdir)/ada
  
--- 273,279 
  # Both . and srcdir are used, in that order,
  # so that tm.h and config.h will be found in the compilation
  # subdirectory rather than in the source directory.
! INCLUDES = -I- -I. -I.. -I$(srcdir)/ada -I$(srcdir) -I$(srcdir)/../include 
$(GMPINC)
  
  ADA_INCLUDES = -I- -I. -I$(srcdir)/ada
  
*** ADA_INCLUDES = -I- -I. -I$(srcdir)/ada
*** 283,293 
  ifneq ($(findstring vxworks,$(osys)),)
INCLUDES_FOR_SUBDIR = -iquote . -iquote .. -iquote ../.. \
-iquote $(fsrcdir)/ada \
!   -I$(fsrcdir)/../include
  else
INCLUDES_FOR_SUBDIR = -iquote . -iquote .. -iquote ../.. \
-iquote $(fsrcdir)/ada -iquote $(fsrcdir) \
!   -I$(fsrcdir)/../include
  endif
  
  ADA_INCLUDES_FOR_SUBDIR = -I. -I$(fsrcdir)/ada
--- 283,293 
  ifneq ($(findstring vxworks,$(osys)),)
INCLUDES_FOR_SUBDIR = -iquote . -iquote .. -iquote ../.. \
-iquote $(fsrcdir)/ada \
!   -I$(fsrcdir)/../include $(GMPINC)
  else
INCLUDES_FOR_SUBDIR = -iquote . -iquote .. -iquote ../.. \
-iquote $(fsrcdir)/ada -iquote $(fsrcdir) \
!   -I$(fsrcdir)/../include $(GMPINC)
  endif
  
  ADA_INCLUDES_FOR_SUBDIR = -I. -I$(fsrcdir)/ada

Re: Use libstdc++-raw-cxx.m4 in libjava

[Jakub Jelinek]

On Tue, Dec 11, 2012 at 02:00:18PM -0800, H.J. Lu wrote:
> 2012-12-11  H.J. Lu  
> 
>   * libstdc++-raw-cxx.m4 (GCC_LIBSTDCXX_RAW_CXX_FLAGS): Also
>   AC_SUBST LIBSTDCXX_RAW_CXX_LDFLAGS.

> --- a/config/libstdc++-raw-cxx.m4
> +++ b/config/libstdc++-raw-cxx.m4
> @@ -14,13 +14,17 @@
>  # along with GCC; see the file COPYING3.  If not see
>  # .
> 
> -# Define compiler flags, LIBSTDCXX_RAW_CXX_CXXFLAGS, for libstdc++-v3
> -# header files to compile libraries in C++ with raw_cxx=true.
> +# Define flags, LIBSTDCXX_RAW_CXX_CXXFLAGS and # LIBSTDCXX_RAW_CXX_LDFLAGS,
> +# for libstdc++-v3 header files to compile and link libraries in C++ with
> +# raw_cxx=true.
>  AC_DEFUN([GCC_LIBSTDCXX_RAW_CXX_FLAGS], [
>AC_REQUIRE([ACX_NONCANONICAL_TARGET])
>LIBSTDCXX_RAW_CXX_CXXFLAGS="\
>  -I\$(top_builddir)/../libstdc++-v3/include \
>  -I\$(top_builddir)/../libstdc++-v3/include/\$(target_noncanonical) \
>  -I\$(top_srcdir)/../libstdc++-v3/libsupc++"
> +  LIBSTDCXX_RAW_CXX_LDFLAGS="\
> +-I\$(top_builddir)/../libstdc++-v3/src/libstdc++.la"

-I/libstdc++-v3/src/libstdc++.la ?  That can't be right, libstdc++.la
is not a directory containing header files.

Jakub

[Ada] Make {Short,Long,Long_Long}_Complex_Elementary_Functions pure

[Arnaud Charlet]

The other Complex_Elementary_Functions packages were already declared pure,
these were missed by oversight.

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

2013-01-02  Geert Bosch  

* a-nllcef.ads, a-nlcefu.ads, a-nscefu.ads: Make Pure.

Index: a-nllcef.ads
===
--- a-nllcef.ads(revision 194776)
+++ a-nllcef.ads(working copy)
@@ -19,3 +19,4 @@
 package Ada.Numerics.Long_Long_Complex_Elementary_Functions is
   new Ada.Numerics.Generic_Complex_Elementary_Functions
(Ada.Numerics.Long_Long_Complex_Types);
+pragma Pure (Ada.Numerics.Long_Long_Complex_Elementary_Functions);
Index: a-nlcefu.ads
===
--- a-nlcefu.ads(revision 194776)
+++ a-nlcefu.ads(working copy)
@@ -19,3 +19,4 @@
 package Ada.Numerics.Long_Complex_Elementary_Functions is
   new Ada.Numerics.Generic_Complex_Elementary_Functions
   (Ada.Numerics.Long_Complex_Types);
+pragma Pure (Ada.Numerics.Long_Complex_Elementary_Functions);
Index: a-nscefu.ads
===
--- a-nscefu.ads(revision 194776)
+++ a-nscefu.ads(working copy)
@@ -19,3 +19,4 @@
 package Ada.Numerics.Short_Complex_Elementary_Functions is
   new Ada.Numerics.Generic_Complex_Elementary_Functions
   (Ada.Numerics.Short_Complex_Types);
+pragma Pure (Ada.Numerics.Short_Complex_Elementary_Functions);

Re: Use libstdc++-raw-cxx.m4 in libjava

[Andreas Schwab]

Jakub Jelinek  writes:

> On Tue, Dec 11, 2012 at 02:00:18PM -0800, H.J. Lu wrote:
>> 2012-12-11  H.J. Lu  
>> 
>>  * libstdc++-raw-cxx.m4 (GCC_LIBSTDCXX_RAW_CXX_FLAGS): Also
>>  AC_SUBST LIBSTDCXX_RAW_CXX_LDFLAGS.
>
>> --- a/config/libstdc++-raw-cxx.m4
>> +++ b/config/libstdc++-raw-cxx.m4
>> @@ -14,13 +14,17 @@
>>  # along with GCC; see the file COPYING3.  If not see
>>  # .
>> 
>> -# Define compiler flags, LIBSTDCXX_RAW_CXX_CXXFLAGS, for libstdc++-v3
>> -# header files to compile libraries in C++ with raw_cxx=true.
>> +# Define flags, LIBSTDCXX_RAW_CXX_CXXFLAGS and # LIBSTDCXX_RAW_CXX_LDFLAGS,
>> +# for libstdc++-v3 header files to compile and link libraries in C++ with
>> +# raw_cxx=true.
>>  AC_DEFUN([GCC_LIBSTDCXX_RAW_CXX_FLAGS], [
>>AC_REQUIRE([ACX_NONCANONICAL_TARGET])
>>LIBSTDCXX_RAW_CXX_CXXFLAGS="\
>>  -I\$(top_builddir)/../libstdc++-v3/include \
>>  -I\$(top_builddir)/../libstdc++-v3/include/\$(target_noncanonical) \
>>  -I\$(top_srcdir)/../libstdc++-v3/libsupc++"
>> +  LIBSTDCXX_RAW_CXX_LDFLAGS="\
>> +-I\$(top_builddir)/../libstdc++-v3/src/libstdc++.la"
>
> -I/libstdc++-v3/src/libstdc++.la ?  That can't be right, libstdc++.la
> is not a directory containing header files.

And a library shouldn't be put on LDFLAGS, but on LIBADD.  And
LIBSTDCXX_RAW_CXX_LDLAGS doesn't exist.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

[Ada] Illegal prefix in array attributes

[Arnaud Charlet]

A reference to a type in an expression freezes the type, and any component
subtypes. This is the case for array attributes such as 'Length, 'Size, etc.
which can be evaluated without reference to the component type, but still
require that the component type be fully declared at the point of the attribute.

Compiling foo.ads must yield:

  foo.ads:5:21: premature usage of incomplete private type "X" defined at line 3

package Foo is

type X is private;
type Y is array(1 .. 4) of X;
Z : constant := Y'Length;

private
type X is new Integer;

end Foo;

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

2013-01-02  Ed Schonberg  

* sem_attr.adb (Check_Array_Type): Reject an attribute reference on an
array whose component type does not have a completion.

Index: sem_attr.adb
===
--- sem_attr.adb(revision 194792)
+++ sem_attr.adb(working copy)
@@ -1015,6 +1015,16 @@
  ("prefix for % attribute must be constrained array", P);
 end if;
 
+--  The attribute reference freezes the type, and thus the
+--  component type, even if the attribute may not depend on the
+--  component. Diagnose arrays with incomplete components now.
+--  If the prefix is an access to array, this does not freeze
+--  the designated type.
+
+if Nkind (P) /= N_Explicit_Dereference then
+   Check_Fully_Declared (Component_Type (P_Type), P);
+end if;
+
 D := Number_Dimensions (P_Type);
 
  else

[PATCH] Fix up compat.exp C testing

[Jakub Jelinek]

Hi!

I've noticed when using ALT_CC_UNDER_TEST=gcc all compat.exp and
struct-layout-1.exp tests fail, because prune.exp adds
-fno-diagnostics-show-caret unconditionally, which is undesirable if
$ALT_CC_UNDER_TEST doesn't support that option (but of course desirable
if $ALT_CC_UNDER_TEST supports carets).
check-g++ compat.exp & struct-layout-1.exp don't suffer from this problem,
because they apparently clear ALWAYS_CXXFLAGS completely in their
compat-use-alt-compiler (which isn't right either, when testing say g++ 4.9
against 4.8 we will want to pass -fno-diagnostics-show-caret, and also
perhaps -fmessage-length=0 should be passed too conditionally depending on
whether alt g++ supports it or not).
Another thing is that ALT_*_UNDER_TEST testing doesn't work when testing
a compiler built with different prefix from the alt compiler, then the
problem is that GCC_RUN_PATH is put into environment.  Perhaps
compat-use-alt-compiler should remove GCC_RUN_PATH from environment and
compat-use-tst-compiler add it back if it was initially in the environment?

Anyway, this fixes the most urgent issue.  Ok for trunk?

2013-01-02  Jakub Jelinek  

* lib/c-compat.exp (compat-use-alt-compiler): Remove
-fno-diagnostics-show-caret from TEST_ALWAYS_FLAGS if needed.
(compat-use-tst-compiler): Restore TEST_ALWAYS_FLAGS.
(compat_setup_dfp): Initialize compat_alt_caret and
compat_save_TEST_ALWAYS_FLAGS.

--- gcc/testsuite/lib/c-compat.exp.jj   2009-02-20 15:43:09.0 +0100
+++ gcc/testsuite/lib/c-compat.exp  2013-01-02 13:41:28.595153560 +0100
@@ -1,4 +1,4 @@
-# Copyright (C) 2002, 2003, 2005, 2006, 2007, 2008
+# Copyright (C) 2002, 2003, 2005, 2006, 2007, 2008, 2013
 # Free Software Foundation, Inc.
 
 # This program is free software; you can redistribute it and/or modify
@@ -35,12 +35,16 @@ load_lib target-supports.exp
 # 
 proc compat-use-alt-compiler { } {
 global GCC_UNDER_TEST ALT_CC_UNDER_TEST
-global compat_same_alt
+global compat_same_alt compat_alt_caret
+global TEST_ALWAYS_FLAGS
 
 # We don't need to do this if the alternate compiler is actually
 # the same as the compiler under test.
 if { $compat_same_alt == 0 } then {
set GCC_UNDER_TEST $ALT_CC_UNDER_TEST
+   if { $compat_alt_caret == 0 } then {
+   regsub -- "-fno-diagnostics-show-caret" $TEST_ALWAYS_FLAGS "" 
TEST_ALWAYS_FLAGS
+   }
 }
 }
 
@@ -50,12 +54,14 @@ proc compat-use-alt-compiler { } {
 proc compat-use-tst-compiler { } {
 global GCC_UNDER_TEST compat_save_gcc_under_test
 global compat_same_alt
+global TEST_ALWAYS_FLAGS compat_save_TEST_ALWAYS_FLAGS
 
 # We don't need to do this if the alternate compiler is actually
 # the same as the compiler under test.
 
 if { $compat_same_alt == 0 } then {
set GCC_UNDER_TEST $compat_save_gcc_under_test
+   set TEST_ALWAYS_FLAGS $compat_save_TEST_ALWAYS_FLAGS
 }
 }
 
@@ -64,6 +70,11 @@ proc compat_setup_dfp { } {
 global compat_use_alt
 global compat_same_alt
 global compat_have_dfp
+global compat_alt_caret
+global TEST_ALWAYS_FLAGS compat_save_TEST_ALWAYS_FLAGS
+
+set compat_alt_caret 0
+set compat_save_TEST_ALWAYS_FLAGS $TEST_ALWAYS_FLAGS
 
 verbose "compat_setup_dfp: $compat_use_alt $compat_same_alt" 2
 
@@ -72,6 +83,15 @@ proc compat_setup_dfp { } {
 set compat_have_dfp [check_effective_target_dfprt_nocache]
 verbose "compat_have_dfp for tst compiler: $compat_have_dfp" 2
 
+if { $compat_use_alt == 1 && $compat_same_alt == 0 } {
+   compat-use-alt-compiler
+   if { [check_no_compiler_messages_nocache compat_alt_has_caret object {
+   int dummy; } "-fno-diagnostics-show-caret"] != 0 } {
+   set compat_alt_caret 1
+   }
+   compat-use-tst-compiler
+}
+
 # If there is an alternate compiler, does it support decimal float types?
 if { $compat_have_dfp == 1 && $compat_use_alt == 1 && $compat_same_alt == 
0 } {
compat-use-alt-compiler

Jakub

Re: [committed] Fix ICE in gen_reg_rtx, at emit-rtl.c:864/865 compiling GNU MPFR

[Richard Sandiford]

John David Anglin  writes:
> The attached change fixes PR target/5379.  ICE occurs when reload tries
> to emit a move instruction containing a TLS symbol reference as the source
> operand.  This requires several scratch registers.  As a result, it isn't
> possible for a reload pattern to handle this case.  So, the best solution
> was to reject TLS symbol reference source operands after reload starts.
>
> Tested on hppa-unknown-linux-gnu and hppa2.0w-hp-hpux11.11 with not observed
> regressions.
>
> Committed to all active branches.
>
> Dave
>
> 2012-12-25  John David Anglin  
>
>   PR target/53789
>   * config/pa/pa.md (movsi): Reject expansion of TLS symbol references
>   after reload starts.
>
> Index: config/pa/pa.md
> ===
> --- config/pa/pa.md   (revision 194709)
> +++ config/pa/pa.md   (working copy)
> @@ -2051,6 +2110,12 @@
>""
>"
>  {
> +  /* A TLS symbol reference is not a valid move source operand.
> + pa_emit_move_sequence can only handle them prior to reload.
> + There is also no way to reload a TLS symbol reference, so
> + we must reject them after reload starts.  */
> +  if (PA_SYMBOL_REF_TLS_P (operands[1]) && !can_create_pseudo_p ())
> +FAIL;
>if (pa_emit_move_sequence (operands, SImode, 0))
>  DONE;
>  }")

Sorry to butt in, but I'm not sure about this.  Move patterns aren't
supposed to fail.  The nasty thing is that all FAIL actually does is
make the generator return null, and emitting a null insn is a no-op.
That means code like:

  /* from emit_move_insn_1 */
  code = optab_handler (mov_optab, mode);
  if (code != CODE_FOR_nothing)
return emit_insn (GEN_FCN (code) (x, y));
  ...

  emit_move_insn{,_1} (x, y);

won't generate an ICE on FAIL, but it won't generate any insns either.
If someone's feeling brave, they might want to add an assert for nonnull.

In any case, reload needs to know up-front that the constant can't be
rematerialised, via LEGITIMATE_CONSTANT_P.  emit_move_insn_1 would be
too late.  It looks like PA already handles this for some TLS models:

  /* TLS_MODEL_GLOBAL_DYNAMIC and TLS_MODEL_LOCAL_DYNAMIC are not
 legitimate constants.  */
  if (PA_SYMBOL_REF_TLS_P (x))
   {
 enum tls_model model = SYMBOL_REF_TLS_MODEL (x);

 if (model == TLS_MODEL_GLOBAL_DYNAMIC || model == TLS_MODEL_LOCAL_DYNAMIC)
   return false;
   }

so maybe that should just be:

  if (PA_SYMBOL_REF_TLS_P (x))
return false;

?  It probably ought to handle symbol + constant too though.

FWIW, I wrote the test below just to make sure that this worked for
mips64-linux-gnu.  OK to install?

...although I just tried it on x86_64-linux-gnu and it ICEs there.

Richard


gcc/testsuite/
* gcc.dg/torture/tls/tls-reload-1.c: New test.

Index: gcc/testsuite/gcc.dg/torture/tls/tls-reload-1.c
===
--- /dev/null   2012-12-29 10:15:03.199289441 +
+++ gcc/testsuite/gcc.dg/torture/tls/tls-reload-1.c 2013-01-02 
12:56:22.278837979 +
@@ -0,0 +1,48 @@
+/* { dg-do run } */
+/* { dg-require-effective-target tls_runtime } */
+
+#define ARRAY(X) X##_array
+#define DECLARE(X) \
+  __thread int X; \
+  __thread int ARRAY(X)[4]; \
+  int *volatile *__attribute__((noinline)) \
+  check##X (int *volatile *y) \
+  { \
+if (!y || *y++ != &X || *y++ != &ARRAY(X)[3]) \
+  return 0; \
+return y; \
+  }
+#define COPY(X) *y++ = &X; *y++ = &ARRAY(X)[3];
+#define CHECK(X) y = check##X (y);
+#define A(M, X) M(X##0) M(X##1) M(X##2) M(X##3) M(X##4) M(X##5) M(X##6) M(X##7)
+#define B(M, X) A(M, X##0) A(M, X##1) A(M, X##2)
+#define C(M, X) B(M, X) B(M, X) B(M, X)
+
+#define NM 2
+#define NA (NM * 8)
+#define NB (NA * 3)
+#define NC (NB * 3)
+
+extern void abort (void);
+
+B(DECLARE, tls)
+
+void __attribute__ ((noinline))
+setup (int *volatile *y)
+{
+  C(COPY, tls)
+}
+
+int
+main (void)
+{
+  int *volatile array[NC];
+  int *volatile *y = array;
+  int i;
+
+  setup (array);
+  B(CHECK, tls);
+  if (!y)
+abort ();
+  return 0;
+}

Re: extern "C" fixes for sunCC

[Marc Glisse]

Ping
http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00746.html
(I'll re-test since there have been changes around gmp.h inclusion)

On Tue, 11 Dec 2012, Marc Glisse wrote:


Hello,

this patch should help if we ever want to use sunCC to initiate a bootstrap, 
though I didn't test with sunCC. Note that using gmp_fprintf means we have to 
include stdio.h before gmp.h. I didn't investigate how, but this seems to 
already be the case :-) The reallocator cast is just a hack, but the point 
here is only to help sunCC, making gcc extern "C"-clean is a larger task...


Passes bootstrap+testsuite on x86_64-linux using the system's gcc (graphite 
is enabled, don't know if this particular code is exercised).


2012-12-12  Marc Glisse  

PR bootstrap/50167
PR bootstrap/50177
libcpp/
* line-map.c (get_combined_adhoc_loc): Cast to extern "C" type.
gcc/
* graphite-interchange.c (pdr_stride_in_loop): Use gmp_fprintf.
* graphite-poly.c (debug_gmp_value): Likewise.


--
Marc Glisse

[PATCH] Avoid creating dead code in the vectorizer

[Richard Biener]

When analyzing PR55334 further I noticed that when vectorizing
an invariant load we still create a regular (but dead) vector
load and an associated pointer induction variable.  That's of
course pointless.

Fix is simple.

Bootstrapped (with -O3) and tested on x86_64-unknown-linux-gnu, applied to 
trunk.

Richard.

2013-01-02  Richard Biener  

* tree-vect-stmts.c (vectorizable_load): When vectorizing an
invariant load do not generate a vector load from the scalar
location.

Index: gcc/tree-vect-stmts.c
===
*** gcc/tree-vect-stmts.c   (revision 194787)
--- gcc/tree-vect-stmts.c   (working copy)
*** vectorizable_load (gimple stmt, gimple_s
*** 4988,4993 
--- 4988,5006 
  /* Record the mapping between SSA_NAMEs and statements.  */
  vect_record_grouped_load_vectors (stmt, dr_chain);
}
+   /* Handle invariant-load.  */
+   else if (inv_p && !bb_vinfo)
+   {
+ gimple_stmt_iterator gsi2 = *gsi;
+ gcc_assert (!grouped_load && !slp_perm);
+ gsi_next (&gsi2);
+ new_temp = vect_init_vector (stmt, scalar_dest,
+  vectype, &gsi2);
+ new_stmt = SSA_NAME_DEF_STMT (new_temp);
+ /* Store vector loads in the corresponding SLP_NODE.  */
+ if (slp)
+   SLP_TREE_VEC_STMTS (slp_node).quick_push (new_stmt);
+   }
else
{
  for (i = 0; i < vec_num; i++)
*** vectorizable_load (gimple stmt, gimple_s
*** 5135,5151 
}
}
  
- /* 4. Handle invariant-load.  */
- if (inv_p && !bb_vinfo)
-   {
- gimple_stmt_iterator gsi2 = *gsi;
- gcc_assert (!grouped_load);
- gsi_next (&gsi2);
- new_temp = vect_init_vector (stmt, scalar_dest,
-  vectype, &gsi2);
- new_stmt = SSA_NAME_DEF_STMT (new_temp);
-   }
- 
  if (negative)
{
  tree perm_mask = perm_mask_for_reverse (vectype);
--- 5148,5153 

Re: extern "C" fixes for sunCC

[Richard Biener]

On Wed, Jan 2, 2013 at 2:45 PM, Marc Glisse  wrote:
> Ping
> http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00746.html
> (I'll re-test since there have been changes around gmp.h inclusion)

The graphite changes are ok.

Thanks,
Richard.

>
> On Tue, 11 Dec 2012, Marc Glisse wrote:
>
>> Hello,
>>
>> this patch should help if we ever want to use sunCC to initiate a
>> bootstrap, though I didn't test with sunCC. Note that using gmp_fprintf
>> means we have to include stdio.h before gmp.h. I didn't investigate how, but
>> this seems to already be the case :-) The reallocator cast is just a hack,
>> but the point here is only to help sunCC, making gcc extern "C"-clean is a
>> larger task...
>>
>> Passes bootstrap+testsuite on x86_64-linux using the system's gcc
>> (graphite is enabled, don't know if this particular code is exercised).
>>
>> 2012-12-12  Marc Glisse  
>>
>> PR bootstrap/50167
>> PR bootstrap/50177
>> libcpp/
>> * line-map.c (get_combined_adhoc_loc): Cast to extern "C" type.
>> gcc/
>> * graphite-interchange.c (pdr_stride_in_loop): Use gmp_fprintf.
>> * graphite-poly.c (debug_gmp_value): Likewise.
>
>
> --
> Marc Glisse

[Patch, fortran] [4.7/4.8 Regression] [OOP] ICE on invalid: gfc_variable_attr(): Bad array reference

[Paul Richard Thomas]

Dear All,

As noted by Janus in comment #2 of the PR, "I think the function
'copy_ts_from_selector_to_associate' comes too early (namely during
parsing). It tries to resolve the target expr, which should rather
wait until resolution stage!?!"

It turned out that the function of the call to gfc_resolve_expr was to
fix up the selector array reference type.  This has been done
explicitly in this patch.

Bootstraps and regtests on FC17/x86_64 - OK for trunk and 4.7?

A fix for PRs 53876, 54990 and 54992 is on its way, as soon as I am
back from getting some groceries :-)

Cheers

Paul

2013-01-02   Paul Thomas  

PR fortran/55172
* match.c (copy_ts_from_selector_to_associate): Remove call to
gfc_resolve_expr and replace it with explicit setting of the
array reference type.

2013-01-02   Paul Thomas  

PR fortran/55172
* gfortran.dg/select_type_31.f03: New test.


pr55172.diff
Description: Binary data

Re: [PR libmudflap/53359] don't register symbols not emitted

[Richard Biener]

On Sun, Dec 30, 2012 at 1:22 AM, Alexandre Oliva  wrote:
> On Dec 21, 2012, Richard Biener  wrote:
>
>> On Fri, Dec 21, 2012 at 6:33 AM, Alexandre Oliva  wrote:
>>> libmudflap emits a global initializer that registers memory ranges for
>>> global data symbols.  However, even if IPA decides not to emit a symbol
>>> because it's unused, we'd still emit registration sequences for them in
>>> some cases, which, in the PR testcase, would result in TOC references to
>>> the undefined symbols.
>
>> Hmm, I think that at this point of the compilation you are looking for
>> TREE_ASM_WRITTEN instead.
>
> That doesn't work, several mudflap regressions show up because accesses
> to global library symbols that are accessed by template methods compiled
> with mudflap (say cout) are then verified but not registered.  We have
> to register symbols that are not emitted but that referenced.

Ehm, how can something be not emitted but still referenced?  You mean if
it's external?  So maybe

  if (!TREE_ASM_WRITTEN (obj) || DECL_EXTERNAL (obj))

instead?

Thanks,
Richard.

> I've now updated the comment to reflect this.
>
> Is this ok to install?  Regstrapped again (along with the patches for
> feraiseexcept, since there weren't any non-comment changes here) on
> x86_64-linux-gnu and i686-linux-gnu.
>
>
>
>
> --
> Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
> You must be the change you wish to see in the world. -- Gandhi
> Be Free! -- http://FSFLA.org/   FSF Latin America board member
> Free Software Evangelist  Red Hat Brazil Compiler Engineer
>

Re: [Patch, fortran] [4.7/4.8 Regression] [OOP] ICE on invalid: gfc_variable_attr(): Bad array reference

[Tobias Burnus]

Dear Paul,

Paul Richard Thomas wrote:

As noted by Janus in comment #2 of the PR, "I think the function
'copy_ts_from_selector_to_associate' comes too early (namely during
parsing). It tries to resolve the target expr, which should rather
wait until resolution stage!?!"

It turned out that the function of the call to gfc_resolve_expr was to
fix up the selector array reference type.  This has been done
explicitly in this patch.

Bootstraps and regtests on FC17/x86_64 - OK for trunk and 4.7?


It looks mostly okay; however, you do not handle vector sections 
correctly, which leads to an ICE. Without your patch, one gets:
   Error: CLASS selector at (1) needs a temporary which is not yet 
implemented


With your patch, it fails as one has:
(gdb) p ref->next->u.ar.type
$7 = AR_ELEMENT

(gdb) p ref->next->u.ar.dimen_type
$8 = {DIMEN_VECTOR, 0, 0, 0, 0, 0, 0}

Please fix the DIMEN_VECTOR handling and add a test case for it (e.g. 
the one below). Could you also check whether we have a PR for that "not 
yet implemented" error?


module gn
  type :: ncb
  end type ncb
  type, public :: tn
 class(ncb), allocatable, dimension(:) :: cb
  end type tn
contains
  integer function name(self)
implicit none
class (tn), intent(in) :: self
select type (component => self%cb([4,7+1]))
end select
  end function name
end module gn


I am not quite sure whether the following ICE has the same cause or a 
different one, but it also ICEs with your patch applied:


module gn
  type :: ncb
  end type ncb
  type, public :: tn
 class(ncb), allocatable :: cb[:]
  end type tn
contains
  integer function name(self)
implicit none
class (tn), intent(in) :: self
select type (component => self%cb[4])
! ALSO FAILS: "(component => self%cb)"
end select
  end function name
end module gn



Tobias

Re: RFA: Fix ICE on PARALLEL returns when expand builtins

[Richard Biener]

On Sun, Dec 23, 2012 at 10:43 AM, Richard Sandiford
 wrote:
> Some of the maths builtins can expand to a call followed by a bit
> of postprocessing.  With 4.8's PARALLEL return optimisations, these
> embedded calls might return a PARALLEL of pseudos, but the postprocessing
> isn't prepared to deal with that.  This leads to an ICE in builtins-53.c
> on n32 and n64 mips64-linux-gnu.
>
> One fix might have been to pass an explicit register target to the
> expand routines, but that target's only a hint.  This patch instead
> adds an avoid_group_rtx function (named after gen_group_rtx) to convert
> PARALLELs to pseudos where necessary.
>
> I wondered whether it was really safe for expand_builtin_int_roundingfn_2
> to pass "target == const0_rtx" as the "ignore" parameter to expand_call,
> given that we don't actually ignore the return value ourselves
> (even if the caller does).  I suppose it is safe though,
> since expand_call will always return const0_rtx in that case,
> and this code is dealing with integer return values.
>
> Tested on mips64-linux-gnu.  OK to install?  Or is there a better way?

You didn't add a testcase so I can't check myself - but why isn't
using force_reg enough here?  I can imagine other cases than PARALLELs
that are not well handled, no?

Thanks,
Richard.

> Richard
>
>
> gcc/
> * expr.h (avoid_group_rtx): Declare.
> * expr.c (avoid_group_rtx): New function.
> * builtins.c (expand_builtin_int_roundingfn): Call it.
> (expand_builtin_int_roundingfn_2): Likewise.
>
> Index: gcc/expr.h
> ===
> --- gcc/expr.h  2012-12-23 09:21:21.969086853 +
> +++ gcc/expr.h  2012-12-23 09:32:03.487440220 +
> @@ -334,6 +334,8 @@ extern rtx emit_group_move_into_temps (r
> PARALLEL.  */
>  extern void emit_group_store (rtx, rtx, tree, int);
>
> +extern rtx avoid_group_rtx (rtx, tree);
> +
>  /* Copy BLKmode object from a set of registers.  */
>  extern void copy_blkmode_from_reg (rtx, rtx, tree);
>
> Index: gcc/expr.c
> ===
> --- gcc/expr.c  2012-12-23 09:21:21.980086911 +
> +++ gcc/expr.c  2012-12-23 09:32:03.485440208 +
> @@ -2079,6 +2079,23 @@ emit_group_store (rtx orig_dst, rtx src,
>  emit_move_insn (orig_dst, dst);
>  }
>
> +/* Return a form of X that does not use a PARALLEL.  TYPE is the type
> +   of the value stored in X.  */
> +
> +rtx
> +avoid_group_rtx (rtx x, tree type)
> +{
> +  enum machine_mode mode = TYPE_MODE (type);
> +  gcc_checking_assert (GET_MODE (x) == VOIDmode || GET_MODE (x) == mode);
> +  if (GET_CODE (x) == PARALLEL)
> +{
> +  rtx result = gen_reg_rtx (mode);
> +  emit_group_store (result, x, type, int_size_in_bytes (type));
> +  return result;
> +}
> +  return x;
> +}
> +
>  /* Copy a BLKmode object of TYPE out of a register SRCREG into TARGET.
>
> This is used on targets that return BLKmode values in registers.  */
> Index: gcc/builtins.c
> ===
> --- gcc/builtins.c  2012-12-23 09:21:21.981086916 +
> +++ gcc/builtins.c  2012-12-23 09:34:47.813323158 +
> @@ -2757,6 +2757,7 @@ expand_builtin_int_roundingfn (tree exp,
>exp = build_call_nofold_loc (EXPR_LOCATION (exp), fallback_fndecl, 1, arg);
>
>tmp = expand_normal (exp);
> +  tmp = avoid_group_rtx (tmp, TREE_TYPE (exp));
>
>/* Truncate the result of floating point optab to integer
>   via expand_fix ().  */
> @@ -2860,6 +2861,7 @@ expand_builtin_int_roundingfn_2 (tree ex
>fallback_fndecl, 1, arg);
>
>target = expand_call (exp, NULL_RTX, target == const0_rtx);
> +  target = avoid_group_rtx (target, TREE_TYPE (exp));
>return convert_to_mode (mode, target, 0);
>  }
>

Re: [patch][RFC] bail out after front-end errors

[Richard Biener]

On Fri, Dec 28, 2012 at 6:35 PM, Steven Bosscher  wrote:
> On Tue, Mar 27, 2012 at 10:59 AM, Richard Guenther wrote:
>> On Tue, Mar 27, 2012 at 10:32 AM, Steven Bosscher  wrote:
>>> On Tue, Mar 27, 2012 at 9:17 AM, Richard Guenther wrote:
 It would be nice to finally move
 the call to cgraph_finalize_compilation_unit to the middle-end ...
 (warning, if you try that you run into an issue with the Java frontend ... 
 :/)
>>>
>>> Do you remember what issues that causes? I'm running into a great
>>> number of issues there already with some varasm fixes (basically just
>>> cleanups for the tree-ssa and unit-at-a-time era we're supposed to
>>> live in - except Java).
>>
>> I think it was the
>>
>>   /* Generate hidden aliases for Java.  */
>>   if (candidates)
>> {
>>   build_java_method_aliases (candidates);
>>   pointer_set_destroy (candidates);
>> }
>>
>> hunk in cp_write_global_declarations that does not work when run
>> before cgraph_finalize_compilation_unit
>> (I simply tried to move that call out of, and after calling the
>> langhook).  So the problem materialized when
>> building libjava I think.
>
> Hello,
>
> Coming back to this issue...  Attached patch is an attempt to resolve
> this part of the finalize_compilation_unit problem. Instead of
> emitting aliases with assemble_alias after finalize_compilation_unit,
> this patch uses cgraph_same_body_alias before it.
>
> Bootstrapped&tested on powerpc64-unknown-linux-gnu.
> Richi, Honza, does this make sense?

Looks sensible to me.  In theory it should even allow more optimizations
this way ...

Of course it looks like stage1 material.

Thanks,
Richard.

> Ciao!
> Steven
>
> cp/
> * decl2.c (collect_candidates_for_java_method_aliases): Remove.
> (build_java_method_aliases): Rewrite to emit the aliases via the
> cgraphunit machinery.
> (cp_write_global_declarations): Adjust for abovementioned changes.
>
> Index: cp/decl2.c
> ===
> --- cp/decl2.c  (revision 194725)
> +++ cp/decl2.c  (working copy)
> stevenb@stevenb-laptop:~$ cat devel/java_method_aliases.diff
> cp/
> * decl2.c (collect_candidates_for_java_method_aliases): Remove.
> (build_java_method_aliases): Rewrite to emit the aliases via the
> cgraphunit machinery.
> (cp_write_global_declarations): Adjust for abovementioned changes.
>
> Index: cp/decl2.c
> ===
> --- cp/decl2.c  (revision 194725)
> +++ cp/decl2.c  (working copy)
> @@ -3615,79 +3615,53 @@ generate_ctor_and_dtor_functions_for_priority (spl
>
>  /* Java requires that we be able to reference a local address for a
> method, and not be confused by PLT entries.  If hidden aliases are
> -   supported, collect and return all the functions for which we should
> +   supported, emit one for each java function that we've emitted.
> emit a hidden alias.  */
>
> -static struct pointer_set_t *
> -collect_candidates_for_java_method_aliases (void)
> +static void
> +build_java_method_aliases (void)
>  {
> +#ifdef HAVE_GAS_HIDDEN
>struct cgraph_node *node;
> -  struct pointer_set_t *candidates = NULL;
> +  tree fndecl;
> +  vec candidates = vNULL;
> +  unsigned int ix;
>
> -#ifndef HAVE_GAS_HIDDEN
> -  return candidates;
> -#endif
> -
> +  /* First collect all candidates.  We cannot create the aliases
> + in place, it confuses the FOR_EACH_FUNCTION iterator.  */
>FOR_EACH_FUNCTION (node)
>  {
> -  tree fndecl = node->symbol.decl;
> -
> +  fndecl = node->symbol.decl;
>if (DECL_CONTEXT (fndecl)
>   && TYPE_P (DECL_CONTEXT (fndecl))
>   && TYPE_FOR_JAVA (DECL_CONTEXT (fndecl))
>   && TARGET_USE_LOCAL_THUNK_ALIAS_P (fndecl))
> -   {
> - if (candidates == NULL)
> -   candidates = pointer_set_create ();
> - pointer_set_insert (candidates, fndecl);
> -   }
> +   candidates.safe_push (fndecl);
>  }
>
> -  return candidates;
> -}
> -
> -
> -/* Java requires that we be able to reference a local address for a
> -   method, and not be confused by PLT entries.  If hidden aliases are
> -   supported, emit one for each java function that we've emitted.
> -   CANDIDATES is the set of FUNCTION_DECLs that were gathered
> -   by collect_candidates_for_java_method_aliases.  */
> -
> -static void
> -build_java_method_aliases (struct pointer_set_t *candidates)
> -{
> -  struct cgraph_node *node;
> -
> -#ifndef HAVE_GAS_HIDDEN
> -  return;
> -#endif
> -
> -  FOR_EACH_FUNCTION (node)
> +  /* Now add the aliases for the candidates collected above.
> + Mangle the name in a predictable way; we need to reference
> + this from a java compiled object file.  */
> +  FOR_EACH_VEC_ELT (candidates, ix, fndecl)
>  {
> -  tree fndecl = node->symbol.decl;
> +  tree oid, nid, alias;
> +  const char *oname;
> +  char *nname;
>
> -  if (TREE_A

[PATCH] Fix PR55848

[Richard Biener]

This fixes PR55848, when doing LTO symtab merging as last resort
we should prefer a built-in decl if one is available as we are
not replacing its cgraph node.

Note, we still prefer a prevailing definition over a built-in
(which IMHO is good).

LTO bootstrap and regtest pending on x86_64-unknown-linux-gnu.

Richard.

2013-01-02  Richard Biener  

PR lto/55848
* lto-symtab.c (lto_symtab_merge_decls_1): As last resort, always
prefer a built-in decl.

Index: gcc/lto-symtab.c
===
*** gcc/lto-symtab.c(revision 194787)
--- gcc/lto-symtab.c(working copy)
*** lto_symtab_merge_decls_1 (symtab_node fi
*** 439,444 
--- 439,454 
&& COMPLETE_TYPE_P (TREE_TYPE (e->symbol.decl)))
  prevailing = e;
}
+   /* For variables prefer the builtin if one is available.  */
+   else if (TREE_CODE (prevailing->symbol.decl) == FUNCTION_DECL)
+   {
+ for (e = first; e; e = e->symbol.next_sharing_asm_name)
+   if (DECL_BUILT_IN (e->symbol.decl))
+ {
+   prevailing = e;
+   break;
+ }
+   }
  }
  
symtab_prevail_in_asm_name_hash (prevailing);

Re: [PATCH] Use new dump scheme to emit loop unroll/peel summary info (issue6941070)

[Teresa Johnson]

On Thu, Dec 20, 2012 at 9:20 AM, Teresa Johnson  wrote:
> On Thu, Dec 20, 2012 at 1:21 AM, Bernhard Reutner-Fischer
>  wrote:
>
> Thanks for your comments. Responses inlined below, and new patch include 
> below.
>
>> On Mon, Dec 17, 2012 at 10:44:59PM -0800, Teresa Johnson wrote:
>>>Index: tree-ssa-loop-ivcanon.c
>>>===
>>>--- tree-ssa-loop-ivcanon.c(revision 194516)
>>>+++ tree-ssa-loop-ivcanon.c(working copy)
>>>@@ -639,22 +639,24 @@ unloop_loops (bitmap loop_closed_ssa_invalidated,
>>>
>>> /* Tries to unroll LOOP completely, i.e. NITER times.
>>>UL determines which loops we are allowed to unroll.
>>>-   EXIT is the exit of the loop that should be eliminated.
>>>+   EXIT is the exit of the loop that should be eliminated.
>>>MAXITER specfy bound on number of iterations, -1 if it is
>>>-   not known or too large for HOST_WIDE_INT.  */
>>>+   not known or too large for HOST_WIDE_INT. The location
>>>+   LOCUS corresponding to the loop is used when emitting
>>>+   a summary of the unroll to the dump file.  */
>>>
>>> static bool
>>> try_unroll_loop_completely (struct loop *loop,
>>>   edge exit, tree niter,
>>>   enum unroll_level ul,
>>>-  HOST_WIDE_INT maxiter)
>>>+  HOST_WIDE_INT maxiter,
>>>+location_t locus)
>>
>> whitespace damage?
>
> This and the other location you pointed out below as possible
> whitespace damage are because the surrounding lines use tab characters
> whereas mine uses spaces. Is there a guideline on which one is correct
> for gcc? I looked in the style guide but didn't find anything. The
> existing code uses a mix of indentation via tabs and spaces. I have
> fixed this location and the one you point out below to use a tab
> character so that the diff goes away, but I haven't searched the patch
> exhaustively for similar issues.
>
>>
>>>Index: loop-unroll.c
>>>===
>>>--- loop-unroll.c  (revision 194516)
>>>+++ loop-unroll.c  (working copy)
>>>@@ -148,6 +148,61 @@ static void combine_var_copies_in_loop_exit (struc
>>>basic_block);
>>> static rtx get_expansion (struct var_to_expand *);
>>>
>>>+/* Emit a message summarizing the unroll or peel that will be
>>>+   performed for LOOP, along with the loop's location LOCUS, if
>>>+   appropriate given the dump or -fopt-info settings.  */
>>>+
>>>+static void
>>>+report_unroll_peel(struct loop *loop, location_t locus)
>>
>> missing space before (
>>
>> contrib/check_GNU_style.sh generally says:
>> Dot, space, space, new sentence.
>> loop-dump.01.patch:223:+   not known or too large for HOST_WIDE_INT. The 
>> location
>> loop-dump.01.patch:514:+   * of the for or while statement, if possible. To 
>> do this, look
>>
>> Dot, space, space, end of comment.
>> loop-dump.01.patch:504:+/* Return location corresponding to the loop control 
>> condition if possible. */
>> loop-dump.01.patch:541:+  /* Next check the latch, to see if it is 
>> non-empty. *
>> loop-dump.01.patch:555:+  /* If all else fails, simply return the current 
>> function location. */
>>
>> There should be exactly one space between function name and parentheses.
>> loop-dump.01.patch:329:+report_unroll_peel(struct loop *loop, location_t 
>> locus)
>> loop-dump.01.patch:386:+  location_t locus = get_loop_location(loop);
>> loop-dump.01.patch:404:+  report_unroll_peel(loop, locus);
>> loop-dump.01.patch:412:+  location_t locus = get_loop_location(loop);
>> loop-dump.01.patch:429:+  report_unroll_peel(loop, locus);
>> loop-dump.01.patch:533:+  if ((exit = single_exit(loop)))
>
> I fixed all these and verified that check_GNU_style.sh no longer reports 
> these.
>
>>
>>>@@ -248,6 +305,7 @@ peel_loops_completely (int flags)
>>>
>>>   if (loop->lpt_decision.decision == LPT_PEEL_COMPLETELY)
>>>   {
>>>+  report_unroll_peel(loop, locus);
>>> peel_loop_completely (loop);
>>
>> whitespace damage? You seem to have this kind of whitespace error
>> throughout the patch. I take it you are aware of
>> http://gcc.gnu.org/wiki/FormattingCodeForGCC
>> and just forgot to have it on the machine you edited?
>
> This was the same issue described above (tab vs space). As noted
> above, I fixed this instance too, but there may be others and I'm not
> sure what is required or correct.
>
>>
>> I seemingly have
>> $ cat ~/.vim/gcc_style.vim
>> " put this plugin into ~/.vim/gcc_style.vim and source it into your ~/.vimrc 
>> via
>> " source ~/.vim/gcc_style.vim
>> if exists("g:loaded_gcc_style") || &cp
>>   finish
>> endif
>> let g:loaded_gcc_style = 1
>>
>> augroup gcc_style
>>   autocmd BufReadPost,FileReadPost * call s:maybe_gcc_style()
>> augroup END
>> if exists("*s:maybe_gcc_style")
>>   finish
>> endif
>> let s:cpo_save = &cpo
>> set cpo&vim
>>

RE: [AArch64] Fix some warnings about unused variables.

[James Greenhalgh]

> OK.
> 
> R.

Thanks Richard,

I've also backported this to aarch64-4.7-branch and committed
it as revision 194808.

Cheers,
James Greenhalgh

Re: [patch, libgfortran] PR55818 Reading a REAL from a file which doesn't end in a new line fails

[Jerry DeLisle]

On 01/02/2013 01:00 AM, Tobias Burnus wrote:

Jerry DeLisle wrote:

This updated patch addresses the issues with infinities, nans, characters, and
valid reals.

And complex.


OK for trunk?
Test case attached.


Thanks for the patch. It looks okay (with a ChangeLog).


ChangeLog created



However, I found yet another case which is not handled, namely reals with
exponentials such as "1.0e3". Hopefully, we have then covered all cases.




Missed one spot for exponents, trivial, fixed, and added to test case.

Also added logical kind to test case. (It was already addressed in the patch)

I will commit after one more full regression test.

Thanks for review.

Jerry

Re: RFA: Fix ICE on PARALLEL returns when expand builtins

[Richard Sandiford]

Richard Biener  writes:
> On Sun, Dec 23, 2012 at 10:43 AM, Richard Sandiford
>  wrote:
>> Some of the maths builtins can expand to a call followed by a bit
>> of postprocessing.  With 4.8's PARALLEL return optimisations, these
>> embedded calls might return a PARALLEL of pseudos, but the postprocessing
>> isn't prepared to deal with that.  This leads to an ICE in builtins-53.c
>> on n32 and n64 mips64-linux-gnu.
>>
>> One fix might have been to pass an explicit register target to the
>> expand routines, but that target's only a hint.  This patch instead
>> adds an avoid_group_rtx function (named after gen_group_rtx) to convert
>> PARALLELs to pseudos where necessary.
>>
>> I wondered whether it was really safe for expand_builtin_int_roundingfn_2
>> to pass "target == const0_rtx" as the "ignore" parameter to expand_call,
>> given that we don't actually ignore the return value ourselves
>> (even if the caller does).  I suppose it is safe though,
>> since expand_call will always return const0_rtx in that case,
>> and this code is dealing with integer return values.
>>
>> Tested on mips64-linux-gnu.  OK to install?  Or is there a better way?
>
> You didn't add a testcase so I can't check myself

It's gcc.dg/builtins-53.c.

> - but why isn't using force_reg enough here?  I can imagine other
> cases than PARALLELs that are not well handled, no?

Not sure either way TBH.  Fortunately expanding your own calls seems
to be pretty rare.

But yeah, having force_reg (or I suppose force_operand) do it sounds
good in principle.  The problem is that the operation needs the type
tree, which the force_* routines don't have.

Richard

Re: [PATCH] Use new dump scheme to emit loop unroll/peel summary info (issue6941070)

[Richard Henderson]

On 12/17/2012 10:44 PM, Teresa Johnson wrote:
> 2012-12-17  Teresa Johnson  
> 
>   * dumpfile.c (dump_loc): Print filename with location.
>   * tree-ssa-loop-ivcanon.c (try_unroll_loop_completely): Use
> new location_t parameter to emit complete unroll message with
> new dump framework.
>   (canonicalize_loop_induction_variables): Compute loops location
> and pass to try_unroll_loop_completely.
>   * loop-unroll.c (report_unroll_peel): New function.
>   (peel_loops_completely): Use new dump format with location
> for main dumpfile message, and invoke report_unroll_peel on success.
>   (decide_unrolling_and_peeling): Ditto.
>   (decide_peel_once_rolling): Remove old dumpfile message subsumed
> by report_unroll_peel.
>   (decide_peel_completely): Ditto.
>   (decide_unroll_constant_iterations): Ditto.
>   (decide_unroll_runtime_iterations): Ditto.
>   (decide_peel_simple): Ditto.
>   (decide_unroll_stupid): Ditto.
>   * cfgloop.c (get_loop_location): New function.
>   * cfgloop.h (get_loop_location): Declare.
> 
> testsuite/
>   * gcc.dg/tree-ssa/loop-1.c: Update expected dump message.
>   * gcc.dg/tree-ssa/loop-23.c: Ditto.
>   * gcc.dg/tree-ssa/cunroll-1.c: Ditto.
>   * gcc.dg/tree-ssa/cunroll-2.c: Ditto.
>   * gcc.dg/tree-ssa/cunroll-3.c: Ditto.
>   * gcc.dg/tree-ssa/cunroll-4.c: Ditto.
>   * gcc.dg/tree-ssa/cunroll-5.c: Ditto.
>   * testsuite/gcc.dg/unroll_1.c:
>   * testsuite/gcc.dg/unroll_2.c:
>   * testsuite/gcc.dg/unroll_3.c:
>   * testsuite/gcc.dg/unroll_4.c:

Ok except,

> -  if (!single_exit (loop))
> +  if (!(exit = single_exit (loop)))

Avoid nested assignment when its easy, as it is in this case.


r~

Re: [PATCH] Fix handling of EXPAND_MEMORY for TFmode memory constraint in asm

[Richard Henderson]

On 12/01/2012 02:46 PM, John David Anglin wrote:
>   PR middle-end/55198
>   * expr.c (expand_expr_real_1): Don't use bitfield extraction for non
>   BLKmode objects when EXPAND_MEMORY is specified.

Ok.


r~

Re: [PATCH] Fix up compat.exp C testing

[Mike Stump]

On Jan 2, 2013, at 4:58 AM, Jakub Jelinek  wrote:
> Anyway, this fixes the most urgent issue.  Ok for trunk?

Ok.  If you find any breakage in the patch and need to fix it, ok for that as 
well.  :-o

For a fun time, compat testing clang and gcc would be a curious test.

> 2013-01-02  Jakub Jelinek  
> 
>   * lib/c-compat.exp (compat-use-alt-compiler): Remove
>   -fno-diagnostics-show-caret from TEST_ALWAYS_FLAGS if needed.
>   (compat-use-tst-compiler): Restore TEST_ALWAYS_FLAGS.
>   (compat_setup_dfp): Initialize compat_alt_caret and
>   compat_save_TEST_ALWAYS_FLAGS.

C++ PATCH for c++/55804 (missing ctor call)

[Jason Merrill]

My earlier patch to force layout when re-building an array type caused 
problems because we weren't setting TYPE_NEEDS_CONSTRUCTING at the same 
time.  So this attacks the problem in a different way: the underlying 
issue here is that we're attaching a variant (which has been laid out) 
to a previously built main variant (which hasn't).  So now, when we do 
that we make sure to copy the layout information to the older variants.


Tested x86_64-pc-linux-gnu, applying to trunk, 4.7 and 4.6.
commit 953241f451c969981f4fdecd9cdf90b133ada6d2
Author: Jason Merrill 
Date:   Wed Jan 2 09:53:19 2013 -0500

	PR c++/55804
	PR c++/55032
	PR c++/55245
	* tree.c (build_array_type_1): Revert earlier change.
	* cp/tree.c (build_cplus_array_type): Copy layout information
	to main variant if necessary.

diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index c430237..c658582 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -809,6 +809,15 @@ build_cplus_array_type (tree elt_type, tree index_type)
   t = build_array_type (elt_type, index_type);
 }
 
+  /* Push these needs up so that initialization takes place
+ more easily.  */
+  bool needs_ctor
+= TYPE_NEEDS_CONSTRUCTING (TYPE_MAIN_VARIANT (elt_type));
+  TYPE_NEEDS_CONSTRUCTING (t) = needs_ctor;
+  bool needs_dtor
+= TYPE_HAS_NONTRIVIAL_DESTRUCTOR (TYPE_MAIN_VARIANT (elt_type));
+  TYPE_HAS_NONTRIVIAL_DESTRUCTOR (t) = needs_dtor;
+
   /* We want TYPE_MAIN_VARIANT of an array to strip cv-quals from the
  element type as well, so fix it up if needed.  */
   if (elt_type != TYPE_MAIN_VARIANT (elt_type))
@@ -818,6 +827,27 @@ build_cplus_array_type (tree elt_type, tree index_type)
 
   if (TYPE_MAIN_VARIANT (t) != m)
 	{
+	  if (COMPLETE_TYPE_P (t) && !COMPLETE_TYPE_P (m))
+	{
+	  /* m was built before the element type was complete, so we
+		 also need to copy the layout info from t.  */
+	  tree size = TYPE_SIZE (t);
+	  tree size_unit = TYPE_SIZE_UNIT (t);
+	  unsigned int align = TYPE_ALIGN (t);
+	  unsigned int user_align = TYPE_USER_ALIGN (t);
+	  enum machine_mode mode = TYPE_MODE (t);
+	  for (tree var = m; var; var = TYPE_NEXT_VARIANT (var))
+		{
+		  TYPE_SIZE (var) = size;
+		  TYPE_SIZE_UNIT (var) = size_unit;
+		  TYPE_ALIGN (var) = align;
+		  TYPE_USER_ALIGN (var) = user_align;
+		  SET_TYPE_MODE (var, mode);
+		  TYPE_NEEDS_CONSTRUCTING (var) = needs_ctor;
+		  TYPE_HAS_NONTRIVIAL_DESTRUCTOR (var) = needs_dtor;
+		}
+	}
+
 	  TYPE_MAIN_VARIANT (t) = m;
 	  TYPE_NEXT_VARIANT (t) = TYPE_NEXT_VARIANT (m);
 	  TYPE_NEXT_VARIANT (m) = t;
@@ -828,12 +858,6 @@ build_cplus_array_type (tree elt_type, tree index_type)
   if (TYPE_SIZE (t) && EXPR_P (TYPE_SIZE (t)))
 TREE_NO_WARNING (TYPE_SIZE (t)) = 1;
 
-  /* Push these needs up so that initialization takes place
- more easily.  */
-  TYPE_NEEDS_CONSTRUCTING (t)
-= TYPE_NEEDS_CONSTRUCTING (TYPE_MAIN_VARIANT (elt_type));
-  TYPE_HAS_NONTRIVIAL_DESTRUCTOR (t)
-= TYPE_HAS_NONTRIVIAL_DESTRUCTOR (TYPE_MAIN_VARIANT (elt_type));
   return t;
 }
 
diff --git a/gcc/testsuite/g++.dg/init/array33.C b/gcc/testsuite/g++.dg/init/array33.C
new file mode 100644
index 000..4440d3d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/init/array33.C
@@ -0,0 +1,22 @@
+// PR c++/55804
+// { dg-do run }
+
+int t = 0;
+template  struct vector {
+  vector() { t++; }
+};
+
+typedef vector Arrays[1];
+class C
+{
+vector v_;
+void Foo(const Arrays &);
+};
+Arrays a;
+
+int main(void)
+{
+  if (t!=1)
+__builtin_abort ();
+  return 0;
+}
diff --git a/gcc/tree.c b/gcc/tree.c
index 429db49..7cacb2a 100644
--- a/gcc/tree.c
+++ b/gcc/tree.c
@@ -7505,12 +7505,7 @@ build_array_type_1 (tree elt_type, tree index_type, bool shared)
   hashval_t hashcode = iterative_hash_object (TYPE_HASH (elt_type), 0);
   if (index_type)
 	hashcode = iterative_hash_object (TYPE_HASH (index_type), hashcode);
-  tree old_t = t;
   t = type_hash_canon (hashcode, t);
-  if (t != old_t)
-	/* Lay it out again in case the element type has been completed since
-	   the array was added to the hash table.  */
-	layout_type (t);
 }
 
   if (TYPE_CANONICAL (t) == t)

Re: [committed] Fix ICE in gen_reg_rtx, at emit-rtl.c:864/865 compiling GNU MPFR

[Richard Henderson]

On 01/02/2013 05:12 AM, Richard Sandiford wrote:
>   * gcc.dg/torture/tls/tls-reload-1.c: New test.

Ok.


r~

Re: [committed] Fix ICE in gen_reg_rtx, at emit-rtl.c:864/865 compiling GNU MPFR

[Richard Sandiford]

Richard Henderson  writes:
> On 01/02/2013 05:12 AM, Richard Sandiford wrote:
>>  * gcc.dg/torture/tls/tls-reload-1.c: New test.
>
> Ok.

Thanks, committed.  And sorry for not volunteering a patch for the x86 ICE,
but I barely know the port...

Richard

C++ PATCH for KDE default argument issue

[Jason Merrill]

Jakub sent me a testcase from KDE that has started failing since my 
change to how default argument conversions are checked; we were ignoring 
'explicit' when considering applicable conversions.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit 31f87e04a3bcdfe18c2672fe9725d96117a95031
Author: Jason Merrill 
Date:   Wed Jan 2 14:14:24 2013 -0500

	* decl.c (check_default_argument): Use LOOKUP_IMPLICIT.

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 64bd4b5..52ceefc 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -10829,7 +10829,7 @@ check_default_argument (tree decl, tree arg)
  parameter type.  */
   ++cp_unevaluated_operand;
   perform_implicit_conversion_flags (decl_type, arg, tf_warning_or_error,
- LOOKUP_NORMAL);
+ LOOKUP_IMPLICIT);
   --cp_unevaluated_operand;
 
   if (warn_zero_as_null_pointer_constant
diff --git a/gcc/testsuite/g++.dg/overload/defarg7.C b/gcc/testsuite/g++.dg/overload/defarg7.C
new file mode 100644
index 000..8cc08f5
--- /dev/null
+++ b/gcc/testsuite/g++.dg/overload/defarg7.C
@@ -0,0 +1,12 @@
+struct A
+{
+  A(const char *);
+  explicit A(const int *);
+};
+
+void f (A a = 0);
+
+int main()
+{
+  f();
+}

Re: [PATCH] Support OpenMP for task parallelism on Android-ICS/GCC-4.7.2

[Richard Henderson]

On 12/26/2012 04:39 PM, Geunsik Lim wrote:
> diff --git a/gcc-4.7/gcc/config/linux-android.h 
> b/gcc-4.7/gcc/config/linux-android.h
> index 033cfef..c6d9cdd 100644
> --- a/gcc-4.7/gcc/config/linux-android.h
> +++ b/gcc-4.7/gcc/config/linux-android.h
> @@ -53,7 +53,8 @@
>"--noexecstack"
>  
>  #define ANDROID_LIB_SPEC \
> -  "%{!static: -ldl}"
> +  "%{!static: -ldl}" \
> +  "%{pthread:-lc}"
>  
...
> diff --git a/gcc-4.7/libgomp/configure.ac b/gcc-4.7/libgomp/configure.ac
> index d87ed29..292db2a 100644
> --- a/gcc-4.7/libgomp/configure.ac
> +++ b/gcc-4.7/libgomp/configure.ac
> @@ -184,6 +184,13 @@ AC_LINK_IFELSE(
> void *g(void *d) { return NULL; }],
>[pthread_t t; pthread_create(&t,NULL,g,NULL);])],
>   [XPCFLAGS=" -Wc,-pthread"],
> + [CFLAGS="$save_CFLAGS" LIBS="$LIBS"
> +  AC_LINK_IFELSE(
> +   [AC_LANG_PROGRAM(
> +[#include 
> + void *g(void *d) { return NULL; }],
> +[pthread_t t; pthread_create(&t,NULL,g,NULL);])],
> +   [],
>   [CFLAGS="$save_CFLAGS" LIBS="-lpthread $LIBS"
>AC_LINK_IFELSE(
> [AC_LANG_PROGRAM(
> @@ -191,7 +198,7 @@ AC_LINK_IFELSE(
>   void *g(void *d) { return NULL; }],
>  [pthread_t t; pthread_create(&t,NULL,g,NULL);])],
> [],
> -   [AC_MSG_ERROR([Pthreads are required to build libgomp])])])
> +   [AC_MSG_ERROR([Pthreads are required to build libgomp])])])])

Why do you need this change to configure.ac?

It sure looks as if the linux-android.h patch
makes the -pthread gcc parameter DTRT, and the
first existing test here is configure.ac will
default to using -pthread.

> --- a/gcc-4.7/libgomp/env.c
> +++ b/gcc-4.7/libgomp/env.c
> @@ -44,6 +44,7 @@
>  #endif
>  #include 
>  #include 
> +#include 

This isn't correct.  What declaration are you after?


r~

Re: [PATCH] Function Multiversioning Bug, checking for function versions

[Sriraman Tallam]

I committed this trivial patch to fix some corner case bugs in
Function Multiversioning.

* config/i386/i386.c (ix86_get_function_versions_dispatcher): Fix bug
in loop predicate.
(fold_builtin_cpu): Do not share cpu model decls across statements.

Index: config/i386/i386.c
===
--- config/i386/i386.c  (revision 194817)
+++ config/i386/i386.c  (working copy)
@@ -29290,7 +29290,7 @@ ix86_get_function_versions_dispatcher (void *decl)

   /* Set the dispatcher for all the versions.  */
   it_v = default_version_info;
-  while (it_v->next != NULL)
+  while (it_v != NULL)
 {
   it_v->dispatcher_resolver = dispatch_decl;
   it_v = it_v->next;
@@ -29626,8 +29626,8 @@ fold_builtin_cpu (tree fndecl, tree *args)
   {"avx2",   F_AVX2}
 };

-  static tree __processor_model_type = NULL_TREE;
-  static tree __cpu_model_var = NULL_TREE;
+  tree __processor_model_type = NULL_TREE;
+  tree __cpu_model_var = NULL_TREE;

   if (__processor_model_type == NULL_TREE)
 __processor_model_type = build_processor_model_struct ();



Thanks,
-Sri.

On Thu, Dec 27, 2012 at 2:05 AM, Andreas Schwab  wrote:
> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> index 148388d..575e03a 100644
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1,4 +1,7 @@
> -<<< .mine
> +2012-12-27  Andreas Schwab  
> +
> +   * target.def (supports_function_versions): Fix typo.
> +
>  2012-12-26  Sriraman Tallam  
>
> * doc/tm.texi.in (TARGET_OPTION_SUPPORTS_FUNCTION_VERSIONS): Document
> @@ -15,12 +18,10 @@
> * (is_function_default_version): Check target string.
> * TARGET_OPTION_SUPPORTS_FUNCTION_VERSIONS: New macro.
>
> -===
>  2012-12-27  Steven Bosscher  
>
> * cgraph.c (verify_cgraph_node): Don't allocate/free visited_nodes 
> set.
>
> ->>> .r194729
>  2012-12-25  John David Anglin  
>
> PR target/53789
> diff --git a/gcc/target.def b/gcc/target.def
> index 79bb955..d0547be 100644
> --- a/gcc/target.def
> +++ b/gcc/target.def
> @@ -2839,7 +2839,7 @@ DEFHOOK
>  (supports_function_versions,
>   "",
>   bool, (void),
> - hool_bool_void_false)
> + hook_bool_void_false)
>
>  /* Function to determine if one function can inline another function.  */
>  #undef HOOK_PREFIX
> --
> 1.8.0.2
>
>
> --
> Andreas Schwab, sch...@linux-m68k.org
> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> "And now for something completely different."

Re: C++ PATCH for c++/54325 (wrong error initializing abstract base class)

[Jason Merrill]

Fixed thus.  For a user-provided default constructor we don't need to 
play with zeroing the object first, so we can use the normal logic that 
works properly for protected access.


Tested x86_64-pc-linux-gnu, applying to trunk and 4.7.
commit 0ebf6baa1f5f27bd96db44514425075cad2cbd97
Author: Jason Merrill 
Date:   Wed Jan 2 15:31:02 2013 -0500

	PR c++/54325
	* call.c (build_new_method_call_1): Don't use build_value_init for
	user-provided default constructors.

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index bba5d9f..ad39637 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -7534,6 +7534,9 @@ build_new_method_call_1 (tree instance, tree fns, vec **args,
 	 build_special_member_call.  */
   if (CONSTRUCTOR_NELTS (init_list) == 0
 	  && TYPE_HAS_DEFAULT_CONSTRUCTOR (basetype)
+	  /* For a user-provided default constructor, use the normal
+	 mechanisms so that protected access works.  */
+	  && !type_has_user_provided_default_constructor (basetype)
 	  && !processing_template_decl)
 	init = build_value_init (basetype, complain);
 
diff --git a/gcc/testsuite/g++.dg/cpp0x/initlist-protected.C b/gcc/testsuite/g++.dg/cpp0x/initlist-protected.C
new file mode 100644
index 000..fb5cc6a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/initlist-protected.C
@@ -0,0 +1,23 @@
+// PR c++/54325
+// { dg-options -std=c++11 }
+
+class base
+{
+protected:
+base()
+{}
+};
+
+class derived : public base
+{
+public:
+derived()
+: base{} // <-- Note the c++11 curly brace syntax
+{}
+};
+
+int main()
+{
+derived d1;
+return 0;
+}

Re: [PATCH] Function Multiversioning Bug, checking for function versions

[Jakub Jelinek]

On Wed, Jan 02, 2013 at 12:23:45PM -0800, Sriraman Tallam wrote:
> --- config/i386/i386.c  (revision 194817)
> +++ config/i386/i386.c  (working copy)
> @@ -29290,7 +29290,7 @@ ix86_get_function_versions_dispatcher (void *decl)
> 
>/* Set the dispatcher for all the versions.  */
>it_v = default_version_info;
> -  while (it_v->next != NULL)
> +  while (it_v != NULL)
>  {
>it_v->dispatcher_resolver = dispatch_decl;
>it_v = it_v->next;
> @@ -29626,8 +29626,8 @@ fold_builtin_cpu (tree fndecl, tree *args)
>{"avx2",   F_AVX2}
>  };
> 
> -  static tree __processor_model_type = NULL_TREE;
> -  static tree __cpu_model_var = NULL_TREE;
> +  tree __processor_model_type = NULL_TREE;
> +  tree __cpu_model_var = NULL_TREE;
> 
>if (__processor_model_type == NULL_TREE)
>  __processor_model_type = build_processor_model_struct ();

If __processor_model_type is always NULL_TREE above, then you should write
  tree __processor_model_type = build_processor_model_struct ();
rather than the extra if with an always true condition.

Jakub

Re: [Patch, fortran] [4.7/4.8 Regression] [OOP] ICE on invalid: gfc_variable_attr(): Bad array reference

[Paul Richard Thomas]

Dear Tobias,

First of all, thanks for the review!  I still owe you my comments on
FINAL; I got lost in trying to fix these various regressions :-)  I
promise that I'll come back to you first thing tomorrow.

>
> It looks mostly okay; however, you do not handle vector sections correctly,
> which leads to an ICE. Without your patch, one gets:
>Error: CLASS selector at (1) needs a temporary which is not yet
> implemented
>
> With your patch, it fails as one has:

This was fairly easily fixed - see attached.

snip...

> I am not quite sure whether the following ICE has the same cause or a
> different one, but it also ICEs with your patch applied:
>
> module gn
>   type :: ncb
>   end type ncb
>   type, public :: tn
>  class(ncb), allocatable :: cb[:]
>   end type tn
> contains
>   integer function name(self)
> implicit none
> class (tn), intent(in) :: self
> select type (component => self%cb[4])
> ! ALSO FAILS: "(component => self%cb)"
> end select
>   end function name
> end module gn

This co-array example was never OK, as far as I can tell.  The error
is similar to that of the PR.  However, co-arrays were just never
handled at all again, as far as I can tell.  I'll have a go at it
tomorrow night.

With best regards

Paul


pr55172a.diff
Description: Binary data

Re: [PATCH] Function Multiversioning Bug, checking for function versions

[Sriraman Tallam]

On Wed, Jan 2, 2013 at 1:01 PM, Jakub Jelinek  wrote:
> On Wed, Jan 02, 2013 at 12:23:45PM -0800, Sriraman Tallam wrote:
>> --- config/i386/i386.c  (revision 194817)
>> +++ config/i386/i386.c  (working copy)
>> @@ -29290,7 +29290,7 @@ ix86_get_function_versions_dispatcher (void *decl)
>>
>>/* Set the dispatcher for all the versions.  */
>>it_v = default_version_info;
>> -  while (it_v->next != NULL)
>> +  while (it_v != NULL)
>>  {
>>it_v->dispatcher_resolver = dispatch_decl;
>>it_v = it_v->next;
>> @@ -29626,8 +29626,8 @@ fold_builtin_cpu (tree fndecl, tree *args)
>>{"avx2",   F_AVX2}
>>  };
>>
>> -  static tree __processor_model_type = NULL_TREE;
>> -  static tree __cpu_model_var = NULL_TREE;
>> +  tree __processor_model_type = NULL_TREE;
>> +  tree __cpu_model_var = NULL_TREE;
>>
>>if (__processor_model_type == NULL_TREE)
>>  __processor_model_type = build_processor_model_struct ();
>
> If __processor_model_type is always NULL_TREE above, then you should write
>   tree __processor_model_type = build_processor_model_struct ();
> rather than the extra if with an always true condition.

Right, sorry! Oversight in a hurry to fix the bug.

-Sri.

>
> Jakub

Re: [Patch, fortran] [4.7/4.8 Regression] [OOP] ICE on invalid: gfc_variable_attr(): Bad array reference

[Tobias Burnus]

Dear Paul,

First, the new patch is fine from my side. (Although, I think the test 
case should also include the vector-section example.) Thanks for working 
on that regression.



Paul Richard Thomas wrote:

First of all, thanks for the review!  I still owe you my comments on
FINAL; I got lost in trying to fix these various regressions :-)  I
promise that I'll come back to you first thing tomorrow.


I am looking forward to them - and in particular to a patch review of 
the FINAL patches. I am also interested in your comment to my LOGICAL in 
BIND(C) procedures patch, namely 
http://gcc.gnu.org/ml/fortran/2012-12/msg00200.html



It looks mostly okay; however, you do not handle vector sections correctly,
which leads to an ICE. Without your patch, one gets:
Error: CLASS selector at (1) needs a temporary which is not yet
implemented

With your patch, it fails as one has:

This was fairly easily fixed - see attached.


Thanks. By the way, I have filled a PR to track this "not yet 
implemented" issue: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55849




I am not quite sure whether the following ICE has the same cause or a
different one, but it also ICEs with your patch applied:
 select type (component => self%cb[4])

This co-array example was never OK, as far as I can tell. The error
is similar to that of the PR.  However, co-arrays were just never
handled at all again, as far as I can tell.  I'll have a go at it
tomorrow night.


I recall that we did add some coarray support for polymorphic variables. 
At least with coarray arrays (contrary to coarray scalars) it seems to 
compile. But it is very likely that select type never worked with 
coarrays or coarray scalars.


Note that the coindexd

select type (component => self%cb[4])
is invalid (C803; PR55850 (a)). However, the same failure occurs for 
noncoindexed valid selector:
select type (component => self%cb)


(See also PR 55850 for some other SELECT TYPE issues I found.)

Tobias

Re: [RFC PATCH] Implementing ifunc target hook

[Maxim Kuvyrkov]

On 29/12/2012, at 1:30 AM, Alexander Ivchenko wrote:

> Joseph, Maxim, thank you for your input. I converted this macro into
> a target hook as you said. I had to add gcc/config/linux-protos.h in order
> to declare linux (that works for android) version of this hook - otherwise
> I don't know where to declare it..

See notes below on this.  Once you added a new target hook you can call it via 
targetm.(), so references to TARGET_HAS_IFUNC should be replaced with 
calls to targetm.has_ifunc_p().

Sorry, but it will take another iteration or two to make this patch just right. 
 GCC config machinery is tricky, and placing things in the right places is 
non-trivial.

> 
>>> --- a/gcc/config/i386/i386.c
>>> +++ b/gcc/config/i386/i386.c
>>> @@ -29146,7 +29146,7 @@ make_name (tree decl, const char *suffix, bool 
>>> make_unique)
>>>   return global_var_name;
>>> }
>>> 
>>> -#if defined (ASM_OUTPUT_TYPE_DIRECTIVE) && HAVE_GNU_INDIRECT_FUNCTION
>>> +#if defined (ASM_OUTPUT_TYPE_DIRECTIVE)
>>> 
>>> /* Make a dispatcher declaration for the multi-versioned function DECL.
>>>Calls to DECL function will be replaced with calls to the dispatcher
>>> @@ -29213,7 +29213,7 @@ ix86_get_function_versions_dispatcher (void *decl)
>>> 
>>>   tree dispatch_decl = NULL;
>>> 
>>> -#if defined (ASM_OUTPUT_TYPE_DIRECTIVE) && HAVE_GNU_INDIRECT_FUNCTION
>>> +#if defined (ASM_OUTPUT_TYPE_DIRECTIVE)
>>>   struct cgraph_function_version_info *it_v = NULL;
>>>   struct cgraph_node *dispatcher_node = NULL;
>>>   struct cgraph_function_version_info *dispatcher_version_info = NULL;
>> 
>> It seems you can move these variables inside the 'if (TARGET_HAS_IFUNC)' 
>> clause below and make >the code cleaner, no?
> 
> All variable declarations should be at the beginning of the routine.
> Or is it changed right now?

The variable declarations should be at the beginning of a block.  Since you are 
adding a new block below (under if (TARGET_HAS_IFUNC) {  }), and these 
variables are used only within that block, it would be cleaner to move them 
there.

> 
>>> @@ -29263,24 +29263,33 @@ ix86_get_function_versions_dispatcher (void *decl)
>>> 
>>>   default_node = default_version_info->this_node;
>>> 
>>> -#if defined (ASM_OUTPUT_TYPE_DIRECTIVE) && HAVE_GNU_INDIRECT_FUNCTION
>>> -  /* Right now, the dispatching is done via ifunc.  */
>>> -  dispatch_decl = make_dispatcher_decl (default_node->symbol.decl);
>>> -
>>> -  dispatcher_node = cgraph_get_create_node (dispatch_decl);
>>> -  gcc_assert (dispatcher_node != NULL);
>>> -  dispatcher_node->dispatcher_function = 1;
>>> -  dispatcher_version_info
>>> -= insert_new_cgraph_node_version (dispatcher_node);
>>> -  dispatcher_version_info->next = default_version_info;
>>> -  dispatcher_node->local.finalized = 1;
>>> -
>>> -  /* Set the dispatcher for all the versions.  */
>>> -  it_v = default_version_info;
>>> -  while (it_v->next != NULL)
>>> +#if defined (ASM_OUTPUT_TYPE_DIRECTIVE)
>>> +  if (TARGET_HAS_IFUNC)
>>> +{
>>> +  /* Right now, the dispatching is done via ifunc.  */
>>> +  dispatch_decl = make_dispatcher_decl (default_node->symbol.decl);
>>> +
>>> +  dispatcher_node = cgraph_get_create_node (dispatch_decl);
>>> +  gcc_assert (dispatcher_node != NULL);
>>> +  dispatcher_node->dispatcher_function = 1;
>>> +  dispatcher_version_info
>>> + = insert_new_cgraph_node_version (dispatcher_node);
>>> +  dispatcher_version_info->next = default_version_info;
>>> +  dispatcher_node->local.finalized = 1;
>>> +
>>> +  /* Set the dispatcher for all the versions.  */
>>> +  it_v = default_version_info;
>>> +  while (it_v->next != NULL)
>>> + {
>>> +   it_v->dispatcher_resolver = dispatch_decl;
>>> +   it_v = it_v->next;
>>> + }
>>> +}
>>> +  else
>>> {
>>> -  it_v->dispatcher_resolver = dispatch_decl;
>>> -  it_v = it_v->next;
>>> +  error_at (DECL_SOURCE_LOCATION (default_node->symbol.decl),
>>> + "multiversioning needs ifunc which is not supported "
>>> + "on this target");
>>> }
>> 
>> This looks wrong.  Before the patch this code would be ignored if 
>> !HAVE_GNU_INDIRECT_FUNCTION and after the patch it will produce an error.  
>> Removing the else-clause should fix this.
> 
> Mmm, I believe that we want this code not to be ignored, because we
> want it to produces an error
> if the target does not support ifuncs and we are compiling something
> that uses ifuncs.. May be I
> missed something..

You are right, I read the patch wrong.

> index db56819..e535218 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -637,6 +637,11 @@ case ${target} in
>native_system_header_dir=/include
>;;
>esac
> +  case $target in
> +*linux*)
> +  tm_p_file="${tm_p_file} linux-protos.h"
> +  ;;
> +  esac
># glibc / uclibc / bionic switch.
># uclibc and bionic aren't usable for GNU/Hurd and neither for GNU/k*BSD.
>case $target in

Should not be necessary.  Put t

Re: [PATCH][Cilkplus] Check invalid gotos, increments and report errors

[Richard Henderson]

On 12/12/2012 07:39 PM, Iyer, Balaji V wrote:
> +   error_at (EXPR_LOCATION (orig_incr),
> + "Invalid loop increment operation.");

Error messages should not be Capitalized, nor contain trailing punctuation.


r~

Re: [PATCH] Add --param max-vartrack-reverse-op-size=N (PR debug/54402)

[Richard Henderson]

On 12/13/2012 01:39 AM, Jakub Jelinek wrote:
>   PR debug/54402
>   * params.def (PARAM_MAX_VARTRACK_REVERSE_OP_SIZE): New param.
>   * var-tracking.c (reverse_op): Don't add reverse ops to
>   VALUEs that have already
>   PARAM_VALUE (PARAM_MAX_VARTRACK_REVERSE_OP_SIZE) or longer
>   locs list.

Ok.


r~

[google 4_7] fix unsat for target w/o atomic builtins (issue7031051)

[Rong Xu]

Hi,

This patch fixes an issue in r194725. The call to atmoic builtin
is emmitted regardless of -fprofile-gen-atomic -- which results
in link unsat for targets without sync builtin support.

Tested with regression test in x86 (with builtin support.) 
and powerpc32 (without builtin support).

Thanks,

-Rong

2013-01-02  Rong Xu  

* gcc/gcov-io.h: Make __atomic_fetch_add weak for these
target without sync builtin support.

Index: gcc/gcov-io.h
===
--- gcc/gcov-io.h   (revision 194739)
+++ gcc/gcov-io.h   (working copy)
@@ -308,6 +308,10 @@ typedef unsigned gcov_type_unsigned __attribute__
 #define GCOV_TYPE_ATOMIC_FETCH_ADD_FN __atomic_fetch_add_4
 #define GCOV_TYPE_ATOMIC_FETCH_ADD BUILT_IN_ATOMIC_FETCH_ADD_4
 #endif
+/* Make the atomic builtin weak. Otherwise we get link unsat 
+   if the builtin is not available.  */
+extern gcov_type GCOV_TYPE_ATOMIC_FETCH_ADD_FN
+  (gcov_type*, gcov_type, int) __attribute__ ((weak));
 
 #undef EXTRACT_MODULE_ID_FROM_GLOBAL_ID
 #undef EXTRACT_FUNC_ID_FROM_GLOBAL_ID

--
This patch is available for review at http://codereview.appspot.com/7031051

Re: [PATCH] Function Multiversioning Bug, checking for function versions

[Sriraman Tallam]

On Wed, Jan 2, 2013 at 1:01 PM, Jakub Jelinek  wrote:
> On Wed, Jan 02, 2013 at 12:23:45PM -0800, Sriraman Tallam wrote:
>> --- config/i386/i386.c  (revision 194817)
>> +++ config/i386/i386.c  (working copy)
>> @@ -29290,7 +29290,7 @@ ix86_get_function_versions_dispatcher (void *decl)
>>
>>/* Set the dispatcher for all the versions.  */
>>it_v = default_version_info;
>> -  while (it_v->next != NULL)
>> +  while (it_v != NULL)
>>  {
>>it_v->dispatcher_resolver = dispatch_decl;
>>it_v = it_v->next;
>> @@ -29626,8 +29626,8 @@ fold_builtin_cpu (tree fndecl, tree *args)
>>{"avx2",   F_AVX2}
>>  };
>>
>> -  static tree __processor_model_type = NULL_TREE;
>> -  static tree __cpu_model_var = NULL_TREE;
>> +  tree __processor_model_type = NULL_TREE;
>> +  tree __cpu_model_var = NULL_TREE;
>>
>>if (__processor_model_type == NULL_TREE)
>>  __processor_model_type = build_processor_model_struct ();
>
> If __processor_model_type is always NULL_TREE above, then you should write
>   tree __processor_model_type = build_processor_model_struct ();
> rather than the extra if with an always true condition.

Submitted this patch to fix this.

* config/i386/i386.c (fold_builtin_cpu): Remove unnecessary checks for
NULL.

--- config/i386/i386.c (revision 194827)
+++ config/i386/i386.c (working copy)
@@ -29626,16 +29626,10 @@ fold_builtin_cpu (tree fndecl, tree *args)
   {"avx2",   F_AVX2}
 };

-  tree __processor_model_type = NULL_TREE;
-  tree __cpu_model_var = NULL_TREE;
+  tree __processor_model_type = build_processor_model_struct ();
+  tree __cpu_model_var = make_var_decl (__processor_model_type,
+  "__cpu_model");

-  if (__processor_model_type == NULL_TREE)
-__processor_model_type = build_processor_model_struct ();
-
-  if (__cpu_model_var == NULL_TREE)
-__cpu_model_var = make_var_decl (__processor_model_type,
- "__cpu_model");
-
   gcc_assert ((args != NULL) && (*args != NULL));

   param_string_cst = *args;

Thanks,
-Sri.


>
> Jakub

Re: [google 4_7] fix unsat for target w/o atomic builtins (issue7031051)

[Xinliang David Li]

Ok for google branch, but it might be better to warn this at compile
time (more discussion needed for the trunk version).

David

On Wed, Jan 2, 2013 at 4:58 PM, Rong Xu  wrote:
> Hi,
>
> This patch fixes an issue in r194725. The call to atmoic builtin
> is emmitted regardless of -fprofile-gen-atomic -- which results
> in link unsat for targets without sync builtin support.
>
> Tested with regression test in x86 (with builtin support.)
> and powerpc32 (without builtin support).
>
> Thanks,
>
> -Rong
>
> 2013-01-02  Rong Xu  
>
> * gcc/gcov-io.h: Make __atomic_fetch_add weak for these
> target without sync builtin support.
>
> Index: gcc/gcov-io.h
> ===
> --- gcc/gcov-io.h   (revision 194739)
> +++ gcc/gcov-io.h   (working copy)
> @@ -308,6 +308,10 @@ typedef unsigned gcov_type_unsigned __attribute__
>  #define GCOV_TYPE_ATOMIC_FETCH_ADD_FN __atomic_fetch_add_4
>  #define GCOV_TYPE_ATOMIC_FETCH_ADD BUILT_IN_ATOMIC_FETCH_ADD_4
>  #endif
> +/* Make the atomic builtin weak. Otherwise we get link unsat
> +   if the builtin is not available.  */
> +extern gcov_type GCOV_TYPE_ATOMIC_FETCH_ADD_FN
> +  (gcov_type*, gcov_type, int) __attribute__ ((weak));
>
>  #undef EXTRACT_MODULE_ID_FROM_GLOBAL_ID
>  #undef EXTRACT_FUNC_ID_FROM_GLOBAL_ID
>
> --
> This patch is available for review at http://codereview.appspot.com/7031051

Re: atomic update of profile counters (issue7000044)

[Rong Xu]

Hi,

Here is a new patch. The only difference is to declare
__atomic_fetch_add as weak. This is
needed for targets without sync/atomic builtin support. The patch
contains a call to the builtin regardless of the new options
-fprofile-gen-atomic. This results in a unsat in these targets even
for regular profile-gen built.

With this new patch, if the user uses -fprofile-gen-atomic in these
target, the generated code will seg fault.

We think a better solution is to emit the builtin call only in these
targets with the support, and give warning for non-supported target.
But I did not find any target hook for this. Does anyone know how to
do this?

Thanks,

-Rong


On Fri, Dec 28, 2012 at 11:35 AM, Xinliang David Li  wrote:
> It would be great if this can make into gcc4.8. The patch has close to
> 0 impact on code stability.
>
> David
>
> On Fri, Dec 28, 2012 at 11:32 AM, Rong Xu  wrote:
>> Hi Honza,
>>
>> In the other thread of discussion (similar patch in google-4_7
>> branch), you said you were thinking if to let this patch into trunk in
>> stage 3. Can you give some update?
>>
>> Thanks,
>>
>> -Rong
>>
>> On Fri, Dec 21, 2012 at 10:37 AM, Rong Xu  wrote:
>>> On Fri, Dec 21, 2012 at 1:25 AM, Jan Hubicka  wrote:
> Hi,
>
> This patch adds support of atomic update of profiles counters. The goal 
> is to improve
> the poor counter values for highly thread programs.
>
> The atomic update is under a new option -fprofile-gen-atomic=
> N=0: default, no atomic update
> N=1: atomic update edge counters.
> N=2: atomic update some of value profile counters (currently 
> indirect-call and one value profile).
> N=3: both edge counter and the above value profile counters.
> Other value: fall back to the default.
>
> This patch is a simple porting of the version in google-4_7 branch. It 
> uses __atomic_fetch_add
> based on Andrew Pinski's suggestion. Note I did not apply to all the 
> value profiles as
> the indirect-call profile is the most relevant one here.
>
> Test with bootstrap.
>
> Comments and suggestions are welcomed.
>
> Thanks,
>
> -Rong
>
>
> 2012-12-20  Rong Xu  
>
>   * libgcc/libgcov.c (__gcov_one_value_profiler_body_atomic): New
> function. Atomic update profile counters.
>   (__gcov_one_value_profiler_atomic): Ditto.
>   (__gcov_indirect_call_profiler_atomic): Ditto.
>   * gcc/gcov-io.h: Macros for atomic update.
>   * gcc/common.opt: New option.
>   * gcc/tree-profile.c (gimple_init_edge_profiler): Atomic
> update profile counters.
>   (gimple_gen_edge_profiler): Ditto.

 The patch looks resonable.  Eventually we probably should provide rest of 
 the value counters
 in thread safe manner.  What happens on targets not having atomic 
 operations?
>>>
>>> From 
>>> http://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-Builtins.html#_005f_005fsync-Builtins,
>>> it says:
>>>   "If a particular operation cannot be implemented on the target
>>> processor, a warning is generated and a call an external function is
>>> generated. "
>>>
>>> So I think there will be a warning and eventually a link error of unsat.
>>>
>>> Thanks,
>>>
>>> -Rong
>>>
>>>

 Honza


patch2.diff
Description: Binary data

Re: atomic update of profile counters (issue7000044)

[Andrew Pinski]

On Wed, Jan 2, 2013 at 5:15 PM, Rong Xu  wrote:
> Hi,
>
> Here is a new patch. The only difference is to declare
> __atomic_fetch_add as weak. This is
> needed for targets without sync/atomic builtin support. The patch
> contains a call to the builtin regardless of the new options
> -fprofile-gen-atomic. This results in a unsat in these targets even
> for regular profile-gen built.
>
> With this new patch, if the user uses -fprofile-gen-atomic in these
> target, the generated code will seg fault.
>
> We think a better solution is to emit the builtin call only in these
> targets with the support, and give warning for non-supported target.
> But I did not find any target hook for this. Does anyone know how to
> do this?

Why not use libatomic for those targets?

Thanks,
Andrew Pinski



>
> Thanks,
>
> -Rong
>
>
> On Fri, Dec 28, 2012 at 11:35 AM, Xinliang David Li  
> wrote:
>> It would be great if this can make into gcc4.8. The patch has close to
>> 0 impact on code stability.
>>
>> David
>>
>> On Fri, Dec 28, 2012 at 11:32 AM, Rong Xu  wrote:
>>> Hi Honza,
>>>
>>> In the other thread of discussion (similar patch in google-4_7
>>> branch), you said you were thinking if to let this patch into trunk in
>>> stage 3. Can you give some update?
>>>
>>> Thanks,
>>>
>>> -Rong
>>>
>>> On Fri, Dec 21, 2012 at 10:37 AM, Rong Xu  wrote:
 On Fri, Dec 21, 2012 at 1:25 AM, Jan Hubicka  wrote:
>> Hi,
>>
>> This patch adds support of atomic update of profiles counters. The goal 
>> is to improve
>> the poor counter values for highly thread programs.
>>
>> The atomic update is under a new option -fprofile-gen-atomic=
>> N=0: default, no atomic update
>> N=1: atomic update edge counters.
>> N=2: atomic update some of value profile counters (currently 
>> indirect-call and one value profile).
>> N=3: both edge counter and the above value profile counters.
>> Other value: fall back to the default.
>>
>> This patch is a simple porting of the version in google-4_7 branch. It 
>> uses __atomic_fetch_add
>> based on Andrew Pinski's suggestion. Note I did not apply to all the 
>> value profiles as
>> the indirect-call profile is the most relevant one here.
>>
>> Test with bootstrap.
>>
>> Comments and suggestions are welcomed.
>>
>> Thanks,
>>
>> -Rong
>>
>>
>> 2012-12-20  Rong Xu  
>>
>>   * libgcc/libgcov.c (__gcov_one_value_profiler_body_atomic): New
>> function. Atomic update profile counters.
>>   (__gcov_one_value_profiler_atomic): Ditto.
>>   (__gcov_indirect_call_profiler_atomic): Ditto.
>>   * gcc/gcov-io.h: Macros for atomic update.
>>   * gcc/common.opt: New option.
>>   * gcc/tree-profile.c (gimple_init_edge_profiler): Atomic
>> update profile counters.
>>   (gimple_gen_edge_profiler): Ditto.
>
> The patch looks resonable.  Eventually we probably should provide rest of 
> the value counters
> in thread safe manner.  What happens on targets not having atomic 
> operations?

 From 
 http://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-Builtins.html#_005f_005fsync-Builtins,
 it says:
   "If a particular operation cannot be implemented on the target
 processor, a warning is generated and a call an external function is
 generated. "

 So I think there will be a warning and eventually a link error of unsat.

 Thanks,

 -Rong


>
> Honza

Re: atomic update of profile counters (issue7000044)

[Rong Xu]

Does libatomic support all targets?
I think it's a good idea to change the driver to link in this library
if the option is specified.
But still, we need to make the builtin weak.

Thanks,

-Rong

On Wed, Jan 2, 2013 at 5:25 PM, Andrew Pinski  wrote:
> On Wed, Jan 2, 2013 at 5:15 PM, Rong Xu  wrote:
>> Hi,
>>
>> Here is a new patch. The only difference is to declare
>> __atomic_fetch_add as weak. This is
>> needed for targets without sync/atomic builtin support. The patch
>> contains a call to the builtin regardless of the new options
>> -fprofile-gen-atomic. This results in a unsat in these targets even
>> for regular profile-gen built.
>>
>> With this new patch, if the user uses -fprofile-gen-atomic in these
>> target, the generated code will seg fault.
>>
>> We think a better solution is to emit the builtin call only in these
>> targets with the support, and give warning for non-supported target.
>> But I did not find any target hook for this. Does anyone know how to
>> do this?
>
> Why not use libatomic for those targets?
>
> Thanks,
> Andrew Pinski
>
>
>
>>
>> Thanks,
>>
>> -Rong
>>
>>
>> On Fri, Dec 28, 2012 at 11:35 AM, Xinliang David Li  
>> wrote:
>>> It would be great if this can make into gcc4.8. The patch has close to
>>> 0 impact on code stability.
>>>
>>> David
>>>
>>> On Fri, Dec 28, 2012 at 11:32 AM, Rong Xu  wrote:
 Hi Honza,

 In the other thread of discussion (similar patch in google-4_7
 branch), you said you were thinking if to let this patch into trunk in
 stage 3. Can you give some update?

 Thanks,

 -Rong

 On Fri, Dec 21, 2012 at 10:37 AM, Rong Xu  wrote:
> On Fri, Dec 21, 2012 at 1:25 AM, Jan Hubicka  wrote:
>>> Hi,
>>>
>>> This patch adds support of atomic update of profiles counters. The goal 
>>> is to improve
>>> the poor counter values for highly thread programs.
>>>
>>> The atomic update is under a new option -fprofile-gen-atomic=
>>> N=0: default, no atomic update
>>> N=1: atomic update edge counters.
>>> N=2: atomic update some of value profile counters (currently 
>>> indirect-call and one value profile).
>>> N=3: both edge counter and the above value profile counters.
>>> Other value: fall back to the default.
>>>
>>> This patch is a simple porting of the version in google-4_7 branch. It 
>>> uses __atomic_fetch_add
>>> based on Andrew Pinski's suggestion. Note I did not apply to all the 
>>> value profiles as
>>> the indirect-call profile is the most relevant one here.
>>>
>>> Test with bootstrap.
>>>
>>> Comments and suggestions are welcomed.
>>>
>>> Thanks,
>>>
>>> -Rong
>>>
>>>
>>> 2012-12-20  Rong Xu  
>>>
>>>   * libgcc/libgcov.c (__gcov_one_value_profiler_body_atomic): New
>>> function. Atomic update profile counters.
>>>   (__gcov_one_value_profiler_atomic): Ditto.
>>>   (__gcov_indirect_call_profiler_atomic): Ditto.
>>>   * gcc/gcov-io.h: Macros for atomic update.
>>>   * gcc/common.opt: New option.
>>>   * gcc/tree-profile.c (gimple_init_edge_profiler): Atomic
>>> update profile counters.
>>>   (gimple_gen_edge_profiler): Ditto.
>>
>> The patch looks resonable.  Eventually we probably should provide rest 
>> of the value counters
>> in thread safe manner.  What happens on targets not having atomic 
>> operations?
>
> From 
> http://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-Builtins.html#_005f_005fsync-Builtins,
> it says:
>   "If a particular operation cannot be implemented on the target
> processor, a warning is generated and a call an external function is
> generated. "
>
> So I think there will be a warning and eventually a link error of unsat.
>
> Thanks,
>
> -Rong
>
>
>>
>> Honza

Re: atomic update of profile counters (issue7000044)

[Andrew Pinski]

On Wed, Jan 2, 2013 at 5:29 PM, Rong Xu  wrote:
> Does libatomic support all targets?

It supports all targets that support pthreads.

Thanks,
Andrew


> I think it's a good idea to change the driver to link in this library
> if the option is specified.
> But still, we need to make the builtin weak.
>
> Thanks,
>
> -Rong
>
> On Wed, Jan 2, 2013 at 5:25 PM, Andrew Pinski  wrote:
>> On Wed, Jan 2, 2013 at 5:15 PM, Rong Xu  wrote:
>>> Hi,
>>>
>>> Here is a new patch. The only difference is to declare
>>> __atomic_fetch_add as weak. This is
>>> needed for targets without sync/atomic builtin support. The patch
>>> contains a call to the builtin regardless of the new options
>>> -fprofile-gen-atomic. This results in a unsat in these targets even
>>> for regular profile-gen built.
>>>
>>> With this new patch, if the user uses -fprofile-gen-atomic in these
>>> target, the generated code will seg fault.
>>>
>>> We think a better solution is to emit the builtin call only in these
>>> targets with the support, and give warning for non-supported target.
>>> But I did not find any target hook for this. Does anyone know how to
>>> do this?
>>
>> Why not use libatomic for those targets?
>>
>> Thanks,
>> Andrew Pinski
>>
>>
>>
>>>
>>> Thanks,
>>>
>>> -Rong
>>>
>>>
>>> On Fri, Dec 28, 2012 at 11:35 AM, Xinliang David Li  
>>> wrote:
 It would be great if this can make into gcc4.8. The patch has close to
 0 impact on code stability.

 David

 On Fri, Dec 28, 2012 at 11:32 AM, Rong Xu  wrote:
> Hi Honza,
>
> In the other thread of discussion (similar patch in google-4_7
> branch), you said you were thinking if to let this patch into trunk in
> stage 3. Can you give some update?
>
> Thanks,
>
> -Rong
>
> On Fri, Dec 21, 2012 at 10:37 AM, Rong Xu  wrote:
>> On Fri, Dec 21, 2012 at 1:25 AM, Jan Hubicka  wrote:
 Hi,

 This patch adds support of atomic update of profiles counters. The 
 goal is to improve
 the poor counter values for highly thread programs.

 The atomic update is under a new option -fprofile-gen-atomic=
 N=0: default, no atomic update
 N=1: atomic update edge counters.
 N=2: atomic update some of value profile counters (currently 
 indirect-call and one value profile).
 N=3: both edge counter and the above value profile counters.
 Other value: fall back to the default.

 This patch is a simple porting of the version in google-4_7 branch. It 
 uses __atomic_fetch_add
 based on Andrew Pinski's suggestion. Note I did not apply to all the 
 value profiles as
 the indirect-call profile is the most relevant one here.

 Test with bootstrap.

 Comments and suggestions are welcomed.

 Thanks,

 -Rong


 2012-12-20  Rong Xu  

   * libgcc/libgcov.c (__gcov_one_value_profiler_body_atomic): New
 function. Atomic update profile counters.
   (__gcov_one_value_profiler_atomic): Ditto.
   (__gcov_indirect_call_profiler_atomic): Ditto.
   * gcc/gcov-io.h: Macros for atomic update.
   * gcc/common.opt: New option.
   * gcc/tree-profile.c (gimple_init_edge_profiler): Atomic
 update profile counters.
   (gimple_gen_edge_profiler): Ditto.
>>>
>>> The patch looks resonable.  Eventually we probably should provide rest 
>>> of the value counters
>>> in thread safe manner.  What happens on targets not having atomic 
>>> operations?
>>
>> From 
>> http://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-Builtins.html#_005f_005fsync-Builtins,
>> it says:
>>   "If a particular operation cannot be implemented on the target
>> processor, a warning is generated and a call an external function is
>> generated. "
>>
>> So I think there will be a warning and eventually a link error of unsat.
>>
>> Thanks,
>>
>> -Rong
>>
>>
>>>
>>> Honza

[committed] gcc.dg/pr55430.c: Define MAP_FAILED if not defined

[John David Anglin]

Tested on hppa1.1-hp-hpux10.20.

Dave
-- 
J. David Anglin  dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)

2013-01-02  John David Anglin  

* gcc.dg/pr55430.c: Define MAP_FAILED if not defined.

Index: gcc.dg/pr55430.c
===
--- gcc.dg/pr55430.c(revision 194729)
+++ gcc.dg/pr55430.c(working copy)
@@ -11,6 +11,9 @@
 #ifndef MAP_ANON
 #define MAP_ANON 0
 #endif
+#ifndef MAP_FAILED
+#define MAP_FAILED ((void *)-1)
+#endif
 #include 
 
 struct S

Re: [wwwdocs] bugs/management.html

[Gerald Pfeifer]

On Sun, 2 Jan 2011, Richard Guenther wrote:
>> Richi, looking at that page and your changes earlier this year, what
>> did you mean by
>>
>>  "This includes bugs that have been released with."
>>
>> ?  Is something missing here?  Perhaps "...have been in earlier
>> releases" or something like that?
> Yes, bugs that have been shipped in earlier releases.  "Regressions
> mit denen released worden ist." - german habit of using passive form ...

Yes, I know what you are talking about. ;-)

The change below still uses passive form, but I hope it avoids
ambiguity and went ahead and applied it.  If anyone wants to
offer better wording, happy to change.

Gerald


Clarify wording in the description of P2.

--- management.orig 2012-08-26 00:34:44.468942157 -1000
+++ management.html 2012-12-30 17:20:13.107445607 -1000
@@ -116,7 +116,7 @@
   P2
   This generally indicates a regression users will notice on a
 major platform, which is not severe enough to block a release though.
-This includes bugs that have been released with.
+This includes bugs that were already present in a previous release.
   
 
   P3

Re: [patch][wwwdocs] gcc 4.8 changes - mention scalability improvements

[Gerald Pfeifer]

On Sun, 14 Oct 2012, Steven Bosscher wrote:
> This patch adds a short notice about some speed-ups in GCC 4.8 for 
> extremely large functions (coming from the work done on PR54146 by 
> several people). OK for the wwwdocs?

Thanks.  Somehow I kept stumbling over the second sentence, so
finally I went ahead a adjusted it a bit.   (This also describes
previous situation not _as_ negatively.)

Gerald

Tweak rationale of removing -fipa-struct-reorg and -fipa-matrix-reorg.

--- changes.orig2012-12-21 16:15:03.628627198 -1000
+++ changes.html2013-01-02 17:56:51.343937379 -1000
@@ -82,8 +82,9 @@
 The struct reorg and matrix reorg optimizations (command-line
  options -fipa-struct-reorg and 
  -fipa-matrix-reorg) have been removed.  They did not
- work correctly nor with link-time optimization (LTO), hence were only
- applicable to programs consisting of a single translation unit.
+ always work correctly, nor did they work with link-time optimization
+ (LTO), hence were only applicable to programs consisting of a single
+ translation unit.
 
 Several scalability bottle-necks have been removed from GCC's
  optimization passes.  Compilation of extremely large functions,

Re: [wwwdocs] SH 4.8 changes - document thread pointer built-ins

[Gerald Pfeifer]

Hi Oleg,

On Wed, 17 Oct 2012, Oleg Endo wrote:
>> +Added support for the built-in functions
>> +__builtin_thread_pointer and
>> +__builtin_set_thread_pointer.  This assumes that
>> +GBR is used to hold the thread pointer of the current 
>> thread,
>> +which has been the case since a while already. 
>> 
>> "since a while" -> "for a while", and I made that change.
>> That said, why is this important, and is there a fixed date or version?
> It might be important for some embedded systems software that does not
> use the GBR for storing the thread pointer, but for something else (like
> a pointer to some global table of frequently used stuff or something
> like that).  I just thought it might be better to mention this.  But
> you're right, the last "for a while" part sounds strange, and should
> probably just be removed, reducing it to "This assumes that
> GBR is used to hold the thread pointer of the current
> thread."

That sounds good.  I noticed this has not been changed yet, so I
assume you were probably waiting for my response?  Will you be
making this change?

>> +Memory loads and stores
>> +relative to the address returned by 
>> __builtin_thread_pointer
>> +will now also utilize GBR based displacement address modes.
>> 
>> Why do these _now_ utilize these address modes, when per the above
>> __builtin_thread_pointer was just added?  This last sentence implies
>> a change when there does not seem to be one?
> Because before GCC did not utilize GBR addressing modes on SH at all.
> Now it can do that, if the base address is obtained via
> __builtin_thread_pointer.  Does that make sense? :)

Yep, it does. :-)  Thanks for the explanation.

Gerald

Re: [wwwdocs] Document libstdc++ changes and minimum MinGW-w64 version requirement.

[Gerald Pfeifer]

On Sat, 15 Dec 2012, Jonathan Wakely wrote:
> Committed to wwwdocs.

Thanks, Jonathan.

Where it says, "Added --disable-libstdcxx-verbose configure 
option", would it make sense to add a half-sentence that describes the
purpose of this option?

Gerald

[DOC] Update doc/contrib.texi

[Gerald Pfeifer]

This is something I had discussed with Mark about a year ago after
he stepped down as release manager, and just failed to commit until
now.

Gerald


2013-01-01  Gerald Pfeifer  

* doc/contrib.texi: Note years as release manager for Mark Mitchell.

Index: doc/contrib.texi
===
--- doc/contrib.texi(revision 194572)
+++ doc/contrib.texi(working copy)
@@ -623,7 +623,8 @@
 @item
 Mark Mitchell for his direction via the steering committee, mountains of
 C++ work, load/store hoisting out of loops, alias analysis improvements,
-ISO C @code{restrict} support, and serving as release manager for GCC 3.x.
+ISO C @code{restrict} support, and serving as release manager from 2000
+to 2011.
 
 @item
 Alan Modra for various GNU/Linux bits and testing.