Re: [PATCH] Fix PR 51505
On 30.01.2012 11:38, Paolo Bonzini wrote:
On 01/29/2012 04:09 PM, Eric Botcazou wrote:
As discussed in Bugzilla, this is the patch implementing Paolo's
suggestion of killing REG_EQUAL/REG_EQUIV notes from df_kill_notes. The
code assumes there is at most one such note per insn.
That's wrong though and wreaks havoc during reload, e.g.:
(insn 169 60 62 4 (set (reg:TF 158)
(mem/c:TF (plus:SI (reg/f:SI 101 %sfp)
(const_int -16 [0xfff0])) [3 S16 A64]))
960513-1.c:13 97 {*movtf_insn_sp32}
(expr_list:REG_EQUIV (mem/c:TF (plus:SI (reg/f:SI 101 %sfp)
(const_int -16 [0xfff0])) [3 S16 A64])
(expr_list:REG_EQUAL (mult:TF (reg/v:TF 110 [ d ])
(reg:TF 154))
(nil
because the REG_EQUIV note disappears behind reload's back and it isn't
prepared for that. This is the cause of the following regression on SPARC:
FAIL: gcc.c-torture/execute/960513-1.c execution, -Os
As well as:
FAIL: gcc.c-torture/execute/stdarg-2.c execution, -O2
FAIL: gcc.c-torture/execute/stdarg-2.c execution, -O3 -fomit-frame-pointer
FAIL: gcc.c-torture/execute/stdarg-2.c execution, -O3 -g
FAIL: gcc.c-torture/execute/stdarg-2.c execution, -Os
FAIL: gcc.c-torture/execute/stdarg-2.c
execution, -O2 -flto -flto-partition=none
FAIL: gcc.c-torture/execute/stdarg-2.c execution, -O2 -flto
for the exact same reason.
Does this help?
That would fix the problem of multiple notes per insn (as we wanted to do
initially), but I didn't understand whether this is the real problem or the
problem is the reload not happy with disappearing notes. Also I can't
reproduce it with a cross to sparc64-linux -- when I put a breakpoint on
the code removing the notes, I find only similarly looking insn 148 which
gets removed from the df_analyze call at the start of IRA. Though I see
the fail from SPARC test results on the ML, so I guess I'm missing something...
Andrey
Paolo
Re: [patch, fortran] Fix PR 51858, wrong-code regression with function elimination
Hello Thomas, I didn't know that you are now also fixing libmudflap problems and that you work on Some malloc'd inside libc is not being tracked. Or did you intent to write PR fortran/51958 rather than PR libmudflap/51858? Changing else if into else; if ... endif; endif matches what we already do for the middle end and should thus be fine. While I haven't tried the patch, it looks okay. Could you also add a test case for: if () else if () else if () else end if (can be in the same file, but should be additional) just to make sure that multiple else if also work? Tobias
Re: [committed] Add -fno-common option on hppa-*-hpux* in gcc.dg/tm/pr51472.c
John David Anglin d...@hiauly1.hia.nrc.ca writes:
Index: gcc.dg/tm/pr51472.c
===
--- gcc.dg/tm/pr51472.c (revision 183677)
+++ gcc.dg/tm/pr51472.c (working copy)
@@ -1,5 +1,6 @@
/* { dg-do compile } */
/* { dg-options -fgnu-tm -O --param tm-max-aggregate-size=32 } */
+/* { dg-options -fgnu-tm -fno-common -O --param tm-max-aggregate-size=32
{ target hppa*-*-hpux* } } */
Please use dg-additional-options.
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.
Re: [committed] PR 51931: force non-MIPS16ness for long-branch tests
On 2012/1/22 06:33 PM, Richard Sandiford wrote: The MIPS16 port has never handled long branches properly; see PR 51931 for the details. It isn't easy to xfail MIPS16-specific problems at the dejagnu level because of -mflip-mips16, so the patch below forces a nomips16 attribute instead. Tested on mips64-linux-gnu and applied. Richard CCing Catherine, I think we have a fix for this? Thanks, Chung-Lin
Re: [committed] Skip gfortran.dg/guality/pr41558.f90 on 32-bit hppa*-*-hpux*
John David Anglin d...@hiauly1.hia.nrc.ca writes:
Index: gfortran.dg/guality/pr41558.f90
===
--- gfortran.dg/guality/pr41558.f90 (revision 183677)
+++ gfortran.dg/guality/pr41558.f90 (working copy)
@@ -1,5 +1,6 @@
! PR debug/41558
! { dg-do run }
+! { dg-skip-if PR testsuite/51875 { { hppa*-*-hpux* } { ! hppa*64*-*-*
} } { * } { } }
Although there is no support for biarch it is probably better to check
for !lp64 here.
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.
Re: [PATCH, rs6000] Fix PR16458, eliminate redudant compares
On Fri, Jan 27, 2012 at 5:56 PM, Peter Bergner berg...@vnet.ibm.com wrote:
This patch fixes PR16458 by using the type expression attached to a reg
rtx to detect its signedness and generating unsigned compares when
appropriate. However, we continue to use signed compares for the
special case of when we compare an unsigned reg against the constant 0.
This is because signed and unsigned compares give the same results
for equality and (unsigned)x 0) is equivalent to x != 0.
Using a signed compare in this special case allows us to continue to
generate record form instructions (ie, instructions that implicitly
set cr0).
I'll note that for the moment, I have XFAILed pr16458-4.c, since this
test case isn't working yet, but it is due to a problem in expand not
attaching any type expression information on *index's reg rtx like it
does for *a and *b in pr16458-2.c. We're tracking that down for 4.8.
This has passed bootstrap and regtesting with no regressions.
Ok for mainline?
This does not sound suitable for stage4. rs6000_unsigned_reg_p
looks suspiciously non-rs6000 specific, and if we really can rely
on the way it is implemented should find its way to general RTL
helper routines. The question is - do we ever coalesce signed
and unsigned variables to the same pseudo?
IIRC avr people recently have come across the same idea.
Richard.
Peter
gcc/
PR target/16458
* config/rs6000/rs6000.c (rs6000_unsigned_reg_p): New function.
(rs6000_generate_compare): Use it.
gcc/testsuite/
PR target/16458
* gcc.target/powerpc/pr16458-1.c: New test.
* gcc.target/powerpc/pr16458-2.c: Likewise.
* gcc.target/powerpc/pr16458-3.c: Likewise.
* gcc.target/powerpc/pr16458-4.c: Likewise.
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c (revision 183628)
+++ gcc/config/rs6000/rs6000.c (working copy)
@@ -15588,6 +15588,22 @@ rs6000_reverse_condition (enum machine_m
return reverse_condition (code);
}
+static bool
+rs6000_unsigned_reg_p (rtx op)
+{
+ enum rtx_code code = GET_CODE (op);
+
+ if (code == REG
+ REG_EXPR (op)
+ TYPE_UNSIGNED (TREE_TYPE (REG_EXPR (op
+ return true;
+
+ if (code == SUBREG SUBREG_PROMOTED_UNSIGNED_P (op))
+ return true;
+
+ return false;
+}
+
/* Generate a compare for CODE. Return a brand-new rtx that
represents the result of the compare. */
@@ -15606,14 +15622,11 @@ rs6000_generate_compare (rtx cmp, enum m
|| code == GEU || code == LEU)
comp_mode = CCUNSmode;
else if ((code == EQ || code == NE)
- GET_CODE (op0) == SUBREG
- GET_CODE (op1) == SUBREG
- SUBREG_PROMOTED_UNSIGNED_P (op0)
- SUBREG_PROMOTED_UNSIGNED_P (op1))
+ rs6000_unsigned_reg_p (op0)
+ (rs6000_unsigned_reg_p (op1)
+ || (CONST_INT_P (op1) INTVAL (op1) != 0)))
/* These are unsigned values, perhaps there will be a later
- ordering compare that can be shared with this one.
- Unfortunately we cannot detect the signedness of the operands
- for non-subregs. */
+ ordering compare that can be shared with this one. */
comp_mode = CCUNSmode;
else
comp_mode = CCmode;
Index: gcc/testsuite/gcc.target/powerpc/pr16458-1.c
===
--- gcc/testsuite/gcc.target/powerpc/pr16458-1.c (revision 0)
+++ gcc/testsuite/gcc.target/powerpc/pr16458-1.c (revision 0)
@@ -0,0 +1,18 @@
+/* Test cse'ing of unsigned compares. */
+/* { dg-do compile } */
+/* { dg-options -O2 } */
+
+/* { dg-final { scan-assembler-not cmpw } } */
+/* { dg-final { scan-assembler-times cmplw 1 } } */
+
+unsigned int a, b;
+
+int
+foo (void)
+{
+ if (a == b) return 1;
+ if (a b) return 2;
+ if (a b) return 3;
+ if (a != b) return 4;
+ return 0;
+}
Index: gcc/testsuite/gcc.target/powerpc/pr16458-2.c
===
--- gcc/testsuite/gcc.target/powerpc/pr16458-2.c (revision 0)
+++ gcc/testsuite/gcc.target/powerpc/pr16458-2.c (revision 0)
@@ -0,0 +1,18 @@
+/* Test cse'ing of unsigned compares. */
+/* { dg-do compile } */
+/* { dg-options -O2 } */
+
+/* { dg-final { scan-assembler-not cmpw } } */
+/* { dg-final { scan-assembler-times cmplw 1 } } */
+
+unsigned int *a, *b;
+
+int
+foo (void)
+{
+ if (*a == *b) return 1;
+ if (*a *b) return 2;
+ if (*a *b) return 3;
+ if (*a != *b) return 4;
+ return 0;
+}
Index: gcc/testsuite/gcc.target/powerpc/pr16458-3.c
===
--- gcc/testsuite/gcc.target/powerpc/pr16458-3.c (revision 0)
+++ gcc/testsuite/gcc.target/powerpc/pr16458-3.c (revision 0)
@@ -0,0 +1,41 @@
+/* Test cse'ing of unsigned compares. */
+/* {
Re: adjust installation docs to discourage installing GMP, MPFR and MPC separately
On Fri, Jan 27, 2012 at 9:51 PM, Quentin Neill quentin.neill@gmail.com wrote: On Fri, Jan 20, 2012 at 6:10 PM, Jonathan Wakely jwakely@gmail.com wrote: On 20 January 2012 23:08, Quentin Neill wrote: My 2c - I heartily recommend this patch. Thanks. I'm a bit surprised noone else has commented - I hoped this would be a no-brainer, or at least get some constructive feedback for further improvement. Another +1 for this patch. Who can approve? If we discourage from separately installing these libraries, who will do the required in-tree-bootstrap testing before a release on the Hosts we care for? Can we at least recommend using the OS vendors versions of the libraries in case they match our minimum (not recommended) version requirements? Is our in-tree build support robust enough against newer/older OS vendor installed copies? Richard. Seems like this would be okay for stage4 too. May I suggest updating /cvs/gcc/wwwdocs/htdocs/install/prerequisites.html That's exactly the page I'm trying to change, it's generated from the texi file my patch changes. Didn't know that, makes sense. And perhaps add a page to the twiki http://gcc.gnu.org/wiki/BuildingGCC to catch google searches for building gcc? I recently added http://gcc.gnu.org/wiki/InstallingGCC I chose installing not building because I believe that of the people who fail to build GCC and look for support, most of them probably should have installed a pre-built package supplied by their OS or another third-party packager. Maybe it could be changed to attract more search hits. Yes I saw your InstallingGCC and I like it. I was thinking a BuildingGCC would catch searches and could direct to InstallingGCC. Does MoinMoin have a way to attach keyword data to a page? Consider where InstallingGCC appears in these different results from google: ? https://www.google.com/search?q=installing+gcc -surprised me ? http://www.google.com/search?q=building+gcc ? http://www.google.com/search?q=building+gcc+wiki #2 http://www.google.com/search?q=installing+gcc+wiki #4 http://www.google.com/search?q=building+installing+gcc Another suggestion would be to link from one or both of these: http://gcc.gnu.org/install/index.html http://gcc.gnu.org/install/build.html -- Quentin
Re: [patch libjava]: Fix PR target/51500
On 01/29/2012 02:15 PM, Kai Tietz wrote: 2012-01-29 Kai Tietz kti...@redhat.com PR target/51500 * interpret.cc (_Jv_init_cif): Handle thiscall convention for 32-bit Windows. * java/lang/reflect/natMethod.cc (_Jv_CallAnyMethodA): Likewise. * java/lang/reflect/natVMProxy.cc (ncode): Force SYSV closure for 32-bit Windows. (invoke_t): Add thiscall-attribute for 32-bit Windows. Patch tested for i686-w64-mingw32, i686-pc-cygwin, and x86_64-unknown-linux-gnu. Ok for apply? Is it upstream? OK if so. Andrew.
[Ada] New pragma/aspect Remote_Access_Type
This change introduces a new implementation defined pragma, and an associated
implementation defined aspect: Remote_Access_Type. This pragma allows the
definition of generic units allowing RACWs as actuals for generic formal
access types.
Tested on x86_64-pc-linux-gnu, committed on trunk
2012-01-30 Thomas Quinot qui...@adacore.com
* gnat_rm.texi, sem_dist.adb, sem_dist.ads, einfo.ads, sem_prag.adb,
sem_ch12.adb, sem_attr.adb, aspects.adb, aspects.ads, par-prag.adb,
sem_cat.adb, snames.ads-tmpl (Sem_Dist.Is_Valid_Remote_Object_Type):
New subprogram (extracted from
Sem_Cat.Validate_Remote_Access_Object_Type_Declaration).
(Einfo.Is_Remote_Types): Now applies to generic types. Update
documentation accordingly.
(Sem_Ch12.Analyze_Associations): A RACW type is acceptable as
actual for a formal type to which a pragma Remote_Access_Type
applies.
(Aspects, Par.Prag, Sem_Prag): Support for new pramga/aspect
Remote_Access_Type.
(Sem_Attr.Analyze_Attribute, case Stub_Type): Attribute can
be applied to a generic type if pragma Remote_Access_Type
applies, in which case the type of the attribute is
System.Partition_Interface.RACW_Stub_Type.
Index: gnat_rm.texi
===
--- gnat_rm.texi(revision 183694)
+++ gnat_rm.texi(working copy)
@@ -186,6 +186,7 @@
* Pragma Profile (Restricted)::
* Pragma Psect_Object::
* Pragma Pure_Function::
+* Pragma Remote_Access_Type::
* Pragma Restriction_Warnings::
* Pragma Shared::
* Pragma Short_Circuit_And_Or::
@@ -824,6 +825,7 @@
* Pragma Profile (Restricted)::
* Pragma Psect_Object::
* Pragma Pure_Function::
+* Pragma Remote_Access_Type::
* Pragma Restriction_Warnings::
* Pragma Shared::
* Pragma Short_Circuit_And_Or::
@@ -4479,6 +4481,32 @@
unit is not a Pure unit in the categorization sense. So for example, a function
thus marked is free to @code{with} non-pure units.
+@node Pragma Remote_Access_Type
+@unnumberedsec Pragma Remote_Access_Type
+@findex Remote_Access_Type
+@noindent
+Syntax:
+
+@smallexample @c ada
+pragma Remote_Access_Type ([Entity =] formal_access_type_LOCAL_NAME);
+@end smallexample
+
+@noindent
+This pragma appears in the formal part of a generic declaration.
+It specifies an exception to the RM rule from E.2.2(17/2), which forbids
+the use of a remote access to class-wide type as actual for a formal
+access type.
+
+When this pragma applies to a formal access type @code{Entity}, that
+type is treated as a remote access to class-wide type in the generic.
+It must be a formal general access type, and its designated type must
+be the class-wide type of a formal tagged limited private type from the
+same generic declaration.
+
+In the generic unit, the formal type is subject to all restrictions
+pertaining to remote access to class-wide types. At instantiation, the
+actual type must be a remote access to class-wide type.
+
@node Pragma Restriction_Warnings
@unnumberedsec Pragma Restriction_Warnings
@findex Restriction_Warnings
@@ -16803,6 +16831,7 @@
@item @code{Predicate} @tab
@item @code{Preelaborable_Initialization} @tab
@item @code{Pure_Function} @tab -- GNAT
+@item @code{Remote_Access_Type} @tab-- GNAT
@item @code{Shared} @tab-- GNAT
@item @code{Size} @tab
@item @code{Storage_Pool} @tab
Index: sem_dist.adb
===
--- sem_dist.adb(revision 183694)
+++ sem_dist.adb(working copy)
@@ -6,7 +6,7 @@
-- --
-- B o d y --
-- --
--- Copyright (C) 1992-2010, Free Software Foundation, Inc. --
+-- Copyright (C) 1992-2012, Free Software Foundation, Inc. --
-- --
-- GNAT is free software; you can redistribute it and/or modify it under --
-- terms of the GNU General Public License as published by the Free Soft- --
@@ -287,6 +287,50 @@
end case;
end Is_RACW_Stub_Type_Operation;
+ -
+ -- Is_Valid_Remote_Object_Type --
+ -
+
+ function Is_Valid_Remote_Object_Type (E : Entity_Id) return Boolean is
+ P : constant Node_Id := Parent (E);
+
+ begin
+ pragma Assert (Is_Tagged_Type (E));
+
+ -- Simple case: a limited private type
+
+ if Nkind (P) = N_Private_Type_Declaration
+and then Is_Limited_Record (E)
+ then
+ return True;
+
+ -- AI05-0060 (Binding Interpretation): A limited interface is a legal
+ -- ancestor for the designated type of an RACW type.
+
+ elsif
[Ada] Minor changes for GNAT dimensionality checking system
Tested on x86_64-pc-linux-gnu, committed on trunk 2012-01-30 Vincent Pucci pu...@adacore.com * sem_dim.adb (Expand_Put_Call_With_Dimension_Symbol): Rewritten. * snames.ads-tmpl: Name_Item and Name_Symbols added. * s-diflio.adb, s-diflio.ads, s-diinio.adb, s-diinio.ads: Rename and change the position of parameter Symbols in every Put routine. * s-dimmks.ads: Convert long float type Mks_Type into long long float. * s-llflex.ads: Modifications in comments. Index: s-diinio.adb === --- s-diinio.adb(revision 183694) +++ s-diinio.adb(working copy) @@ -6,7 +6,7 @@ -- -- -- B o d y -- -- -- ---Copyright (C) 2011, Free Software Foundation, Inc.-- +-- Copyright (C) 2011-2012, Free Software Foundation, Inc. -- -- -- -- GNAT is free software; you can redistribute it and/or modify it under -- -- terms of the GNU General Public License as published by the Free Soft- -- @@ -38,40 +38,40 @@ - procedure Put - (File : File_Type; - Item : Num_Dim_Integer; - Unit : String := ; - Width : Field := Default_Width; - Base : Number_Base := Default_Base) + (File: File_Type; + Item: Num_Dim_Integer; + Width : Field := Default_Width; + Base: Number_Base := Default_Base; + Symbols : String := ) is begin Num_Dim_Integer_IO.Put (File, Item, Width, Base); - Ada.Text_IO.Put (File, Unit); + Ada.Text_IO.Put (File, Symbols); end Put; procedure Put - (Item : Num_Dim_Integer; - Unit : String := ; - Width : Field := Default_Width; - Base : Number_Base := Default_Base) + (Item: Num_Dim_Integer; + Width : Field := Default_Width; + Base: Number_Base := Default_Base; + Symbols : String := ) is begin Num_Dim_Integer_IO.Put (Item, Width, Base); - Ada.Text_IO.Put (Unit); + Ada.Text_IO.Put (Symbols); end Put; procedure Put - (To: out String; - Item : Num_Dim_Integer; - Unit : String := ; - Base : Number_Base := Default_Base) + (To : out String; + Item: Num_Dim_Integer; + Base: Number_Base := Default_Base; + Symbols : String := ) is begin Num_Dim_Integer_IO.Put (To, Item, Base); - To := To Unit; + To := To Symbols; end Put; end System.Dim_Integer_IO; Index: s-diinio.ads === --- s-diinio.ads(revision 183694) +++ s-diinio.ads(working copy) @@ -6,7 +6,7 @@ -- -- -- S p e c -- -- -- ---Copyright (C) 2011, Free Software Foundation, Inc.-- +-- Copyright (C) 2011-2012, Free Software Foundation, Inc. -- -- -- -- GNAT is free software; you can redistribute it and/or modify it under -- -- terms of the GNU General Public License as published by the Free Soft- -- @@ -47,23 +47,23 @@ Default_Base : Number_Base := 10; procedure Put - (File : File_Type; - Item : Num_Dim_Integer; - Unit : String := ; - Width : Field := Default_Width; - Base : Number_Base := Default_Base); + (File: File_Type; + Item: Num_Dim_Integer; + Width : Field := Default_Width; + Base: Number_Base := Default_Base; + Symbols : String := ); procedure Put - (Item : Num_Dim_Integer; - Unit : String := ; - Width : Field := Default_Width; - Base : Number_Base := Default_Base); + (Item: Num_Dim_Integer; + Width : Field := Default_Width; + Base: Number_Base := Default_Base; + Symbols : String := ); procedure Put - (To: out String; - Item : Num_Dim_Integer; - Unit : String := ; - Base : Number_Base := Default_Base); + (To : out String; + Item: Num_Dim_Integer; + Base: Number_Base := Default_Base; + Symbols : String := ); pragma Inline (Put); Index: sem_dim.adb === --- sem_dim.adb (revision 183694) +++ sem_dim.adb (working copy) @@ -6,7 +6,7 @@ --
[Ada] Freezing of nested generic instantiations
This patch corrects machinery which detects whether one node appears earlier in the tree with respect to another node. Tested on x86_64-pc-linux-gnu, committed on trunk 2012-01-30 Hristian Kirtchev kirtc...@adacore.com * sem_ch12.adb (Earlier): Do not use the top level source locations of the two input nodes. Index: sem_ch12.adb === --- sem_ch12.adb(revision 183698) +++ sem_ch12.adb(working copy) @@ -7142,13 +7142,12 @@ end if; -- At this point either both nodes came from source or we approximated - -- their source locations through neighbouring source statements. + -- their source locations through neighbouring source statements. There + -- is no need to look at the top level locations of P1 and P2 because + -- both nodes are in the same list and whether the enclosing context is + -- instantiated is irrelevant. - if Top_Level_Location (Sloc (P1)) Top_Level_Location (Sloc (P2)) then - return True; - else - return False; - end if; + return Sloc (P1) Sloc (P2); end Earlier; --
[Ada] Stand-Alone Library with attribute Interfaces
A library project with an attribute Interfaces that include one or several Ada units was not deemed a Stand-Alone Library project. This patch corrects this. The test for this is to build a project such as: project Prj is for Library_Name use prj; for Library_Dir use lib; for Interfaces use (pkg.ads); end Prj; The project should be a Stand_Alone Library project. Tested on x86_64-pc-linux-gnu, committed on trunk 2012-01-30 Vincent Celier cel...@adacore.com * prj-nmsc.adb (Check_Interfaces): Compute the Lib_Interface_ALIs for the project if either attribute Library_Interface or Interfaces is declared. (Check_Stand_Alone_Library): Use Lib_Interface_ALIs computed in Check_Interfaces. Index: prj-nmsc.adb === --- prj-nmsc.adb(revision 183702) +++ prj-nmsc.adb(working copy) @@ -2554,6 +2554,8 @@ Project_2 : Project_Id; Other : Source_Id; + Interface_ALIs : String_List_Id := Nil_String; + begin if not Interfaces.Default then @@ -2599,6 +2601,31 @@ Other.Declared_In_Interfaces := True; end if; +if Source.Language.Config.Kind = Unit_Based then + if Source.Kind = Spec + and then Other_Part (Source) /= No_Source + then + Source := Other_Part (Source); + end if; + + String_Element_Table.Increment_Last + (Shared.String_Elements); + + Shared.String_Elements.Table + (String_Element_Table.Last +(Shared.String_Elements)) := + (Value = Name_Id (Source.Dep_Name), + Index = 0, + Display_Value = Name_Id (Source.Dep_Name), + Location = No_Location, + Flag = False, + Next = Interface_ALIs); + + Interface_ALIs := + String_Element_Table.Last + (Shared.String_Elements); +end if; + Debug_Output (interface: , Name_Id (Source.Path.Name)); end if; @@ -2627,6 +2654,7 @@ end loop; Project.Interfaces_Defined := True; + Project.Lib_Interface_ALIs := Interface_ALIs; elsif Project.Library and then not Library_Interface.Default then @@ -2668,6 +2696,7 @@ if not Source.Locally_Removed then Source.In_Interfaces := True; Source.Declared_In_Interfaces := True; +Project.Interfaces_Defined := True; Other := Other_Part (Source); @@ -2678,6 +2707,28 @@ Debug_Output (interface: , Name_Id (Source.Path.Name)); + +if Source.Kind = Spec + and then Other_Part (Source) /= No_Source +then + Source := Other_Part (Source); +end if; + +String_Element_Table.Increment_Last + (Shared.String_Elements); + +Shared.String_Elements.Table + (String_Element_Table.Last + (Shared.String_Elements)) := + (Value = Name_Id (Source.Dep_Name), + Index = 0, + Display_Value = Name_Id (Source.Dep_Name), + Location = No_Location, + Flag = False, + Next = Interface_ALIs); + +Interface_ALIs := + String_Element_Table.Last (Shared.String_Elements); end if; exit Big_Loop_2; @@ -2692,7 +2743,7 @@ List := Element.Next; end loop; - Project.Interfaces_Defined := True; + Project.Lib_Interface_ALIs := Interface_ALIs; elsif Project.Extends /= No_Project and then Project.Extends.Interfaces_Defined @@ -2710,6 +2761,8 @@ Next (Iter); end loop; + + Project.Lib_Interface_ALIs := Project.Extends.Lib_Interface_ALIs; end if; end Check_Interfaces; @@ -4282,12 +4335,6 @@ Project.Decl.Attributes, Shared); - Lib_Interfaces : constant Prj.Variable_Value := -
New Swedish PO file for 'cpplib' (version 4.7-b20120128)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'cpplib' has been submitted by the Swedish team of translators. The file is available at: http://translationproject.org/latest/cpplib/sv.po (This file, 'cpplib-4.7-b20120128.sv.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/cpplib/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/cpplib.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator. coordina...@translationproject.org
Contents of PO file 'cpplib-4.7-b20120128.sv.po'
cpplib-4.7-b20120128.sv.po.gz Description: Binary data The Translation Project robot, in the name of your translation coordinator. coordina...@translationproject.org
[Ada] Improve quality of PRNG seeding
When seeding the System.Random_Numbers from the clock, the clock value used to be truncated to whole seconds. This does not occur anymore, and the full resolution of the clock value is now used. Tested on x86_64-pc-linux-gnu, committed on trunk 2012-01-30 Thomas Quinot qui...@adacore.com * s-rannum.adb, s-ransee.adb, s-ransee.ads (Get_Seed): Return Unsigned_64 rather than Duration. (System.Random_Numbers.Reset): Use full value of seed (do not truncate sub-second bits). Index: s-rannum.adb === --- s-rannum.adb(revision 183694) +++ s-rannum.adb(working copy) @@ -6,7 +6,7 @@ -- -- -- B o d y -- -- -- --- Copyright (C) 2007-2011, Free Software Foundation, Inc. -- +-- Copyright (C) 2007-2012, Free Software Foundation, Inc. -- -- -- -- GNAT is free software; you can redistribute it and/or modify it under -- -- terms of the GNU General Public License as published by the Free Soft- -- @@ -480,12 +480,8 @@ --- procedure Reset (Gen : Generator) is - X : constant Unsigned_32 := -Unsigned_32'Mod (Unsigned_64 (Random_Seed.Get_Seed) * 64); - -- Why * 64 ??? - begin - Init (Gen, X); + Init (Gen, Unsigned_32'Mod (Random_Seed.Get_Seed)); end Reset; procedure Reset (Gen : Generator; Initiator : Integer_32) is Index: s-ransee.adb === --- s-ransee.adb(revision 183694) +++ s-ransee.adb(working copy) @@ -6,7 +6,7 @@ -- -- -- B o d y -- -- -- --- Copyright (C) 2011, Free Software Foundation, Inc. -- +-- Copyright (C) 2011-2012, Free Software Foundation, Inc. -- -- -- -- GNAT is free software; you can redistribute it and/or modify it under -- -- terms of the GNU General Public License as published by the Free Soft- -- @@ -32,16 +32,24 @@ -- Version used on all systems except Ravenscar where Calendar is unavailable with Ada.Calendar; use Ada.Calendar; +with Ada.Unchecked_Conversion; package body System.Random_Seed is Y2K : constant Time := Time_Of (Year = 2000, Month = 1, Day = 1, Seconds = 0.0); - -- First day of Year 2000, to get a duration. + -- First day of Year 2000, to get a duration - function Get_Seed return Duration is + function To_U64 is + new Ada.Unchecked_Conversion (Duration, Interfaces.Unsigned_64); + + -- + -- Get_Seed -- + -- + + function Get_Seed return Interfaces.Unsigned_64 is begin - return Clock - Y2K; + return To_U64 (Clock - Y2K); end Get_Seed; end System.Random_Seed; Index: s-ransee.ads === --- s-ransee.ads(revision 183705) +++ s-ransee.ads(working copy) @@ -6,7 +6,7 @@ -- -- -- S p e c -- -- -- ---Copyright (C) 2011-2012, Free Software Foundation, Inc. -- +-- Copyright (C) 2011-2012, Free Software Foundation, Inc. -- -- -- -- GNAT is free software; you can redistribute it and/or modify it under -- -- terms of the GNU General Public License as published by the Free Soft- -- @@ -39,9 +39,11 @@ -- This is required because Ada.Calendar cannot be used on Ravenscar, but -- Ada.Real_Time drags in the whole tasking runtime on regular platforms. +with Interfaces; + package System.Random_Seed is - function Get_Seed return Duration; + function Get_Seed return Interfaces.Unsigned_64; -- Get a seed based on the clock end System.Random_Seed;
[Ada] Leap second for 2012
This patch updates all necessary files to accomodate the new leap second added on 2012-06-30 as defined in IERS Bulletin C. Tested on x86_64-pc-linux-gnu, committed on trunk 2012-01-30 Hristian Kirtchev kirtc...@adacore.com * a-calend-vms.adb, a-calend.adb: Increment the number of leap seconds to 25 and add the hard time value for 2012-06-30. * xleaps.adb: Update the comment on which tests need to be modified each time a new leap second is added. Increment the number of leap seconds to 25 and add the new date for 2012. Index: a-calend.adb === --- a-calend.adb(revision 183694) +++ a-calend.adb(working copy) @@ -155,7 +155,7 @@ Leap_Support : constant Boolean := (Flag = 1); -- Flag to controls the usage of leap seconds in all Ada.Calendar routines - Leap_Seconds_Count : constant Natural := 24; + Leap_Seconds_Count : constant Natural := 25; - -- Local Constants -- @@ -237,7 +237,8 @@ -48125663800, -47651327790, -45442079780, - -44495135770); + -44495135770, + -43391807760); - -- + -- Index: a-calend-vms.adb === --- a-calend-vms.adb(revision 183694) +++ a-calend-vms.adb(working copy) @@ -6,7 +6,7 @@ -- -- -- B o d y -- -- -- --- Copyright (C) 1992-2009, Free Software Foundation, Inc. -- +-- Copyright (C) 1992-2012, Free Software Foundation, Inc. -- -- -- -- GNAT is free software; you can redistribute it and/or modify it under -- -- terms of the GNU General Public License as published by the Free Soft- -- @@ -126,7 +126,7 @@ -- The above flag controls the usage of leap seconds in all Ada.Calendar -- routines. - Leap_Seconds_Count : constant Natural := 24; + Leap_Seconds_Count : constant Natural := 25; - -- Local Constants -- @@ -177,7 +177,8 @@ 437443202, 4421865621000, 4642790422000, - 4737484823000); + 4737484823000, + 4847817624000); - -- + --
[Patch,AVR]: avr.md code clean-up
This is code clean-up for avr.md.
* It resolves all AS1 and AS2 macros for string insertion.
There are plan strings now and no more needed because:
* All deprecated * quoted-c-code transformed to { c-code }.
so that avr.md matches http://gcc.gnu.org/backends.html
now, i.e. no 'b' in the avr line.
* insn-condition optimize or optimize 0 is redundant with
combine patterns as combine does not run at -O0
* Some minor coding style changes
For the AS1/AS2 removal I used the attached awk.
Ok to apply?
Johann
* config/avr/avr.md: Resolve all AS1 and AS2 macros.
Transform all * quoted-c-code to { c-code }.
Remove redundant test for optimize in combine patterns.
Move (include avr-dimode.md) to end of file.
Index: config/avr/avr.md
===
--- config/avr/avr.md (revision 183695)
+++ config/avr/avr.md (working copy)
@@ -1152,7 +1152,7 @@ (define_insn addsi3
};
if (*asm_code[which_alternative])
- return asm_code [which_alternative];
+ return asm_code[which_alternative];
return avr_out_plus (operands, NULL, NULL);
}
@@ -1221,7 +1221,7 @@ (define_insn addpsi3
};
if (*asm_code[which_alternative])
- return asm_code [which_alternative];
+ return asm_code[which_alternative];
return avr_out_plus (operands, NULL, NULL);
}
@@ -1346,13 +1346,13 @@ (define_expand mulqi3
(mult:QI (match_operand:QI 1 register_operand )
(match_operand:QI 2 register_operand )))]
- {
- if (!AVR_HAVE_MUL)
-{
- emit_insn (gen_mulqi3_call (operands[0], operands[1], operands[2]));
- DONE;
-}
-})
+ {
+if (!AVR_HAVE_MUL)
+ {
+emit_insn (gen_mulqi3_call (operands[0], operands[1], operands[2]));
+DONE;
+ }
+ })
(define_insn *mulqi3_enh
[(set (match_operand:QI 0 register_operand =r)
@@ -4381,7 +4381,9 @@ (define_insn *sbrx_branchmode
(label_ref (match_operand 3 ))
(pc)))]
- * return avr_out_sbxx_branch (insn, operands);
+ {
+return avr_out_sbxx_branch (insn, operands);
+ }
[(set (attr length)
(if_then_else (and (ge (minus (pc) (match_dup 3)) (const_int -2046))
(le (minus (pc) (match_dup 3)) (const_int 2046)))
@@ -4559,8 +4561,9 @@ (define_insn difficult_branch
(label_ref (match_operand 0 ))
(pc)))]
- *
- return ret_cond_branch (operands[1], avr_jump_mode (operands[0],insn), 0);
+ {
+return ret_cond_branch (operands[1], avr_jump_mode (operands[0], insn), 0);
+ }
[(set_attr type branch1)
(set_attr cc clobber)])
@@ -4574,8 +4577,9 @@ (define_insn rvbranch
(pc)
(label_ref (match_operand 0 ]
- *
- return ret_cond_branch (operands[1], avr_jump_mode (operands[0], insn), 1);
+ {
+return ret_cond_branch (operands[1], avr_jump_mode (operands[0], insn), 1);
+ }
[(set_attr type branch1)
(set_attr cc clobber)])
@@ -4587,8 +4591,9 @@ (define_insn difficult_rvbranch
(pc)
(label_ref (match_operand 0 ]
- *
- return ret_cond_branch (operands[1], avr_jump_mode (operands[0], insn), 1);
+ {
+return ret_cond_branch (operands[1], avr_jump_mode (operands[0], insn), 1);
+ }
[(set_attr type branch)
(set_attr cc clobber)])
@@ -4769,10 +4774,9 @@ (define_expand casesi
(use (label_ref (match_dup 3)))
(clobber (match_dup 6))])]
-
-{
- operands[6] = gen_reg_rtx (HImode);
-})
+ {
+operands[6] = gen_reg_rtx (HImode);
+ })
;; ^^
@@ -4791,7 +4795,7 @@ (define_insn *cbi
[(set (mem:QI (match_operand 0 low_io_address_operand n))
(and:QI (mem:QI (match_dup 0))
(match_operand:QI 1 single_zero_operand n)))]
- optimize 0
+
{
operands[2] = GEN_INT (exact_log2 (~INTVAL (operands[1]) 0xff));
return cbi %i0,%2;
@@ -4803,7 +4807,7 @@ (define_insn *sbi
[(set (mem:QI (match_operand 0 low_io_address_operand n))
(ior:QI (mem:QI (match_dup 0))
(match_operand:QI 1 single_one_operand n)))]
- optimize 0
+
{
operands[2] = GEN_INT (exact_log2 (INTVAL (operands[1]) 0xff));
return sbi %i0,%2;
@@ -4823,8 +4827,10 @@ (define_insn *sbix_branch
(const_int 0)])
(label_ref (match_operand 3 ))
(pc)))]
- (optimize 0)
- * return avr_out_sbxx_branch (insn, operands);
+
+ {
+return avr_out_sbxx_branch (insn, operands);
+ }
[(set (attr length)
(if_then_else (and (ge (minus (pc) (match_dup 3)) (const_int -2046))
(le (minus (pc) (match_dup 3)) (const_int 2046)))
@@ -4843,7 +4849,7 @@ (define_insn *sbix_branch_bit7
(const_int 0)])
(label_ref (match_operand 2 ))
(pc)))]
- (optimize 0)
+
{
operands[3] = operands[2];
operands[2] = GEN_INT (7);
@@ -4870,8 +4876,10 @@ (define_insn
[Ada] PR ada/15846 Reject self-renaming of subprogram declaration
The compiler does not report an error on the self renaming of a subprogram declaration when the renamed subprogram is referenced through its expanded name. After this patch the following test is rejected by the compiler: package Renamings1 is type T1 is tagged null record; function = (left, right : in T1) return Boolean renames Renamings1.=; end Renamings1; $ gcc -c renamings1.ads renamings1.ads:5:06: subprogram cannot rename itself Tested on x86_64-pc-linux-gnu, committed on trunk 2012-01-30 Javier Miranda mira...@adacore.com PR ada/15846 * sem_ch8.adb (Analyze_Subprogram_Renaming): Handle self-renaming when the renamed entity is referenced using its expanded name. Index: sem_ch8.adb === --- sem_ch8.adb (revision 183694) +++ sem_ch8.adb (working copy) @@ -6,7 +6,7 @@ -- -- -- B o d y -- -- -- --- Copyright (C) 1992-2011, Free Software Foundation, Inc. -- +-- Copyright (C) 1992-2012, Free Software Foundation, Inc. -- -- -- -- GNAT is free software; you can redistribute it and/or modify it under -- -- terms of the GNU General Public License as published by the Free Soft- -- @@ -2665,7 +2665,10 @@ if not Is_Actual and then (Old_S = New_S or else (Nkind (Nam) /= N_Expanded_Name -and then Chars (Old_S) = Chars (New_S))) +and then Chars (Old_S) = Chars (New_S)) + or else (Nkind (Nam) = N_Expanded_Name +and then Entity (Prefix (Nam)) = Current_Scope +and then Chars (Selector_Name (Nam)) = Chars (New_S))) then Error_Msg_N (subprogram cannot rename itself, N); end if;
[Ada] Implement new warnings for suspicious mod values
This patch implements additional warnings for suspicious mod values as shown by the following test program. These warnings are under control of the warning flag -gnatw.m (on by default). 1. package susmod is 2.type r is mod 2 * 32; | warning: suspicious mod value, was ** intended? 3.H : Integer := 2458; 4.J : Integer := H mod 2 * 32; | warning: suspicious mod value, was ** intended? 5. end susmod; Tested on x86_64-pc-linux-gnu, committed on trunk 2012-01-30 Robert Dewar de...@adacore.com * sem.adb (Analyze): Call Analyze_Mod for N_Op_Mod mode. * sem_ch3.adb (Modular_Type_Declaration): Warn on mod value of form 2 * small-literal. * sem_ch4.adb (Analyze_Mod): New procedure (warn on suspicious mod value). * sem_ch4.ads (Analyze_Mod): New procedure. Index: sem_ch3.adb === --- sem_ch3.adb (revision 183704) +++ sem_ch3.adb (working copy) @@ -16808,6 +16808,21 @@ -- Start of processing for Modular_Type_Declaration begin + -- If the mod expression is (exactly) 2 * literal, where literal is + -- 64 or less,then almost certainly the * was meant to be **. Warn! + + if Warn_On_Suspicious_Modulus_Value +and then Nkind (Mod_Expr) = N_Op_Multiply +and then Nkind (Left_Opnd (Mod_Expr)) = N_Integer_Literal +and then Intval (Left_Opnd (Mod_Expr)) = Uint_2 +and then Nkind (Right_Opnd (Mod_Expr)) = N_Integer_Literal +and then Intval (Right_Opnd (Mod_Expr)) = Uint_64 + then + Error_Msg_N (suspicious MOD value, was '*'* intended'??, Mod_Expr); + end if; + + -- Proceed with analysis of mod expression + Analyze_And_Resolve (Mod_Expr, Any_Integer); Set_Etype (T, T); Set_Ekind (T, E_Modular_Integer_Type); Index: sem.adb === --- sem.adb (revision 183694) +++ sem.adb (working copy) @@ -6,7 +6,7 @@ -- -- -- B o d y -- -- -- --- Copyright (C) 1992-2011, Free Software Foundation, Inc. -- +-- Copyright (C) 1992-2012, Free Software Foundation, Inc. -- -- -- -- GNAT is free software; you can redistribute it and/or modify it under -- -- terms of the GNU General Public License as published by the Free Soft- -- @@ -376,7 +376,7 @@ Analyze_Unary_Op (N); when N_Op_Mod = -Analyze_Arithmetic_Op (N); +Analyze_Mod (N); when N_Op_Multiply = Analyze_Arithmetic_Op (N); Index: sem_ch4.adb === --- sem_ch4.adb (revision 183694) +++ sem_ch4.adb (working copy) @@ -6,7 +6,7 @@ -- -- -- B o d y -- -- -- --- Copyright (C) 1992-2011, Free Software Foundation, Inc. -- +-- Copyright (C) 1992-2012, Free Software Foundation, Inc. -- -- -- -- GNAT is free software; you can redistribute it and/or modify it under -- -- terms of the GNU General Public License as published by the Free Soft- -- @@ -62,6 +62,7 @@ with Sinfo;use Sinfo; with Snames; use Snames; with Tbuild; use Tbuild; +with Uintp;use Uintp; package body Sem_Ch4 is @@ -2637,6 +2638,34 @@ end if; end Analyze_Membership_Op; + - + -- Analyze_Mod -- + - + + procedure Analyze_Mod (N : Node_Id) is + begin + -- A special warning check, if we have an expression of the form: + --expr mod 2 * literal + -- where literal is 64 or less, then probably what was meant was + --expr mod 2 ** literal + -- so issue an appropriate warning. + + if Warn_On_Suspicious_Modulus_Value +and then Nkind (Right_Opnd (N)) = N_Integer_Literal +and then Intval (Right_Opnd (N)) = Uint_2 +and then Nkind (Parent (N)) = N_Op_Multiply +and then Nkind (Right_Opnd (Parent (N))) = N_Integer_Literal +and then Intval (Right_Opnd (Parent (N))) = Uint_64 + then + Error_Msg_N + (suspicious MOD value, was '*'* intended'??, Parent (N)); + end if; + + -- Remaining processing is same as for other arithmetic operators + + Analyze_Arithmetic_Op (N); + end Analyze_Mod; +
[Ada] Vector must check for cursor tampering, not element tampering
The operations Sort and Reverse_Element previously checked for element tampering, instead of for cursor tampering. This is not quite right, since the exception behavior for the vector container must match that for the list container, and the list container checks for cursor tampering in those cases. So we check for cursor tampering here (which will catch more things), instead of for element tampering (which will catch fewer things). It's true that the elements of these vector containers could be safely moved around while (say) an iteration is taking place (iteration only increments the busy counter), and so technically all we would need here is a test for element tampering (indicated by the lock counter), that's simply an artifact of our array-based implementation. Logically these operations require a check for cursor tampering. Tested on x86_64-pc-linux-gnu, committed on trunk 2012-01-30 Matthew Heaney hea...@adacore.com * a-convec.adb, a-coinve.adb, a-cobove.adb (Sort, Reverse_Elements): Check for cursor tampering. Index: a-coinve.adb === --- a-coinve.adb(revision 183694) +++ a-coinve.adb(working copy) @@ -6,7 +6,7 @@ -- -- -- B o d y -- -- -- --- Copyright (C) 2004-2011, Free Software Foundation, Inc. -- +-- Copyright (C) 2004-2012, Free Software Foundation, Inc. -- -- -- -- GNAT is free software; you can redistribute it and/or modify it under -- -- terms of the GNU General Public License as published by the Free Soft- -- @@ -1396,7 +1396,6 @@ -- procedure Sort (Container : in out Vector) is - procedure Sort is new Generic_Array_Sort (Index_Type = Index_Type, Element_Type = Element_Access, @@ -1410,9 +1409,20 @@ return; end if; - if Container.Lock 0 then + -- The exception behavior for the vector container must match that + -- for the list container, so we check for cursor tampering here + -- (which will catch more things) instead of for element tampering + -- (which will catch fewer things). It's true that the elements of + -- this vector container could be safely moved around while (say) an + -- iteration is taking place (iteration only increments the busy + -- counter), and so technically all we would need here is a test for + -- element tampering (indicated by the lock counter), that's simply + -- an artifact of our array-based implementation. Logically Sort + -- requires a check for cursor tampering. + + if Container.Busy 0 then raise Program_Error with - attempt to tamper with elements (vector is locked); + attempt to tamper with cursors (vector is busy); end if; Sort (Container.Elements.EA (Index_Type'First .. Container.Last)); @@ -3417,9 +3427,20 @@ return; end if; - if Container.Lock 0 then + -- The exception behavior for the vector container must match that for + -- the list container, so we check for cursor tampering here (which will + -- catch more things) instead of for element tampering (which will catch + -- fewer things). It's true that the elements of this vector container + -- could be safely moved around while (say) an iteration is taking place + -- (iteration only increments the busy counter), and so technically all + -- we would need here is a test for element tampering (indicated by the + -- lock counter), that's simply an artifact of our array-based + -- implementation. Logically Reverse_Elements requires a check for + -- cursor tampering. + + if Container.Busy 0 then raise Program_Error with - attempt to tamper with elements (vector is locked); + attempt to tamper with cursors (vector is busy); end if; declare Index: a-cobove.adb === --- a-cobove.adb(revision 183694) +++ a-cobove.adb(working copy) @@ -6,7 +6,7 @@ -- -- -- B o d y -- -- -- --- Copyright (C) 2004-2011, Free Software Foundation, Inc. -- +-- Copyright (C) 2004-2012, Free Software Foundation, Inc. -- -- --
Re: [PATCH] Fix PR 51505
Does this help? Yep, this eliminates all the regressions, thanks! -- Eric Botcazou
Re: [PATCH] Fix PR 51505
That would fix the problem of multiple notes per insn (as we wanted to do initially), but I didn't understand whether this is the real problem or the problem is the reload not happy with disappearing notes. reload maintains a mapping between its internal structures and the RTL stream, here between reg_equiv_* fields and REG_EQUIV notes. It simply isn't prepared to deal with the case where this mapping is broken behind its back. -- Eric Botcazou
[PATCH] Fix PR52037
IPA inline transform does not account for the fact that execute_fixup_cfg may return TODO_update_ssa. Fixed as follows. Bootstrap and regtest running on x86_64-unknown-linux-gnu. Richard. 2012-01-30 Richard Guenther rguent...@suse.de PR tree-optimization/52045 * ipa-inline-transform.c (inline_transform): Call execute_fixup_cfg before computing final todo. Index: gcc/ipa-inline-transform.c === --- gcc/ipa-inline-transform.c (revision 183695) +++ gcc/ipa-inline-transform.c (working copy) @@ -369,11 +369,13 @@ inline_transform (struct cgraph_node *no todo = optimize_inline_calls (current_function_decl); timevar_pop (TV_INTEGRATION); + cfun-always_inline_functions_inlined = true; + cfun-after_inlining = true; + todo |= execute_fixup_cfg (); + if (!(todo TODO_update_ssa_any)) /* Redirecting edges might lead to a need for vops to be recomputed. */ todo |= TODO_update_ssa_only_virtuals; - cfun-always_inline_functions_inlined = true; - cfun-after_inlining = true; - return todo | execute_fixup_cfg (); + return todo; }
[PATCH] Fix PR52045
cleanup_tree_cfg can make it necessary to update SSA form. The following
reflects that in execute_cleanup_cfg_post_optimizing (other callers
look safe as they are embedded in more complex passes updating SSA form
anyways).
Bootstrap and regtest pending on x86_64-unknown-linux-gnu.
Richard.
2012-01-30 Richard Guenther rguent...@suse.de
PR tree-optimization/52045
* tree-optimize.c (execute_cleanup_cfg_post_optimizing): Update
SSA form if cfgcleanup did anything.
* gcc.dg/pr52045.c: New testcase.
Index: gcc/tree-optimize.c
===
--- gcc/tree-optimize.c (revision 183695)
+++ gcc/tree-optimize.c (working copy)
@@ -157,7 +157,9 @@ struct gimple_opt_pass pass_all_early_op
static unsigned int
execute_cleanup_cfg_post_optimizing (void)
{
- cleanup_tree_cfg ();
+ unsigned int todo = 0;
+ if (cleanup_tree_cfg ())
+todo |= TODO_update_ssa;
maybe_remove_unreachable_handlers ();
cleanup_dead_labels ();
group_case_labels ();
@@ -190,7 +192,7 @@ execute_cleanup_cfg_post_optimizing (voi
}
}
}
- return 0;
+ return todo;
}
struct gimple_opt_pass pass_cleanup_cfg_post_optimizing =
Index: gcc/testsuite/gcc.dg/pr52045.c
===
--- gcc/testsuite/gcc.dg/pr52045.c (revision 0)
+++ gcc/testsuite/gcc.dg/pr52045.c (revision 0)
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+/* { dg-options -O3 -ftracer -fno-tree-ccp -fno-tree-copy-prop -fno-tree-dce
} */
+
+char *vx;
+char buf[20];
+
+void
+foo (void)
+{
+ vx = __builtin___stpcpy_chk (buf, vx ? gh : e, sizeof(buf));
+}
[SPARC] Fix PR target/51920
I think it's the long-standing issue with word-mode paradoxical subregs of FP
regs in 64-bit mode, which is present on both PA and SPARC. We don't have any
real solution as of this writing, only kludges, so the attached patch makes it
so that vector_init_fpmerge doesn't create pseudos with long live ranges, to
lower the pressure on the register allocator.
Tested on SPARC/Solaris, applied on the mainline.
2012-01-30 Eric Botcazou ebotca...@adacore.com
PR target/51920
* config/sparc/sparc.c (vector_init_fpmerge): Remove INNER_MODE
parameter and use short-lived pseudos.
(vector_init_faligndata): Remove INNER_MODE parameter and use loop.
(sparc_expand_vector_init): Const-ify local variables and adjust
calls to above functions.
--
Eric Botcazou
Index: config/sparc/sparc.c
===
--- config/sparc/sparc.c (revision 183640)
+++ config/sparc/sparc.c (working copy)
@@ -11485,49 +11485,47 @@ vector_init_bshuffle (rtx target, rtx el
emit_insn (final_insn);
}
+/* Subroutine of sparc_expand_vector_init. Emit code to initialize
+ all fields of TARGET to ELT in V8QI by means of VIS FPMERGE insn. */
+
static void
-vector_init_fpmerge (rtx target, rtx elt, enum machine_mode inner_mode)
+vector_init_fpmerge (rtx target, rtx elt)
{
- rtx t1, t2, t3, t3_low;
+ rtx t1, t2, t2_low, t3, t3_low;
t1 = gen_reg_rtx (V4QImode);
- elt = convert_modes (SImode, inner_mode, elt, true);
+ elt = convert_modes (SImode, QImode, elt, true);
emit_move_insn (gen_lowpart (SImode, t1), elt);
- t2 = gen_reg_rtx (V4QImode);
- emit_move_insn (t2, t1);
+ t2 = gen_reg_rtx (V8QImode);
+ t2_low = gen_lowpart (V4QImode, t2);
+ emit_insn (gen_fpmerge_vis (t2, t1, t1));
t3 = gen_reg_rtx (V8QImode);
t3_low = gen_lowpart (V4QImode, t3);
+ emit_insn (gen_fpmerge_vis (t3, t2_low, t2_low));
- emit_insn (gen_fpmerge_vis (t3, t1, t2));
- emit_move_insn (t1, t3_low);
- emit_move_insn (t2, t3_low);
-
- emit_insn (gen_fpmerge_vis (t3, t1, t2));
- emit_move_insn (t1, t3_low);
- emit_move_insn (t2, t3_low);
-
- emit_insn (gen_fpmerge_vis (gen_lowpart (V8QImode, target), t1, t2));
+ emit_insn (gen_fpmerge_vis (target, t3_low, t3_low));
}
+/* Subroutine of sparc_expand_vector_init. Emit code to initialize
+ all fields of TARGET to ELT in V4HI by means of VIS FALIGNDATA insn. */
+
static void
-vector_init_faligndata (rtx target, rtx elt, enum machine_mode inner_mode)
+vector_init_faligndata (rtx target, rtx elt)
{
rtx t1 = gen_reg_rtx (V4HImode);
+ int i;
- elt = convert_modes (SImode, inner_mode, elt, true);
-
+ elt = convert_modes (SImode, HImode, elt, true);
emit_move_insn (gen_lowpart (SImode, t1), elt);
emit_insn (gen_alignaddrsi_vis (gen_reg_rtx (SImode),
force_reg (SImode, GEN_INT (6)),
- CONST0_RTX (SImode)));
+ const0_rtx));
- emit_insn (gen_faligndatav4hi_vis (target, t1, target));
- emit_insn (gen_faligndatav4hi_vis (target, t1, target));
- emit_insn (gen_faligndatav4hi_vis (target, t1, target));
- emit_insn (gen_faligndatav4hi_vis (target, t1, target));
+ for (i = 0; i 4; i++)
+emit_insn (gen_faligndatav4hi_vis (target, t1, target));
}
/* Emit code to initialize TARGET to values for individual fields VALS. */
@@ -11535,9 +11533,9 @@ vector_init_faligndata (rtx target, rtx
void
sparc_expand_vector_init (rtx target, rtx vals)
{
- enum machine_mode mode = GET_MODE (target);
- enum machine_mode inner_mode = GET_MODE_INNER (mode);
- int n_elts = GET_MODE_NUNITS (mode);
+ const enum machine_mode mode = GET_MODE (target);
+ const enum machine_mode inner_mode = GET_MODE_INNER (mode);
+ const int n_elts = GET_MODE_NUNITS (mode);
int i, n_var = 0;
bool all_same;
rtx mem;
@@ -11593,12 +11591,12 @@ sparc_expand_vector_init (rtx target, rt
}
if (mode == V8QImode)
{
- vector_init_fpmerge (target, XVECEXP (vals, 0, 0), inner_mode);
+ vector_init_fpmerge (target, XVECEXP (vals, 0, 0));
return;
}
if (mode == V4HImode)
{
- vector_init_faligndata (target, XVECEXP (vals, 0, 0), inner_mode);
+ vector_init_faligndata (target, XVECEXP (vals, 0, 0));
return;
}
}
Re: [PATCH] Fix PR 51505
On 01/30/2012 01:22 PM, Eric Botcazou wrote: Does this help? Yep, this eliminates all the regressions, thanks! Committed as r183719. Thanks for testing. Paolo
Re: [PATCH] Fix PR51528
On Fri, 27 Jan 2012, Richard Guenther wrote:
This fixes PR51528 by hiding the issue that SRA generates
copy in/out with a type not suitable for preserving the data
(any non-mode-precision thing). It fixes it by instead of
emitting
x$i_8 = x.i;
D.1720 = x;
D.1720.i = x$i_8;
for an assign to an unscalarized D.1720 from a partly scalarized x
(so the aggregate assignment prevails) emit
x.i = x$i_8;
D.1720 = x;
instead. This allows the unfortunate copy in/out to be optimized
away (and thus its undefined behavior).
Basically whenever the aggregate copy will prevail prefer to
restore the RHS and reload the LHS components - just like we
do for aggregate uses/destinations of call statements.
I think we can still clean up the aggregate copy path a lot,
but that's for 4.8 (unless new bugs pop up).
Bootstrap and regtest pending on x86_64-unknown-linux-gnu.
So it turns out this wasn't that easy and I botched up some
of the intricate execution flow in sra_modify_assign. As a
preparation for a smaller fix the following patch refactors
this function to be easier to understand and hopefully make
the real fix obvious in what it does.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2012-01-30 Richard Guenther rguent...@suse.de
PR tree-optimization/51528
* tree-sra.c (sra_modify_assign): Re-factor in preparation
for PR51528 fix.
Index: gcc/tree-sra.c
===
*** gcc/tree-sra.c (revision 183694)
--- gcc/tree-sra.c (working copy)
*** sra_modify_assign (gimple *stmt, gimple_
*** 2991,2996
--- 2991,3006
force_gimple_rhs = true;
sra_stats.exprs++;
}
+ else if (racc
+ !access_has_children_p (racc)
+ !racc-grp_to_be_replaced
+ !racc-grp_unscalarized_data
+ TREE_CODE (lhs) == SSA_NAME)
+ {
+ rhs = get_repl_default_def_ssa_name (racc);
+ modify_this_stmt = true;
+ sra_stats.exprs++;
+ }
if (modify_this_stmt)
{
*** sra_modify_assign (gimple *stmt, gimple_
*** 3067,3072
--- 3077,3097
generate_subtree_copies (lacc-first_child, lacc-base, 0, 0, 0,
gsi, true, true, loc);
sra_stats.separate_lhs_rhs_handling++;
+
+ /* This gimplification must be done after generate_subtree_copies,
+lest we insert the subtree copies in the middle of the gimplified
+sequence. */
+ if (force_gimple_rhs)
+ rhs = force_gimple_operand_gsi (orig_gsi, rhs, true, NULL_TREE,
+ true, GSI_SAME_STMT);
+ if (gimple_assign_rhs1 (*stmt) != rhs)
+ {
+ modify_this_stmt = true;
+ gimple_assign_set_rhs_from_tree (orig_gsi, rhs);
+ gcc_assert (*stmt == gsi_stmt (orig_gsi));
+ }
+
+ return modify_this_stmt ? SRA_AM_MODIFIED : SRA_AM_NONE;
}
else
{
*** sra_modify_assign (gimple *stmt, gimple_
*** 3093,3153
}
else
{
! if (racc)
{
! if (!racc-grp_to_be_replaced !racc-grp_unscalarized_data)
{
! if (dump_file)
! {
! fprintf (dump_file, Removing load: );
! print_gimple_stmt (dump_file, *stmt, 0, 0);
! }
!
! if (TREE_CODE (lhs) == SSA_NAME)
! {
! rhs = get_repl_default_def_ssa_name (racc);
! if (!useless_type_conversion_p (TREE_TYPE (lhs),
! TREE_TYPE (rhs)))
! rhs = fold_build1_loc (loc, VIEW_CONVERT_EXPR,
! TREE_TYPE (lhs), rhs);
! }
! else
! {
! if (racc-first_child)
! generate_subtree_copies (racc-first_child, lhs,
!racc-offset, 0, 0, gsi,
!false, false, loc);
!
! gcc_assert (*stmt == gsi_stmt (*gsi));
! unlink_stmt_vdef (*stmt);
! gsi_remove (gsi, true);
! sra_stats.deleted++;
! return SRA_AM_REMOVED;
! }
}
! else if (racc-first_child)
! generate_subtree_copies (racc-first_child, lhs, racc-offset,
!0, 0, gsi, false, true, loc);
}
if (access_has_children_p (lacc))
generate_subtree_copies (lacc-first_child, rhs, lacc-offset,
0, 0, gsi, true, true, loc);
}
- }
! /* This gimplification must be done after generate_subtree_copies, lest we
!
[PATCH] Fix tail-merging -fcompare-debug failures (PR debug/52048)
Hi!
local_def in tail merging returned different results depending on
if there are any debug uses in other bbs or not.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
2012-01-30 Jakub Jelinek ja...@redhat.com
PR debug/52048
* tree-ssa-tail-merge.c (local_def): Ignore debug uses.
* g++.dg/other/pr52048.C: New test.
--- gcc/tree-ssa-tail-merge.c.jj2012-01-20 12:35:16.0 +0100
+++ gcc/tree-ssa-tail-merge.c 2012-01-30 09:23:05.392367800 +0100
@@ -371,6 +371,8 @@ local_def (tree val)
res = true;
FOR_EACH_IMM_USE_STMT (stmt, iter, val)
{
+ if (is_gimple_debug (stmt))
+ continue;
bb = gimple_bb (stmt);
if (bb == def_bb)
continue;
--- gcc/testsuite/g++.dg/other/pr52048.C.jj 2012-01-30 09:59:53.570759458
+0100
+++ gcc/testsuite/g++.dg/other/pr52048.C2012-01-30 09:59:12.0
+0100
@@ -0,0 +1,79 @@
+// PR debug/52048
+// { dg-do compile }
+// { dg-options -fcompare-debug -fnon-call-exceptions
-fno-tree-dominator-opts -O2 }
+
+template typename T struct A;
+template typename T
+struct A T *
+{
+ typedef T a;
+};
+template typename T
+struct B
+{
+ typedef typename A T::a a;
+ a operator *() {}
+};
+template typename T, typename U
+bool operator != (B T, B U)
+{
+}
+template typename T
+struct C
+{
+ typedef T *c;
+ template typename
+ struct D { typedef C d; };
+};
+template typename T, typename U struct E
+{
+ typedef typename U::template D T::d e;
+};
+template typename T, typename U = C T
+struct F
+{
+ typedef E T, U b;
+ typedef typename b::e e;
+ typedef typename e::c c;
+ typedef B c i;
+ i begin ();
+ i end ();
+};
+class G;
+class H;
+struct I
+{
+ void *i;
+ template typename T T foo ();
+};
+struct J : public I
+{
+ virtual bool bar ();
+};
+class K {};
+struct L
+{
+ bool baz () {}
+};
+struct M
+{
+ K m1 (K);
+ K m2 (H *) {}
+};
+struct N : J
+{
+ bool bar (G );
+};
+bool
+N::bar (G )
+{
+ M m = foo M ();
+ F H * f;
+ for (F H *::i I = f.begin (), E = f.end (); I != E;)
+{
+ H *h = *I;
+ L l;
+ if (l.baz ())
+ m.m1 (m.m2 (h));
+}
+}
Jakub
[PATCH] Fix vectorizer bool pattern matching with -fnon-call-exceptions (PR tree-optimization/52046)
Hi!
If a comparison can throw, it won't be a valid condition for
COND_EXPR or VEC_COND_EXPR, because is_gimple_condexpr will
fail. This patch gives up in that case. Bootstrapped/regtested on
x86_64-linux and i686-linux, ok for trunk?
2012-01-30 Jakub Jelinek ja...@redhat.com
PR tree-optimization/52046
* tree-vect-patterns.c (check_bool_pattern): Give up if
a comparison could throw.
* gcc.dg/pr52046.c: New test.
--- gcc/tree-vect-patterns.c.jj 2012-01-13 21:47:35.0 +0100
+++ gcc/tree-vect-patterns.c2012-01-30 10:58:11.048787682 +0100
@@ -1,5 +1,5 @@
/* Analysis Utilities for Loop Vectorization.
- Copyright (C) 2006, 2007, 2008, 2009, 2010, 2011
+ Copyright (C) 2006, 2007, 2008, 2009, 2010, 2011, 2012
Free Software Foundation, Inc.
Contributed by Dorit Nuzman do...@il.ibm.com
@@ -1967,6 +1967,11 @@ check_bool_pattern (tree var, loop_vec_i
{
tree vecitype, comp_vectype;
+ /* If the comparison can throw, then is_gimple_condexpr will be
+false and we can't make a COND_EXPR/VEC_COND_EXPR out of it. */
+ if (stmt_could_throw_p (def_stmt))
+ return false;
+
comp_vectype = get_vectype_for_scalar_type (TREE_TYPE (rhs1));
if (comp_vectype == NULL_TREE)
return false;
--- gcc/testsuite/gcc.dg/pr52046.c.jj 2012-01-30 10:59:42.749264286 +0100
+++ gcc/testsuite/gcc.dg/pr52046.c 2012-01-30 10:59:28.0 +0100
@@ -0,0 +1,14 @@
+/* PR tree-optimization/52046 */
+/* { dg-do compile } */
+/* { dg-options -O3 -fexceptions -fnon-call-exceptions } */
+
+extern float a[], b[], c[], d[];
+extern int k[];
+
+void
+foo (void)
+{
+ int i;
+ for (i = 0; i 1024; ++i)
+k[i] = (a[i] b[i]) | (c[i] d[i]);
+}
Jakub
[PATCH] Don't ICE in dwarf2out_switch_section with -g0 (PR debug/52027)
Hi!
dwarf2out_switch_text_section is called even when -g0 or when not generating
dwarf debug info, if we need to handle there unwinding stuff.
But with -g0 e.g. line info tables aren't initialized. Already a few lines
above this spot we guard it with cold_text_section != NULL, so this patch
just adds the same check to another needed spot.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2012-01-30 Jakub Jelinek ja...@redhat.com
PR debug/52027
* dwarf2out.c (dwarf2out_switch_text_section): Don't call
set_cur_line_info_table if not emitting debug info.
* gcc.dg/tree-prof/pr52027.c: New test.
--- gcc/dwarf2out.c.jj 2012-01-26 09:22:21.0 +0100
+++ gcc/dwarf2out.c 2012-01-30 12:09:42.186932405 +0100
@@ -1177,7 +1177,8 @@ dwarf2out_switch_text_section (void)
var_location_switch_text_section ();
- set_cur_line_info_table (sect);
+ if (cold_text_section != NULL)
+set_cur_line_info_table (sect);
}
/* And now, the subset of the debugging information support code necessary
--- gcc/testsuite/gcc.dg/tree-prof/pr52027.c.jj 2012-01-30 12:14:37.073184372
+0100
+++ gcc/testsuite/gcc.dg/tree-prof/pr52027.c2012-01-30 12:15:08.042005858
+0100
@@ -0,0 +1,19 @@
+/* PR debug/52027 */
+/* { dg-require-effective-target freorder } */
+/* { dg-options -O -freorder-blocks-and-partition -fno-reorder-functions } */
+
+void
+foo (int len)
+{
+ char array[1000];
+ __builtin_memset (array, 0, len);
+}
+
+int
+main ()
+{
+ int i;
+ for (i = 0; i 1000; i++)
+foo (8);
+ return 0;
+}
Jakub
Re: [PATCH] Fix vectorizer bool pattern matching with -fnon-call-exceptions (PR tree-optimization/52046)
On Mon, Jan 30, 2012 at 2:37 PM, Jakub Jelinek ja...@redhat.com wrote:
Hi!
If a comparison can throw, it won't be a valid condition for
COND_EXPR or VEC_COND_EXPR, because is_gimple_condexpr will
fail. This patch gives up in that case. Bootstrapped/regtested on
x86_64-linux and i686-linux, ok for trunk?
Ok.
Thanks,
Richard.
2012-01-30 Jakub Jelinek ja...@redhat.com
PR tree-optimization/52046
* tree-vect-patterns.c (check_bool_pattern): Give up if
a comparison could throw.
* gcc.dg/pr52046.c: New test.
--- gcc/tree-vect-patterns.c.jj 2012-01-13 21:47:35.0 +0100
+++ gcc/tree-vect-patterns.c 2012-01-30 10:58:11.048787682 +0100
@@ -1,5 +1,5 @@
/* Analysis Utilities for Loop Vectorization.
- Copyright (C) 2006, 2007, 2008, 2009, 2010, 2011
+ Copyright (C) 2006, 2007, 2008, 2009, 2010, 2011, 2012
Free Software Foundation, Inc.
Contributed by Dorit Nuzman do...@il.ibm.com
@@ -1967,6 +1967,11 @@ check_bool_pattern (tree var, loop_vec_i
{
tree vecitype, comp_vectype;
+ /* If the comparison can throw, then is_gimple_condexpr will be
+ false and we can't make a COND_EXPR/VEC_COND_EXPR out of it. */
+ if (stmt_could_throw_p (def_stmt))
+ return false;
+
comp_vectype = get_vectype_for_scalar_type (TREE_TYPE (rhs1));
if (comp_vectype == NULL_TREE)
return false;
--- gcc/testsuite/gcc.dg/pr52046.c.jj 2012-01-30 10:59:42.749264286 +0100
+++ gcc/testsuite/gcc.dg/pr52046.c 2012-01-30 10:59:28.0 +0100
@@ -0,0 +1,14 @@
+/* PR tree-optimization/52046 */
+/* { dg-do compile } */
+/* { dg-options -O3 -fexceptions -fnon-call-exceptions } */
+
+extern float a[], b[], c[], d[];
+extern int k[];
+
+void
+foo (void)
+{
+ int i;
+ for (i = 0; i 1024; ++i)
+ k[i] = (a[i] b[i]) | (c[i] d[i]);
+}
Jakub
Re: [PATCH] Don't ICE in dwarf2out_switch_section with -g0 (PR debug/52027)
On Mon, Jan 30, 2012 at 2:40 PM, Jakub Jelinek ja...@redhat.com wrote:
Hi!
dwarf2out_switch_text_section is called even when -g0 or when not generating
dwarf debug info, if we need to handle there unwinding stuff.
But with -g0 e.g. line info tables aren't initialized. Already a few lines
above this spot we guard it with cold_text_section != NULL, so this patch
just adds the same check to another needed spot.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Ok.
Thanks,
Richard.
2012-01-30 Jakub Jelinek ja...@redhat.com
PR debug/52027
* dwarf2out.c (dwarf2out_switch_text_section): Don't call
set_cur_line_info_table if not emitting debug info.
* gcc.dg/tree-prof/pr52027.c: New test.
--- gcc/dwarf2out.c.jj 2012-01-26 09:22:21.0 +0100
+++ gcc/dwarf2out.c 2012-01-30 12:09:42.186932405 +0100
@@ -1177,7 +1177,8 @@ dwarf2out_switch_text_section (void)
var_location_switch_text_section ();
- set_cur_line_info_table (sect);
+ if (cold_text_section != NULL)
+ set_cur_line_info_table (sect);
}
/* And now, the subset of the debugging information support code necessary
--- gcc/testsuite/gcc.dg/tree-prof/pr52027.c.jj 2012-01-30 12:14:37.073184372
+0100
+++ gcc/testsuite/gcc.dg/tree-prof/pr52027.c 2012-01-30 12:15:08.042005858
+0100
@@ -0,0 +1,19 @@
+/* PR debug/52027 */
+/* { dg-require-effective-target freorder } */
+/* { dg-options -O -freorder-blocks-and-partition -fno-reorder-functions }
*/
+
+void
+foo (int len)
+{
+ char array[1000];
+ __builtin_memset (array, 0, len);
+}
+
+int
+main ()
+{
+ int i;
+ for (i = 0; i 1000; i++)
+ foo (8);
+ return 0;
+}
Jakub
Re: [Patch,wwwdocs,AVR]: AVR release notes
Gerald Pfeifer wrote: On Fri, 20 Jan 2012, Georg-Johann Lay wrote: Adding AVR-specific release notes to wwwdocs/htdocs/gcc-4.7/changes.html Index: changes.html === +liThe AVR port's libgcc has been improved and its multilib structure + has been enhanced. As a result, all objects contributing to an + application must either be compiled with GCC versions up to 4.6.x or + with GCC versions ge;nbsp;4.7./li How about ...compiled with older versions of GCC, up to GCC 4.6.x, or GCC 4.7.0 and later ? The compiled with might be confusing, for example if someone uses a library generated with 4.6 and compiles his application with 4.7. He does not compile the library, but yet he might run into problems because the code assumes a specific layout of libgcc. Therefore I used the all objects wording. It's bit more technical, but I hoped the reduce misunderstandings. And I'd omit the nbsp; just ge;4.7.0 should work? +liSupport has beed added for instrinsic named address spaces Support for...has been added (also typo: beed - been) +code__pgm/code, code__pgm1/code,nbsp;hellip;, code__pgm5/code How about omitting nbsp; here? +and code__pgmx/code. These address spaces locate read-only data in +flash memory and allow reading from flash memory by means of vanilla +Cnbsp;instructions, i.e. without the need of (inline) assembler code./li What's a C instruction? C builtins? Is C code better? Or C-code? Without the extension, inline assembler must be used to get correct code, using C like a = b or pstruct-component will yield wrong code without the extensions if b or *pstruct is located in flash. +liSupport for AVR-specific built-in functions has beed added./li Which ones? Must they all be named explicitly? Or is it ok to link to onlinedocs? I'd prefer a link to the explanation in onlinedocs but I am unsure how stable the links are as docs evolve over time/versions. +liNew command-line options code-maccumulate-args/code, + code-mbranch-cost=icost/i/code and code-mstrict-X/code + were added to allow better fine-tuning of code optimization./li Should X be put under i.../i here, to? No, the X refers to X-register and must be literally, nothing else than uppercase X is permitted. +liMany optimizations to: + ul + li64-bit integer arithmetic/li + liWidening multiplication/li + liInteger divide-by-constant/li division by a constant + liGeneric built-in functions + like code__builtin_ffs*/code, code__builtin_clz*/code,nbsp;etc./li I don't think we need nbsp; here. Breaking the lines here is something a web browser should avoid, but it is not verboten, technically. Tried to get typesetting all right and avoid Hurenkinder, and I really don't know if browsers add penalties like TeX does. I frequently see browsers offend typesetting rules if there is no nanny. What does need no nbsp; mean? Nothing at ,etc. all or blank , etc.? + liMerging of data in code.progmem/code/li What is .progmen? Perhaps paraphrase this briefly? Not easy without getting into too much technical details... Maybe Eric can help. He is definitely better in English than I am. The update is fine assuming you look into my suggestions. Attached an updated patch as there were many changes and so that Eric and Denis can easier catch up. Johann Index: changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v retrieving revision 1.73 diff -u -r1.73 changes.html --- changes.html 12 Jan 2012 19:35:29 - 1.73 +++ changes.html 30 Jan 2012 13:42:13 - @@ -45,6 +45,11 @@ code-compat-bsd/code compiler option is not recognized any longer./li +liThe AVR port's libgcc has been improved and its multilib structure + has been enhanced. As a result, all objects contributing to an + application must either be compiled with GCC versions up to 4.6.x or + with GCC versions 4.7.0 or later./li + liThe ARM port's code-mwords-little-endian/code option has been deprecated. It will be removed in a future release./li @@ -530,6 +535,44 @@ h2 id=targetsNew Targets and Target Specific Improvements/h2 +h3 id=avrAVR/h3 + ul +liSupport for the + a href=http://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html;named address spaces/a + code__flash/code, code__flash1/code,hellip;, + code__flash5/code and code__memx/code has beed added. + These address spaces locate read-only data in + flash memory and allow reading from flash memory by means of ordinary + C code, i.e. without the need of (inline) assembler code./li +liSupport for AVR-specific a href=http://gcc.gnu.org/onlinedocs/gcc/AVR-Built_002din-Functions.html;built-in functions/a + has beed added./li +liSupport has beed added for the
Re: [PATCH] Fix PR 51505
On 30.01.2012 17:47, Paolo Bonzini wrote: On 01/30/2012 09:44 AM, Andrey Belevantsev wrote: Does this help? That would fix the problem of multiple notes per insn (as we wanted to do initially), but I didn't understand whether this is the real problem or the problem is the reload not happy with disappearing notes. Also I can't reproduce it with a cross to sparc64-linux -- when I put a breakpoint on the code removing the notes, I find only similarly looking insn 148 which gets removed from the df_analyze call at the start of IRA. Though I see the fail from SPARC test results on the ML, so I guess I'm missing something... The REG_EQUAL note can go, but the REG_EQUIV note should not (by definition: they are valid throughout the entire function). In fact, we could just as well apply the loop to REG_EQUAL notes only but that would have been a bit too clever and more risky. Eric, Paolo, thanks for the explanations! Andrey
Re: [PATCH] Fix PR 51910, -frepo/linker demangling interaction
On Sun, Jan 29, 2012 at 05:08:10PM -0700, Sandra Loosemore wrote: Bootstrapped and regression-tested on i636 linux. OK to check in? I think that is terribly expensive fix, for larger projects a single ld invocation can take several minutes. What exactly are advantages of using the linker demangling as opposed to collect2 doing the demangling as before? Does it really justify penalizing -frepo that much? Jakub
Re: [Patch ARM] Fix PR50313 and handle PIC addresses properly.
Now backported to GCC 4.6 branch as attached.
Ramana
2012-01-30 Ramana Radhakrishnan ramana.radhakrish...@linaro.org
Backport from mainline.
2012-01-20 Ramana Radhakrishnan ramana.radhakrish...@linaro.org
PR target/50313
* config/arm/arm.c (arm_load_pic_register): Use
gen_pic_load_addr_unified. Delete calls to gen_pic_load_addr_32bit
, gen_pic_add_dot_plus_eight and gen_pic_add_dot_plus_four.
(arm_pic_static_addr): Likewise.
(arm_rtx_costs_1): Adjust cost for UNSPEC_PIC_UNIFIED.
(arm_note_pic_base): Handle UNSPEC_PIC_UNIFIED.
* config/arm/arm.md (UNSPEC_PIC_UNIFIED): Define.
(pic_load_addr_unified): New.
Index: gcc/config/arm/arm.c
===
--- gcc/config/arm/arm.c(revision 183725)
+++ gcc/config/arm/arm.c(working copy)
@@ -5387,11 +5387,7 @@
if (TARGET_32BIT)
{
- emit_insn (gen_pic_load_addr_32bit (pic_reg, pic_rtx));
- if (TARGET_ARM)
- emit_insn (gen_pic_add_dot_plus_eight (pic_reg, pic_reg, labelno));
- else
- emit_insn (gen_pic_add_dot_plus_four (pic_reg, pic_reg, labelno));
+ emit_insn (gen_pic_load_addr_unified (pic_reg, pic_rtx, labelno));
}
else /* TARGET_THUMB1 */
{
@@ -5404,10 +5400,10 @@
thumb_find_work_register (saved_regs));
emit_insn (gen_pic_load_addr_thumb1 (pic_tmp, pic_rtx));
emit_insn (gen_movsi (pic_offset_table_rtx, pic_tmp));
+ emit_insn (gen_pic_add_dot_plus_four (pic_reg, pic_reg, labelno));
}
else
- emit_insn (gen_pic_load_addr_thumb1 (pic_reg, pic_rtx));
- emit_insn (gen_pic_add_dot_plus_four (pic_reg, pic_reg, labelno));
+ emit_insn (gen_pic_load_addr_unified (pic_reg, pic_rtx, labelno));
}
}
@@ -5437,20 +5433,7 @@
UNSPEC_SYMBOL_OFFSET);
offset_rtx = gen_rtx_CONST (Pmode, offset_rtx);
- if (TARGET_32BIT)
-{
- emit_insn (gen_pic_load_addr_32bit (reg, offset_rtx));
- if (TARGET_ARM)
-insn = emit_insn (gen_pic_add_dot_plus_eight (reg, reg, labelno));
- else
-insn = emit_insn (gen_pic_add_dot_plus_four (reg, reg, labelno));
-}
- else /* TARGET_THUMB1 */
-{
- emit_insn (gen_pic_load_addr_thumb1 (reg, offset_rtx));
- insn = emit_insn (gen_pic_add_dot_plus_four (reg, reg, labelno));
-}
-
+ insn = emit_insn (gen_pic_load_addr_unified (reg, offset_rtx, labelno));
return insn;
}
@@ -5493,7 +5476,7 @@
will_be_in_index_register (const_rtx x)
{
/* arm.md: calculate_pic_address will split this into a register. */
- return GET_CODE (x) == UNSPEC XINT (x, 1) == UNSPEC_PIC_SYM;
+ return GET_CODE (x) == UNSPEC (XINT (x, 1) == UNSPEC_PIC_SYM);
}
/* Return nonzero if X is a valid ARM state address operand. */
@@ -7241,6 +7224,15 @@
*total = COSTS_N_INSNS (4);
return true;
+case UNSPEC:
+ /* We cost this as high as our memory costs to allow this to
+be hoisted from loops. */
+ if (XINT (x, 1) == UNSPEC_PIC_UNIFIED)
+ {
+ *total = COSTS_N_INSNS (2 + ARM_NUM_REGS (mode));
+ }
+ return true;
+
default:
*total = COSTS_N_INSNS (4);
return false;
@@ -9434,7 +9426,8 @@
arm_note_pic_base (rtx *x, void *date ATTRIBUTE_UNUSED)
{
if (GET_CODE (*x) == UNSPEC
- XINT (*x, 1) == UNSPEC_PIC_BASE)
+ (XINT (*x, 1) == UNSPEC_PIC_BASE
+ || XINT (*x, 1) == UNSPEC_PIC_UNIFIED))
return 1;
return 0;
}
Index: gcc/config/arm/arm.md
===
--- gcc/config/arm/arm.md (revision 183725)
+++ gcc/config/arm/arm.md (working copy)
@@ -104,6 +104,7 @@
(UNSPEC_SYMBOL_OFFSET 27) ; The offset of the start of the symbol from
; another symbolic address.
(UNSPEC_MEMORY_BARRIER 28) ; Represent a memory barrier.
+ (UNSPEC_PIC_UNIFIED 29) ; Create a common pic addressing form.
]
)
@@ -5257,6 +5258,30 @@
operands[3] = can_create_pseudo_p () ? gen_reg_rtx (SImode) : operands[0];
)
+;; operand1 is the memory address to go into
+;; pic_load_addr_32bit.
+;; operand2 is the PIC label to be emitted
+;; from pic_add_dot_plus_eight.
+;; We do this to allow hoisting of the entire insn.
+(define_insn_and_split pic_load_addr_unified
+ [(set (match_operand:SI 0 s_register_operand =r,r,l)
+ (unspec:SI [(match_operand:SI 1 mX,mX,mX)
+ (match_operand:SI 2 )]
+ UNSPEC_PIC_UNIFIED))]
+ flag_pic
+ #
+ reload_completed
+ [(set (match_dup 0) (unspec:SI [(match_dup 1)] UNSPEC_PIC_SYM))
+ (set (match_dup 0) (unspec:SI [(match_dup 0) (match_dup 3)
+(match_dup 2)] UNSPEC_PIC_BASE))]
+ operands[3] = TARGET_THUMB ? GEN_INT (4)
Re: [wwwdocs] Add section on diagnostics conventions
On Sun, 29 Jan 2012, Diego Novillo wrote: +licodeinternal_error/code is used for conditions that should not +be triggered by any user input whether valid or invalid and including +invalid asms and LTO binary data (sometimes, as an exception, there is +a call to codeerror/code before further information is printed and +an ICE is triggered)./li + +liAssertion failures should not be triggered by invalid input. +codeinform/code is for informative notes accompanying errors and +warnings. All diagnostics should be full sentences without English +fragments substituted in them, to facilitate translation./li The three sentences in this last list item are actually three independent and unrelated points. I think the first one about assertion failures should be moved up into the previous list item, while the remaining two sentences should each be a list item on its own. -- Joseph S. Myers jos...@codesourcery.com
Re: [wwwdocs] Re: [PATCH] invoke.texi: compile time, run time cleanup
On Sun, 29 Jan 2012, Sandra Loosemore wrote: On 01/29/2012 07:31 AM, Joseph S. Myers wrote: On Sat, 28 Jan 2012, Sandra Loosemore wrote: 2012-01-28 Sandra Loosemoresan...@codesourcery.com gcc/ * doc/invoke.texi: Make usage of compile time and run time/runtime consistent throughout the file. OK. Could you post a patch to codingconventions.html to document the conventions you described in your message? Like this? The table formatting encourages brevity, but I can twiddle it somehow if more detail is necessary. OK, unless Gerald sees any problems with it. -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH][ARM] Improve 64-bit shifts (non-NEON)
On 27/01/12 16:07, Andrew Stubbs wrote:
Hi all,
This patch introduces a new, more efficient set of DImode shift
sequences for values stored in core-registers (as opposed to VFP/NEON
registers).
The new sequences take advantage of knowledge of what the ARM
instructions do with out-of-range shift amounts.
The following are examples or a simple test case, like this one:
long long
f (long long *a, int b)
{
return *a b;
}
In ARM mode, old left-shift vs. the new one:
stmfd sp!, {r4, r5}| ldrdr2, [r0]
rsb r4, r1, #32 | mov ip, r1
ldr r5, [r0, #4] | stmfd sp!, {r4, r5}
subsip, r1, #32 | sub r5, ip, #32
ldr r0, [r0, #0] | rsb r4, ip, #32
mov r3, r5, asl r1 | mov r1, r3, asl ip
orr r3, r3, r0, lsr r4 | mov r0, r2, asl ip
mov r2, r0, asl r1 | orr r1, r1, r2, asl r5
movpl r3, r0, asl ip | orr r1, r1, r2, lsr r4
mov r0, r2 | ldmfd sp!, {r4, r5}
mov r1, r3 | bx lr
ldmfd sp!, {r4, r5}|
bx lr |
In Thumb mode, old left-shift vs. new:
ldr r2, [r0, #0] | ldrdr2, [r0]
ldr r3, [r0, #4] | push{r4, r5, r6}
push{r4, r5, r6} | sub r6, r1, #32
rsb r6, r1, #32 | mov r4, r1
sub r4, r1, #32 | rsb r5, r1, #32
lslsr3, r3, r1 | lslsr6, r2, r6
lsrsr6, r2, r6 | lslsr1, r3, r1
lslsr5, r2, r4 | lsrsr5, r2, r5
orrsr3, r3, r6 | lslsr0, r2, r4
lslsr0, r2, r1 | orrsr1, r1, r6
bicsr1, r5, r4, asr #32 | orrsr1, r1, r5
it cs | pop {r4, r5, r6}
movcs r1, r3 | bx lr
pop {r4, r5, r6} |
bx lr |
Logical right shift is essentially the same sequence as the left shift
above. However, arithmetic right shift requires something slightly
different. Here it is in ARM mode, old vs. new:
stmfd sp!, {r4, r5}| ldrdr2, [r0]
rsb r4, r1, #32 | mov ip, r1
ldr r5, [r0, #0] | stmfd sp!, {r4, r5}
subsip, r1, #32 | rsb r5, ip, #32
ldr r0, [r0, #4] | subsr4, ip, #32
mov r2, r5, lsr r1 | mov r0, r2, lsr ip
orr r2, r2, r0, asl r4 | mov r1, r3, asr ip
mov r3, r0, asr r1 | orr r0, r0, r3, asl r5
movpl r2, r0, asr ip | orrge r0, r0, r3, asr r4
mov r1, r3 | ldmfd sp!, {r4, r5}
mov r0, r2 | bx lr
ldmfd sp!, {r4, r5}|
bx lr |
I won't bore you with the Thumb mode comparison.
The shift-by-constant cases have also been reimplemented, although the
resultant sequences are much the same as before. (Doing this isn't
strictly necessary just yet, but when I post my next patch to do 64-bit
shifts in NEON, this feature will be required by the fall-back
alternatives.)
I've run a regression test on a cross-compiler, and I should have native
test results next week sometime. Also some benchmark results.
Is this OK for stage 1?
What's the impact of this on -Os? At present we fall back to the
libcalls, but I can't immediately see how the new code would do that.
Gut feeling is that shift by a constant is always worth inlining at -Os,
but shift by a register isn't.
R.
Re: [PATCH] Fix PR 51910, -frepo/linker demangling interaction
On 01/30/2012 09:23 AM, Jakub Jelinek wrote: On Sun, Jan 29, 2012 at 05:08:10PM -0700, Sandra Loosemore wrote: Bootstrapped and regression-tested on i636 linux. OK to check in? I think that is terribly expensive fix, for larger projects a single ld invocation can take several minutes. Agreed. What if we always look for .rpo files, and then disable linker demangling if we find them? Jason
[PATCH] Fix PR52028
This fixes PR52028 - we were not properly re-writing virtual SSA form
in loop distribution.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2012-01-30 Richard Guenther rguent...@suse.de
PR tree-optimization/52028
* tree-loop-distribution.c (ldist_gen): Properly update
virtual SSA form.
* gcc.dg/torture/pr52028.c: New testcase.
* gfortran.dg/ldist-pr45199.f: Adjust.
* gcc.dg/tree-ssa/ldist-16.c: Likewise.
* gcc.dg/tree-ssa/ldist-17.c: Likewise.
* gcc.dg/tree-ssa/ldist-pr45948.c: Likewise.
Index: gcc/tree-loop-distribution.c
===
*** gcc/tree-loop-distribution.c(revision 183719)
--- gcc/tree-loop-distribution.c(working copy)
*** ldist_gen (struct loop *loop, struct gra
*** 1143,1149
goto ldist_done;
rewrite_into_loop_closed_ssa (NULL, TODO_update_ssa);
! update_ssa (TODO_update_ssa_only_virtuals | TODO_update_ssa);
ldist_done:
--- 1143,1150
goto ldist_done;
rewrite_into_loop_closed_ssa (NULL, TODO_update_ssa);
! mark_sym_for_renaming (gimple_vop (cfun));
! update_ssa (TODO_update_ssa_only_virtuals);
ldist_done:
Index: gcc/testsuite/gcc.dg/torture/pr52028.c
===
*** gcc/testsuite/gcc.dg/torture/pr52028.c (revision 0)
--- gcc/testsuite/gcc.dg/torture/pr52028.c (revision 0)
***
*** 0
--- 1,83
+ /* { dg-do run } */
+ /* { dg-require-effective-target int32plus } */
+ /* { dg-options -ftree-loop-distribution } */
+
+ #define CAST_LONG unsigned int
+ typedef struct cast_key_st
+ {
+ CAST_LONG data[32];
+ } CAST_KEY;
+ #define CAST_exp(l,A,a,n) \
+ A[n/4]=l; \
+ a[n+3]=(l)0xff; \
+ a[n+2]=(l 8)0xff; \
+ a[n+1]=(l16)0xff; \
+ a[n+0]=(l24)0xff;
+
+ CAST_LONG CAST_S_table[1024];
+
+ #define S4 (CAST_S_table + 000)
+ #define S5 (CAST_S_table + 256)
+ #define S6 (CAST_S_table + 512)
+ #define S7 (CAST_S_table + 768)
+
+ void
+ CAST_set_key (CAST_KEY * key)
+ {
+ CAST_LONG x[16];
+ CAST_LONG z[16];
+ CAST_LONG k[32];
+ CAST_LONG X[4] = {0,0,0,0}, Z[4];
+ CAST_LONG l, *K = k;
+ int i;
+ for (i = 0; i 16; i++)
+ x[i] = 0;
+ for (;;)
+ {
+ l = X[0] ^ S4[x[13]] ^ S5[x[15]] ^ S6[x[12]] ^ S7[x[14]] ^ S6[x[8]];
+ CAST_exp (l, Z, z, 0);
+ CAST_exp (l, Z, z, 4);
+ CAST_exp (l, Z, z, 8);
+ CAST_exp (l, Z, z, 12);
+ K[0] = S4[z[8]] ^ S5[z[9]] ^ S6[z[7]] ^ S7[z[6]] ^ S4[z[2]];
+ K[1] = S4[z[10]] ^ S5[z[11]] ^ S6[z[5]] ^ S7[z[4]] ^ S5[z[6]];
+ K[2] = S4[z[12]] ^ S5[z[13]] ^ S6[z[3]] ^ S7[z[2]] ^ S6[z[9]];
+ K[3] = S4[z[14]] ^ S5[z[15]] ^ S6[z[1]] ^ S7[z[0]] ^ S7[z[12]];
+ K[4] = S4[x[3]] ^ S5[x[2]] ^ S6[x[12]] ^ S7[x[13]] ^ S4[x[8]];
+ K[5] = S4[x[1]] ^ S5[x[0]] ^ S6[x[14]] ^ S7[x[15]] ^ S5[x[13]];
+ K[6] = S4[x[7]] ^ S5[x[6]] ^ S6[x[8]] ^ S7[x[9]] ^ S6[x[3]];
+ K[7] = S4[x[5]] ^ S5[x[4]] ^ S6[x[10]] ^ S7[x[11]] ^ S7[x[7]];
+ K[8] = S4[z[3]] ^ S5[z[2]] ^ S6[z[12]] ^ S7[z[13]] ^ S4[z[9]];
+ K[9] = S4[z[1]] ^ S5[z[0]] ^ S6[z[14]] ^ S7[z[15]] ^ S5[z[12]];
+ K[10] = S4[z[7]] ^ S5[z[6]] ^ S6[z[8]] ^ S7[z[9]] ^ S6[z[2]];
+ K[11] = S4[z[5]] ^ S5[z[4]] ^ S6[z[10]] ^ S7[z[11]] ^ S7[z[6]];
+ l = Z[2] ^ S4[z[5]] ^ S5[z[7]] ^ S6[z[4]] ^ S7[z[6]] ^ S6[z[0]];
+ CAST_exp (l, X, x, 0);
+ K[12] = S4[x[8]] ^ S5[x[9]] ^ S6[x[7]] ^ S7[x[6]] ^ S4[x[3]];
+ K[13] = S4[x[10]] ^ S5[x[11]] ^ S6[x[5]] ^ S7[x[4]] ^ S5[x[7]];
+ K[14] = S4[x[12]] ^ S5[x[13]] ^ S6[x[3]] ^ S7[x[2]] ^ S6[x[8]];
+ K[15] = S4[x[14]] ^ S5[x[15]] ^ S6[x[1]] ^ S7[x[0]] ^ S7[x[13]];
+ if (K != k)
+ break;
+ K += 16;
+ }
+ for (i = 0; i 16; i++)
+ {
+ key-data[i * 2] = k[i];
+ key-data[i * 2 + 1] = ((k[i + 16]) + 16) 0x1f;
+ }
+ }
+
+ int
+ main ()
+ {
+ CAST_KEY ref = { {0x0069B3F8, 0x0013, 0x000AEFF8, 0x0013,
0x004AD0E0, 0x001B, 0x00818F18, 0x0018, 0x008FF000, 0x001B,
0x002D1C00, 0x001B, 0x00EA2800, 0x0010, 0x00C73400, 0x0010,
0x004BF8E0, 0x001B, 0x00B3D718, 0x0018, 0x00B0EBF8, 0x0013,
0x003247F8, 0x0013, 0x00C5BA20, 0x0010, 0x002D1C00, 0x0010,
0x0060822B, 0x0008, 0x0096236B, 0x001B} };
+ CAST_KEY key;
+ unsigned i;
+ for (i = 1; i 1024; i++)
+ CAST_S_table[i] = (CAST_S_table[i-1] * 7 + 3) 0xFF;
+ CAST_set_key (key);
+ if (__builtin_memcmp(ref, key, sizeof(ref)))
+ __builtin_abort();
+ return 0;
+ }
Index: gcc/testsuite/gfortran.dg/ldist-pr45199.f
===
*** gcc/testsuite/gfortran.dg/ldist-pr45199.f (revision 183719)
--- gcc/testsuite/gfortran.dg/ldist-pr45199.f (working copy)
***
*** 23,27
! GCC should apply memset
Re: [PATCH] Fix PR 51910, -frepo/linker demangling interaction
On Mon, Jan 30, 2012 at 10:42:13AM -0500, Jason Merrill wrote: On 01/30/2012 09:23 AM, Jakub Jelinek wrote: On Sun, Jan 29, 2012 at 05:08:10PM -0700, Sandra Loosemore wrote: Bootstrapped and regression-tested on i636 linux. OK to check in? I think that is terribly expensive fix, for larger projects a single ld invocation can take several minutes. Agreed. What if we always look for .rpo files, and then disable linker demangling if we find them? The *.rpo discovery can be many thousands of syscalls too for larger links and I think -frepo is quite rarely used. Can't tlink just take into account that sometimes different symbols mangle the same, and handle those as a group (i.e. if the linker output requests S::~S(), and *.rpo files contain several _ZN1SD[0-9]Ev symbols, mark or tweak them all)? Jakub
Re: RFA: fix PR 51649
Tom == Tom Tromey tro...@redhat.com writes: Tom Unless you have other tests to suggest, I am going to say that it has Tom been sufficiently tested and check it in on Friday. Jakub said on irc that he thought I had done sufficient testing. So, I am checking this patch in now. thanks, Tom
Re: [PATCH] Fix PR 51910, -frepo/linker demangling interaction
On 01/30/2012 07:23 AM, Jakub Jelinek wrote: On Sun, Jan 29, 2012 at 05:08:10PM -0700, Sandra Loosemore wrote: Bootstrapped and regression-tested on i636 linux. OK to check in? I think that is terribly expensive fix, for larger projects a single ld invocation can take several minutes. What exactly are advantages of using the linker demangling as opposed to collect2 doing the demangling as before? Does it really justify penalizing -frepo that much? collect2 doesn't know how to demangle linker map files, and our experience has been that users are more likely to want a map file than to use -frepo. -Sandra
Re: [libitm] Link eh-1.exe with -shared-libgcc on Solaris (PR libitm/51822)
Richard Henderson r...@redhat.com writes:
On 01/25/2012 12:03 AM, Rainer Orth wrote:
Er.. how did we get two copies?
The link line boils down to
ld -o eh-1.exe crt1.o crti.o crtbegin.o eh-1.o -litm -lstdc++ -lm -lgcc
-lgcc_eh -lc -lgcc -lgcc_eh crtend.o crtn.o
The eh-1.o reference to _Unwind_Resume drags in one copy of the unwinder
from libgcc_eh.a, while libstdc++.so is linked against libgcc_s.so.1,
providing another copy.
So... are we linking with the gcc binary, not the g++ binary?
Because I thought -shared-libgcc is the default for C++.
If this goes too far down a rat-hole, your original patch is ok.
The compiler used is currently set in libitm.exp (libitm_init) without
considering the language used. Changing this seems too risky for
stage4. I think we can get away with the following patch instead, which
hardcodes -shared-libgcc for C++. I think it is safe even with
--disable-shared since -shared-libgcc is simply ignored AFAICS, and is
already used unconditionally in libffi.special/special.exp.
Tested on i386-pc-solaris2.11.
Ok for mainline?
Rainer
2012-01-28 Rainer Orth r...@cebitec.uni-bielefeld.de
PR libstdc++/51296
* testsuite/libitm.c++/c++.exp (lang_link_flags): Add
-shared-libgcc.
Correct libgomp references.
# HG changeset patch
# Parent 707821cb5b73761684848cdd143b741881b067ce
Link eh-1.exe with -shared-libgcc on Solaris (PR libitm/51822)
diff --git a/libitm/testsuite/libitm.c++/c++.exp b/libitm/testsuite/libitm.c++/c++.exp
--- a/libitm/testsuite/libitm.c++/c++.exp
+++ b/libitm/testsuite/libitm.c++/c++.exp
@@ -1,3 +1,5 @@
+# Copyright (C) 2011, 2012 Free Software Foundation, Inc.
+#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
@@ -17,14 +19,16 @@ load_lib libitm-dg.exp
global shlib_ext
set shlib_ext [get_shlib_extension]
-set lang_link_flags -lstdc++
+# The C++ tests should be linked with g++, which defaults to -shared-libgcc.
+# Doing that is currently too intrusive, so hardcode here.
+set lang_link_flags -shared-libgcc -lstdc++
set lang_test_file_found 0
set lang_library_path ../libstdc++-v3/src/.libs
# Initialize dg.
dg-init
-set blddir [lookfor_file [get_multilibs] libgomp]
+set blddir [lookfor_file [get_multilibs] libitm]
if { $blddir != } {
@@ -41,7 +45,7 @@ if { $blddir != } {
}
} elseif { [info exists GXX_UNDER_TEST] } {
set lang_test_file_found 1
-# Needs to exist for libgomp.exp.
+# Needs to exist for libitm.exp.
set lang_test_file
} else {
puts GXX_UNDER_TEST not defined, will not execute c++ tests
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [SPARC] Fix PR target/51920
From: Eric Botcazou ebotca...@adacore.com Date: Mon, 30 Jan 2012 13:41:28 +0100 I think it's the long-standing issue with word-mode paradoxical subregs of FP regs in 64-bit mode, which is present on both PA and SPARC. We don't have any real solution as of this writing, only kludges, so the attached patch makes it so that vector_init_fpmerge doesn't create pseudos with long live ranges, to lower the pressure on the register allocator. Tested on SPARC/Solaris, applied on the mainline. Thanks for fixing this Eric.
Re: [PATCH] Fix up --enable-initfini-array autodetection in configure (PR bootstrap/50237)
Jakub Jelinek ja...@redhat.com writes:
The following patch attempts to perform a separate linker check
(grepping objdump of a linked binary) and checks so far glibc version
which is known to support .init_array properly. Perhaps other
C libraries could be added there too (does e.g. Solaris support .init_array
properly, or FreeBSD, other OSes?).
As described in the PR, Solaris ld.so.1 does support
.init_array/.fini_array since an early Solaris 8 patch.
We can (and need to) use the Sun ld version number to check for a
matching ld.so.1 since both are updated in lockstep. To support that, I
must check ld -V output in the native case even if a different linker is
configured.
The following patch has been bootstrapped without regressions on
i386-pc-solaris2.11 with Sun as/ld, gas/Sun ld, gas/gld, where only the
last combination fully supports .init_array/.fini_array due to the
requirement to merge .[cd]tors.* and .{init,fini}_array.* sections which
only gld does so far. I've run H.J.'s original test program on Solaris
8 to 11 and it works on Solaris/x86. The new test doesn't work on
Solaris/SPARC even with gld, still need to investigate why.
Ok for mainline?
Rainer
2012-01-20 Rainer Orth r...@cebitec.uni-bielefeld.de
PR target/50166
* configure.ac (sun_ld_vers_major, sun_ld_vers_minor): Set on
native *-*-solaris2*.
* acinclude.m4 (gcc_AC_INITFINI_ARRAY): Define _start.
Remove -e 0 from $gcc_cv_ld invocation.
Only use __GLIBC_PREREQ if defined.
Enable on Solaris since Solaris 8 patch.
* configure: Regenerate.
# HG changeset patch
# Parent 94f7fcd05ab2cbde19449f1a0fe7151dc01a8208
Enable initfini array support on Solaris
diff --git a/gcc/acinclude.m4 b/gcc/acinclude.m4
--- a/gcc/acinclude.m4
+++ b/gcc/acinclude.m4
@@ -1,4 +1,5 @@
-dnl Copyright (C) 2005, 2006, 2007, 2008, 2011 Free Software Foundation, Inc.
+dnl Copyright (C) 2005, 2006, 2007, 2008, 2011, 2012
+dnl Free Software Foundation, Inc.
dnl
dnl This file is part of GCC.
dnl
@@ -427,9 +428,11 @@ int (*fp) (void) __attribute__ ((section
.balign 4
.byte 'H', 'H', 'H', 'H'
.text
+.globl _start
+_start:
EOF
if $gcc_cv_as -o conftest.o conftest.s /dev/null 21 \
- $gcc_cv_ld -e 0 -o conftest conftest.o /dev/null 21 \
+ $gcc_cv_ld -o conftest conftest.o /dev/null 21 \
$gcc_cv_objdump -s -j .init_array conftest \
| grep /dev/null 21 \
$gcc_cv_objdump -s -j .fini_array conftest \
@@ -442,14 +445,38 @@ changequote([,])dnl
fi
AC_PREPROC_IFELSE([AC_LANG_SOURCE([
#ifndef __ELF__
-#error Not an ELF OS
+# error Not an ELF OS
#endif
#include stdlib.h
-#if defined __GLIBC_PREREQ __GLIBC_PREREQ (2, 4)
+#if defined __GLIBC_PREREQ
+# if __GLIBC_PREREQ (2, 4)
+# else
+# error GLIBC 2.4 required
+# endif
#else
-#error The C library not known to support .init_array/.fini_array
+# if defined __sun__ defined __svr4__
+ /* Solaris ld.so.1 supports .init_array/.fini_array since Solaris 8. */
+# else
+# error The C library not known to support .init_array/.fini_array
+# endif
#endif
-])],, [gcc_cv_initfini_array=no]);;
+])],[
+case ${target} in
+ *-*-solaris2.8*)
+ # .init_array/.fini_array support was introduced in Solaris 8
+ # patches 109147-08 (sparc) and 109148-08 (x86). Since ld.so.1 and
+ # ld are guaranteed to be updated in lockstep, we can check ld -V
+ # instead. Unfortunately, proper ld version numbers were only
+ # introduced in rev. -14, so we check for that.
+ if test $sun_ld_vers_minor -lt 272; then
+ gcc_cv_initfini_array=no
+ fi
+ ;;
+ *-*-solaris2.9* | *-*-solaris2.1[[0-9]]*)
+# .init_array/.fini_array support is present since Solaris 9 FCS.
+;;
+esac
+], [gcc_cv_initfini_array=no]);;
esac
else
AC_MSG_CHECKING(cross compile... guessing)
diff --git a/gcc/configure.ac b/gcc/configure.ac
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -2270,6 +2270,25 @@ if test x$enable_gnu_indirect_function =
fi
changequote(,)dnl
+if test x${build} = x${target} test x${build} = x${host}; then
+ case ${target} in
+*-*-solaris2*)
+ # ld.so.1 and ld are guaranteed to be updated in lockstep, so check
+ # ld version number for use in ld.so.1 feature checks even if a
+ # different linker is configured.
+ #
+ # See below for the version number formats.
+ sun_ld_ver=`/usr/ccs/bin/ld -V 21`
+ if echo $sun_ld_ver | grep 'Solaris Link Editors' /dev/null; then
+ sun_ld_vers=`echo $sun_ld_ver | sed -n \
+ -e 's,^.*: 5\.[0-9][0-9]*-\([0-9]\.[0-9][0-9]*\).*$,\1,p'`
+ sun_ld_vers_major=`expr $sun_ld_vers : '\([0-9]*\)'`
+ sun_ld_vers_minor=`expr $sun_ld_vers : '[0-9]*\.\([0-9]*\)'`
+ fi
+ ;;
+ esac
+fi
+
if test $in_tree_ld != yes ; then
ld_ver=`$gcc_cv_ld --version 2/dev/null | sed 1q`
if echo $ld_ver | grep GNU /dev/null; then
@@ -2305,6 +2324,9 @@ if test $in_tree_ld != yes ; then
#
# ld: Software
Re: [v3] Update Solaris baselines for GCC 4.7
Jonathan Wakely jwakely@gmail.com writes: The change is probably pr 50196 (Sent offlist because the android gmail app refuses to send plain text mails) Right. I think about disabling _GLIBCXX_HAS_GTHREADS on Solaris 8 and 9 per default, with the option of enabling it knowing that it breaks symbol versioning. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [Patch] PR51374: combine.c and volatile correctness
Richard Sandiford wrote:
Georg-Johann Lay a...@gjlay.de writes:
This patch fixes PR51374 by more strictly updating mem_last_set.
Sloppy handling of mem_last_set can lead to error in volatile correctness
because combine then is allowed to drag one volatile access over an other
volatile thing (volatile access, asm volatile, unspec_volatile...).
As explained in the source comment, any volatile might change memory, even a
volatile read.
This looks too broad to me. Volatile MEMs don't usually alias
non-volatile ones (so for example, reads from volatile memory shouldn't
affect reads from non-volatile memory).
The patch tried to fix the issue. If there is less invasive solutions, that's
always preferred, of course.
What do you think about instead changing:
/* If there are any volatile insns between INSN and I3, reject, because
they might affect machine state. */
for (p = NEXT_INSN (insn); p != i3; p = NEXT_INSN (p))
if (INSN_P (p) p != succ p != succ2 volatile_insn_p (PATTERN
(p)))
return 0;
to:
/* If INSN contains volatile references (specifically volatile MEMs),
we cannot combine across any other volatile references.
Even if INSN doesn't contain volatile references, any intervening
volatile insn might affect machine state. */
pred = volatile_refs_p (insn) ? volatile_refs_p : volatile_insn_p;
for (p = NEXT_INSN (insn); p != i3; p = NEXT_INSN (p))
if (NONDEBUG_INSN_P (p) p != succ p != succ2 pred (PATTERN (p)))
return 0;
This would still allow a volatile_refs_p to cross a volatile_insn_p?
And some lines above there is this:
/* If INSN contains anything volatile, or is an `asm' (whether volatile
or not), reject, unless nothing volatile comes between it and I3 */
if (GET_CODE (src) == ASM_OPERANDS || volatile_refs_p (src))
{
/* Make sure neither succ nor succ2 contains a volatile reference. */
if (succ2 != 0 volatile_refs_p (PATTERN (succ2)))
return 0;
if (succ != 0 volatile_refs_p (PATTERN (succ)))
return 0;
/* We'll check insns between INSN and I3 below. */
}
Would our change (whatever it will look like) make that code superfluous?
As you say in the PR notes, we've already handled volatile_insn_p (insn)
by this stage, so the new loop is handling:
volatile_refs_p (insn) !volatile_insn_p (insn)
There is this part of an if-clause in can_combine_p:
/* Make sure that the value that is to be substituted for the register
does not use any registers whose values alter in between. However,
If the insns are adjacent, a use can't cross a set even though we
think it might (this can happen for a sequence of insns each setting
the same destination; last_set of that register might point to
a NOTE). If INSN has a REG_EQUIV note, the register is always
equivalent to the memory so the substitution is valid even if there
are intervening stores. Also, don't move a volatile asm or
UNSPEC_VOLATILE across any other insns. */
|| (! all_adjacent
(((!MEM_P (src)
|| ! find_reg_note (insn, REG_EQUIV, src))
use_crosses_set_p (src, DF_INSN_LUID (insn)))
|| (GET_CODE (src) == ASM_OPERANDS MEM_VOLATILE_P (src))
|| GET_CODE (src) == UNSPEC_VOLATILE))
so it's not a verbatim volatile_insn_p. Maybe it's for historical reason or for
some subtle differences not explained; only someone familiar with combine will
know... perhaps performance issue.
Moreover, writes of the shape (set (zero_extract (mem ... update
mem_last_set.
Good catch. I think we should use note_stores for added safety though,
rather than call zero_extract out as a special case. (I realise the
function already handles subregs, but still.)
record_dead_and_set_regs_1 is called through note_stores so that (set
(zero_extract (mem)) is handled already and thus no change to
record_dead_and_set_regs_1 is needed, right?
Attached you find a new, tentative patch. It resolves the issue in my small
test program.
However, I think someone with more insight into combine should take over the
patch.
Johann
PR rtl-optimization/51374
* combine.c (can_combine_p): Don't allow volatile_refs_p insns
to cross other volatile_refs_p insns.
Index: combine.c
===
--- combine.c (revision 183695)
+++ combine.c (working copy)
@@ -1947,12 +1947,21 @@ can_combine_p (rtx insn, rtx i3, rtx pre
REG_P (dest) REGNO (dest) FIRST_PSEUDO_REGISTER)
return 0;
- /* If there are any volatile insns between INSN and I3, reject, because
- they might affect machine state. */
+ /* If INSN contains volatile references (specifically volatile MEMs),
+ we cannot combine across any other volatile references.
+ Even if INSN doesn't contain volatile references, any
Re: [PATCH] Fix up --enable-initfini-array autodetection in configure (PR bootstrap/50237)
Jakub Jelinek ja...@redhat.com writes:
The following patch attempts to perform a separate linker check
(grepping objdump of a linked binary) and checks so far glibc version
which is known to support .init_array properly. Perhaps other
C libraries could be added there too (does e.g. Solaris support .init_array
properly, or FreeBSD, other OSes?).
As described in the PR, Solaris ld.so.1 does support
.init_array/.fini_array since an early Solaris 8 patch.
We can (and need to) use the Sun ld version number to check for a
matching ld.so.1 since both are updated in lockstep. To support that, I
must check ld -V output in the native case even if a different linker is
configured.
The following patch has been bootstrapped without regressions on
i386-pc-solaris2.11 with Sun as/ld, gas/Sun ld, gas/gld, where only the
last combination fully supports .init_array/.fini_array due to the
requirement to merge .[cd]tors.* and .{init,fini}_array.* sections which
only gld does so far. I've run H.J.'s original test program on Solaris
8 to 11 and it works on Solaris/x86. The new test doesn't work on
Solaris/SPARC even with gld, still need to investigate why.
Ok for mainline?
Rainer
2012-01-20 Rainer Orth r...@cebitec.uni-bielefeld.de
PR target/50166
* configure.ac (sun_ld_vers_major, sun_ld_vers_minor): Set on
native *-*-solaris2*.
* acinclude.m4 (gcc_AC_INITFINI_ARRAY): Define _start.
Remove -e 0 from $gcc_cv_ld invocation.
Only use __GLIBC_PREREQ if defined.
Enable on Solaris since Solaris 8 patch.
* configure: Regenerate.
sol2-initfini-array.patch
# HG changeset patch
# Parent 94f7fcd05ab2cbde19449f1a0fe7151dc01a8208
Enable initfini array support on Solaris
diff --git a/gcc/acinclude.m4 b/gcc/acinclude.m4
--- a/gcc/acinclude.m4
+++ b/gcc/acinclude.m4
@@ -1,4 +1,5 @@
-dnl Copyright (C) 2005, 2006, 2007, 2008, 2011 Free Software Foundation, Inc.
+dnl Copyright (C) 2005, 2006, 2007, 2008, 2011, 2012
+dnl Free Software Foundation, Inc.
dnl
dnl This file is part of GCC.
dnl
@@ -427,9 +428,11 @@ int (*fp) (void) __attribute__ ((section
.balign 4
.byte 'H', 'H', 'H', 'H'
.text
+.globl _start
+_start:
EOF
if $gcc_cv_as -o conftest.o conftest.s /dev/null 21 \
- $gcc_cv_ld -e 0 -o conftest conftest.o /dev/null 21 \
+ $gcc_cv_ld -o conftest conftest.o /dev/null 21 \
$gcc_cv_objdump -s -j .init_array conftest \
| grep /dev/null 21 \
$gcc_cv_objdump -s -j .fini_array conftest \
@@ -442,14 +445,38 @@ changequote([,])dnl
fi
AC_PREPROC_IFELSE([AC_LANG_SOURCE([
#ifndef __ELF__
-#error Not an ELF OS
+# error Not an ELF OS
#endif
#include stdlib.h
-#if defined __GLIBC_PREREQ __GLIBC_PREREQ (2, 4)
+#if defined __GLIBC_PREREQ
+# if __GLIBC_PREREQ (2, 4)
+# else
+# error GLIBC 2.4 required
+# endif
#else
-#error The C library not known to support .init_array/.fini_array
+# if defined __sun__ defined __svr4__
+ /* Solaris ld.so.1 supports .init_array/.fini_array since Solaris 8. */
+# else
+# error The C library not known to support .init_array/.fini_array
+# endif
#endif
-])],, [gcc_cv_initfini_array=no]);;
+])],[
+case ${target} in
+ *-*-solaris2.8*)
+ # .init_array/.fini_array support was introduced in Solaris 8
+ # patches 109147-08 (sparc) and 109148-08 (x86). Since ld.so.1 and
+ # ld are guaranteed to be updated in lockstep, we can check ld -V
+ # instead. Unfortunately, proper ld version numbers were only
+ # introduced in rev. -14, so we check for that.
+ if test $sun_ld_vers_minor -lt 272; then
+ gcc_cv_initfini_array=no
+ fi
+ ;;
+ *-*-solaris2.9* | *-*-solaris2.1[[0-9]]*)
+# .init_array/.fini_array support is present since Solaris 9 FCS.
+;;
+esac
+], [gcc_cv_initfini_array=no]);;
esac
else
AC_MSG_CHECKING(cross compile... guessing)
diff --git a/gcc/configure.ac b/gcc/configure.ac
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -2270,6 +2270,25 @@ if test x$enable_gnu_indirect_function =
fi
changequote(,)dnl
+if test x${build} = x${target} test x${build} = x${host}; then
+ case ${target} in
+*-*-solaris2*)
+ # ld.so.1 and ld are guaranteed to be updated in lockstep, so check
+ # ld version number for use in ld.so.1 feature checks even if a
+ # different linker is configured.
+ #
+ # See below for the version number formats.
+ sun_ld_ver=`/usr/ccs/bin/ld -V 21`
+ if echo $sun_ld_ver | grep 'Solaris Link Editors' /dev/null; then
+ sun_ld_vers=`echo $sun_ld_ver | sed -n \
+ -e 's,^.*: 5\.[0-9][0-9]*-\([0-9]\.[0-9][0-9]*\).*$,\1,p'`
+ sun_ld_vers_major=`expr $sun_ld_vers : '\([0-9]*\)'`
+ sun_ld_vers_minor=`expr $sun_ld_vers : '[0-9]*\.\([0-9]*\)'`
+ fi
+ ;;
+ esac
+fi
This must be a separate macro in acinclude.m4 that is
Re: [PATCH] Fix up --enable-initfini-array autodetection in configure (PR bootstrap/50237)
Paolo Bonzini bonz...@gnu.org writes:
changequote(,)dnl
+if test x${build} = x${target} test x${build} = x${host}; then
+ case ${target} in
+*-*-solaris2*)
+ # ld.so.1 and ld are guaranteed to be updated in lockstep, so check
+ # ld version number for use in ld.so.1 feature checks even if a
+ # different linker is configured.
+ #
+ # See below for the version number formats.
+ sun_ld_ver=`/usr/ccs/bin/ld -V 21`
+ if echo $sun_ld_ver | grep 'Solaris Link Editors' /dev/null; then
+sun_ld_vers=`echo $sun_ld_ver | sed -n \
+ -e 's,^.*: 5\.[0-9][0-9]*-\([0-9]\.[0-9][0-9]*\).*$,\1,p'`
+sun_ld_vers_major=`expr $sun_ld_vers : '\([0-9]*\)'`
+sun_ld_vers_minor=`expr $sun_ld_vers : '[0-9]*\.\([0-9]*\)'`
+ fi
+ ;;
+ esac
+fi
This must be a separate macro in acinclude.m4 that is AC_REQUIREd from
gcc_AC_INITFINI_ARRAY.
Ok, will do.
Can you test Linux too? The change of -e0 looks good, but I'd rather check
on the actual system.
I can test on x86_64-unknown-linux-gnu, just not on my laptop at home.
Actually, Jakub suggested the change in the PR since Sun ld complains
about -e 0.
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH] Fix up --enable-initfini-array autodetection in configure (PR bootstrap/50237)
On 01/30/2012 06:00 PM, Rainer Orth wrote: Can you test Linux too? The change of -e0 looks good, but I'd rather check on the actual system. I can test on x86_64-unknown-linux-gnu, just not on my laptop at home. Note that you only need to test ./configure, not bootstrap/regtest. Actually, Jakub suggested the change in the PR since Sun ld complains about -e 0. Good to know. :) Paolo
Re: [v3] Update Solaris baselines for GCC 4.7
Rainer Orth r...@cebitec.uni-bielefeld.de writes: Paolo Carlini paolo.carl...@oracle.com writes: +FUNC:_ZNSt19istreambuf_iteratorIcSt11char_traitsIcEEppEv@@GLIBCXX_3.4.5 +FUNC:_ZNSt19istreambuf_iteratorIwSt11char_traitsIwEEppEv@@GLIBCXX_3.4.5 I don't think this is a new issue, I see it in 4.6 branch and even in 4.5 branch. At some point we had a problem which Jakub patched (thus the *XX variants), the actual story is longish but is not new, I'm not sure you are interested in thegory details. Perhaps you have a pointer? I can search, but really the issue is very, very old and we already released *many* GCCs affected. For the case at hand, I doubt that: those are additions between the gcc 4.6.0 and 4.7.0 Solaris baselines. They have not been present in Solaris libstdc++.so on 4.6. I've actually done a reghunt, which revealed that those symbols (in src/c++98/locale-inst.o, src/c++98/wlocale-inst.o) were introduced by this patch: 2011-07-18 Martin Jambor mjam...@suse.cz * ipa-prop.h: Include alloc-pool.h, all sorts of updates to general comments. (ipcp_values_pool): Declare. (ipcp_sources_pool): Likewise. I.e. there are *no* libstdc++ or C++ changes involved at all. IMO this is a bug, plain and simple. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH] invoke.texi: compile time, run time cleanup
On 1/28/2012 12:05 PM, Sandra Loosemore wrote: I'm specifically asking for review of this patch by one of the docs maintainers before checking it in, since it seems not everyone agrees that these copyediting patches qualify as obvious. In this particular chunk, I had to make some judgment calls, too. We usually use compile time, link time, and run time to refer to the times at which the program is compiled, linked, and run, respectively. So, the normal English rules about hyphenation apply here; it's correct to say at run time, but run-time behavior, for example. To confuse matters, though, compile time can also be used as a noun meaning the amount of time it takes to compile. I saw that in some places invoke.texi was already using compilation time for this meaning instead and decided it made sense to apply that terminology uniformly. Likewise execution time was already being used in some places for the amount of time it takes the program to run, so I made that usage consistent. Confusingly, there were also a couple of places referring to run time of a compilation pass; I reworded those to refer to compilation time in that pass. Finally, runtime (without a space or hyphen) is commonly used as a noun to refer collectively to the startup code, libraries, trap handlers, bootloader or operating system, etc that are present on the target at run time. In the Objective-C section of this document there's a lot of existing discussion of the GNU runtime versus the NeXT runtime, for example, and other option descriptions refer to the simulator runtime. Google shows a lot of variation on usage here (and Wikipedia, in particular, is quite confused on this topic), but to me it seems silly to make the adjective form of runtime hyphenated when it's already a single word as a noun. So, I decided to go consistently with runtime support, runtime library, etc when discussing what the runtime includes. OK to check in? -Sandra I am still inclined to go with runtime everywhere, to ease searching and avoid everyone having to understand the above set of rules, which seem over-delicate to me (admitting all three forms, with tricky rules as to which of the three is used, will ensure that people make constant mistakes). In particular runtime support run-time behavior seems to tricky a distinction. I am not clear on what the exact rule that you have in mind here is, and I am absolutely sure that it will not be practical to expect the community to absorb and follow this rule. The adjective vs noun rule is one thing, but having a rule that delicately distinguishes two forms of adjectival use is a step too far for me. At the very least, you need to state the rule you have invented here, rather than just give a few usage based examples. I also find the disctinction between compile time and compilation time tricky to expect to be used consistently, although it is a useful distinction if a) enforced carefully b) documented in a glossary whereas the distinction between the two adjectival forms runtime and run-time seems to have no technical value.
Re: [libitm] Link eh-1.exe with -shared-libgcc on Solaris (PR libitm/51822)
On Mon, Jan 30, 2012 at 05:40:21PM +0100, Rainer Orth wrote:
Richard Henderson r...@redhat.com writes:
On 01/25/2012 12:03 AM, Rainer Orth wrote:
Er.. how did we get two copies?
The link line boils down to
ld -o eh-1.exe crt1.o crti.o crtbegin.o eh-1.o -litm -lstdc++ -lm -lgcc
-lgcc_eh -lc -lgcc -lgcc_eh crtend.o crtn.o
The eh-1.o reference to _Unwind_Resume drags in one copy of the unwinder
from libgcc_eh.a, while libstdc++.so is linked against libgcc_s.so.1,
providing another copy.
So... are we linking with the gcc binary, not the g++ binary?
Because I thought -shared-libgcc is the default for C++.
If this goes too far down a rat-hole, your original patch is ok.
The compiler used is currently set in libitm.exp (libitm_init) without
considering the language used. Changing this seems too risky for
stage4. I think we can get away with the following patch instead, which
hardcodes -shared-libgcc for C++. I think it is safe even with
--disable-shared since -shared-libgcc is simply ignored AFAICS, and is
already used unconditionally in libffi.special/special.exp.
Tested on i386-pc-solaris2.11.
FYI, this fix has no impact on the eh-1.C execution failures seen at -m32/-m64
on x86_64 darwin10/11
when built with Xcode 4.2(.1).
Ok for mainline?
Rainer
2012-01-28 Rainer Orth r...@cebitec.uni-bielefeld.de
PR libstdc++/51296
* testsuite/libitm.c++/c++.exp (lang_link_flags): Add
-shared-libgcc.
Correct libgomp references.
# HG changeset patch
# Parent 707821cb5b73761684848cdd143b741881b067ce
Link eh-1.exe with -shared-libgcc on Solaris (PR libitm/51822)
diff --git a/libitm/testsuite/libitm.c++/c++.exp
b/libitm/testsuite/libitm.c++/c++.exp
--- a/libitm/testsuite/libitm.c++/c++.exp
+++ b/libitm/testsuite/libitm.c++/c++.exp
@@ -1,3 +1,5 @@
+# Copyright (C) 2011, 2012 Free Software Foundation, Inc.
+#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
@@ -17,14 +19,16 @@ load_lib libitm-dg.exp
global shlib_ext
set shlib_ext [get_shlib_extension]
-set lang_link_flags -lstdc++
+# The C++ tests should be linked with g++, which defaults to -shared-libgcc.
+# Doing that is currently too intrusive, so hardcode here.
+set lang_link_flags -shared-libgcc -lstdc++
set lang_test_file_found 0
set lang_library_path ../libstdc++-v3/src/.libs
# Initialize dg.
dg-init
-set blddir [lookfor_file [get_multilibs] libgomp]
+set blddir [lookfor_file [get_multilibs] libitm]
if { $blddir != } {
@@ -41,7 +45,7 @@ if { $blddir != } {
}
} elseif { [info exists GXX_UNDER_TEST] } {
set lang_test_file_found 1
-# Needs to exist for libgomp.exp.
+# Needs to exist for libitm.exp.
set lang_test_file
} else {
puts GXX_UNDER_TEST not defined, will not execute c++ tests
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [committed] invoke.texi: fix hyphenation of floating point and related terms
On 1/28/2012 11:33 AM, Sandra Loosemore wrote: Sometimes the best idea is to just drop the hyphen completetly. It seems for example (try google) that runtime is becoming much more accepted than run-time or run time. Coincidentally, runtime is the subject of my next patch chunk, and I had to make some judgment calls there. I'll post it for review by one of the docs maintainers instead of just checking it in. I am in favor of dropping the hyphen in all cases for runtime, given the clear lead from Microsoft and Sun. CMOS really is not the right place to look for appropriate contemporary technical usage. If you google around, you will find that at this stage runtime is getting to be used widely, and the most notable uses: Java Runtime Environment (SUn/Oracle) Runtime for all Microsoft components Are clearly influential As for floating-point, it just makes sense to be consistent instead of following the mandated CMOS inconsistent style, because it eases searches. Remember CMOS was written when people had never heard of computer searching, but the widespread use of searches argue for a more consistent style. I don't see that hyphenating floating-point as a noun can ever be confusing. Yes, it will jar some people who have been taught a particular grammar rule, just as it jars people to hear Shakespeare using between you and I :-) But I think it is reasonable to take a more pragmatic approach in the context of software documentation. Another point is that if you choose a simple consistent rule, rather than a more complex inconsistent rule, it is much easier to get people to follow it, and much easier to correct it when they fail to do so. Otherwise, if you have a more complex rule, people will keep getting it wrong, resulting in noise patches fixing the problems (I use noise here in the sense that such patches have no technically relevant content, but nevertheless have to be taken into account in keeping sources up to date). Anyway, interesting to see what others think! :-)
Re: [libitm] Link eh-1.exe with -shared-libgcc on Solaris (PR libitm/51822)
On 01/30/2012 12:15 PM, Jack Howarth wrote: On Mon, Jan 30, 2012 at 05:40:21PM +0100, Rainer Orth wrote: Richard Hendersonr...@redhat.com writes: On 01/25/2012 12:03 AM, Rainer Orth wrote: Er.. how did we get two copies? The link line boils down to ld -o eh-1.exe crt1.o crti.o crtbegin.o eh-1.o -litm -lstdc++ -lm -lgcc -lgcc_eh -lc -lgcc -lgcc_eh crtend.o crtn.o The eh-1.o reference to _Unwind_Resume drags in one copy of the unwinder from libgcc_eh.a, while libstdc++.so is linked against libgcc_s.so.1, providing another copy. So... are we linking with the gcc binary, not the g++ binary? Because I thought -shared-libgcc is the default for C++. If this goes too far down a rat-hole, your original patch is ok. The compiler used is currently set in libitm.exp (libitm_init) without considering the language used. Changing this seems too risky for stage4. I think we can get away with the following patch instead, which hardcodes -shared-libgcc for C++. I think it is safe even with --disable-shared since -shared-libgcc is simply ignored AFAICS, and is already used unconditionally in libffi.special/special.exp. Tested on i386-pc-solaris2.11. FYI, this fix has no impact on the eh-1.C execution failures seen at -m32/-m64 on x86_64 darwin10/11 when built with Xcode 4.2(.1). Problem was discussed here and not same problem as above: http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00329.html http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00285.html -- Patrick.
Re: [libitm] Link eh-1.exe with -shared-libgcc on Solaris (PR libitm/51822)
Jack Howarth howa...@bromo.med.uc.edu writes: FYI, this fix has no impact on the eh-1.C execution failures seen at -m32/-m64 on x86_64 darwin10/11 when built with Xcode 4.2(.1). Then you need to do the analysis why exactly the failure occurs in this case. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
[RFA/ARM] Fix thumb2_mov_notscc pattern in thumb2.md
Hi, This patch fixes the thumb2_mov_notscc pattern in the same way as the ARM state mov_notscc pattern was fixed earlier in January. This was highlighted by the gcc.target/arm/20120111-1.c testcase. OK? Thanks, Matt gcc/ChangeLog: 2012-01-30 Matthew Gretton-Dann matthew.gretton-d...@arm.com config/arm/thumb2.md (thumb2_mov_notscc): Use MVN for true condition. -- Matthew Gretton-Dann Principal Engineer, PD Software, ARM Ltd.diff --git a/gcc/config/arm/thumb2.md b/gcc/config/arm/thumb2.md index 05585da..ad05feb 100644 --- a/gcc/config/arm/thumb2.md +++ b/gcc/config/arm/thumb2.md @@ -259,7 +259,7 @@ (not:SI (match_operator:SI 1 arm_comparison_operator [(match_operand 2 cc_register ) (const_int 0)])))] TARGET_THUMB2 - ite\\t%D1\;mov%D1\\t%0, #0\;mvn%d1\\t%0, #1 + ite\\t%D1\;mvn%D1\\t%0, #0\;mvn%d1\\t%0, #1 [(set_attr conds use) (set_attr length 10)] )
Re: [RFA/ARM] Fix thumb2_mov_notscc pattern in thumb2.md
On 30/01/12 17:27, Matthew Gretton-Dann wrote: Hi, This patch fixes the thumb2_mov_notscc pattern in the same way as the ARM state mov_notscc pattern was fixed earlier in January. This was highlighted by the gcc.target/arm/20120111-1.c testcase. OK? Thanks, Matt gcc/ChangeLog: 2012-01-30 Matthew Gretton-Dann matthew.gretton-d...@arm.com config/arm/thumb2.md (thumb2_mov_notscc): Use MVN for true condition. OK, and for backports. R.
Re: [v3] Update Solaris baselines for GCC 4.7
On 01/30/2012 06:11 PM, Rainer Orth wrote: I.e. there are *no* libstdc++ or C++ changes involved at all. IMO this is a bug, plain and simple. Just to avoid all the pointless discussions we had last time: *on Solaris*. Because if you look at gnu.ver it's obvious that those symbols *on Linux* were normally exported in 3.4.5. Nothing new. Paolo.
Re: [v3] Update Solaris baselines for GCC 4.7
Paolo Carlini paolo.carl...@oracle.com writes: On 01/30/2012 06:11 PM, Rainer Orth wrote: I.e. there are *no* libstdc++ or C++ changes involved at all. IMO this is a bug, plain and simple. Just to avoid all the pointless discussions we had last time: *on Solaris*. Because if you look at gnu.ver it's obvious that those symbols *on Linux* were normally exported in 3.4.5. Nothing new. A non-C++ change suddenly causing new C++ functions to be emitted that are not present without that change would be a bug on Linux, too! Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [v3] Update Solaris baselines for GCC 4.7
On 01/30/2012 07:06 PM, Rainer Orth wrote: A non-C++ change suddenly causing new C++ functions to be emitted that are not present without that change would be a bug on Linux, too! I should have been more clear: it's *not* a versioning bug on Linux. Maybe what is happening on Solaris is that those functions were inlined, thus not exported, and now aren't anymore. This kind of unpredictability in the inlining choices would not be a compiler bug, or at least not an easy one... Not sure why abi_check didn't complain before on Solaris, because the linker script etc, are meant to export those operators @3.4.5 (and also @3.4 because of an old mistake). This is what happens on Linux since the very old 3.4.5 times. Paolo.
Re: [v3] Update Solaris baselines for GCC 4.7
Paolo Carlini paolo.carl...@oracle.com writes: On 01/30/2012 07:06 PM, Rainer Orth wrote: A non-C++ change suddenly causing new C++ functions to be emitted that are not present without that change would be a bug on Linux, too! I should have been more clear: it's *not* a versioning bug on Linux. Maybe I never claimed that. what is happening on Solaris is that those functions were inlined, thus not exported, and now aren't anymore. This kind of unpredictability in the inlining choices would not be a compiler bug, or at least not an easy one... Whatever, if that were the case, this *must be avoided*. You couldn't remove an exported interface because the compiler suddently decided to inline it, otherwise the whole versioning business became just a joke. Not sure why abi_check didn't complain before on Solaris, because the linker script etc, are meant to export those operators @3.4.5 (and also @3.4 because of an old mistake). This is what happens on Linux since the very old 3.4.5 times. That's due to the way gld linker scripts work: every entry there just works like sort of a wildcard: if the symbol is present in the input objects, it is bound to the respective symbol, if it's missing, this is silently ignored. I observe the introduction of those two symbols with both Sun and GNU ld. IMO, this behavior of gld is fundamentally incompatible with stable versions. Sun ld is different: if a symbol is listed in a version, but missing from the input objects, it errors out. As I stated before, abi_check should just flag all additions to released versions as bugs. That would require us to update all the baselines immediately before releases, though, which unfortunately hasn't been done consistently in the past. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [v3] Update Solaris baselines for GCC 4.7
On 01/30/2012 07:25 PM, Rainer Orth wrote: That's due to the way gld linker scripts work: every entry there just works like sort of a wildcard: if the symbol is present in the input objects, it is bound to the respective symbol, if it's missing, this is silently ignored. I know that. I'm trying to understand why on Solaris you didn't see abi_check errors, because for sure on Linux those operators are in the baselines and normally exported, isn't just about the linker script. I repeat one last time: on Linux we started exporting the symbols @3.4.5, and for real, isn't just that the linker script mentioned the symbols. Then, we (or Jakub) updated the Linux baselines many times, and the baselines always included those symbols. There is nothing special going on on Linux. How you can profitably use this information to understand what't going on on Solaris, I don't know exactly. Paolo.
[PATCH, go testsuite]: Fix PR48501, 64bit-out.go, select5-out.go, tmp.go compilation times out
Hello!
Attached patch introduces adjustable timeout value to go testsuite. I
have added the fix for select5-out.go compilation timeout error, since
this test fails on my target. Following this example, it is trivial to
fix other timeout issues in go-test.exp.
2012-01-30 Uros Bizjak ubiz...@gmail.com
PR go/48501
* lib/go.exp (go_target_compile): Append timeout= to options.
* go.test/go-test.exp (go-gc-tests): Add dg-timeout-factor for
select5-out.go test on alpha*-*-* targets.
Tested on alphaev8-pc-linux-gnu.
OK for mainline?
Uros.
Index: go.test/go-test.exp
===
--- go.test/go-test.exp (revision 183732)
+++ go.test/go-test.exp (working copy)
@@ -1005,7 +1005,10 @@
} else {
pass $name execution
file delete $base-out.x
+ # This testcase takes long time to compile.
+ dg-timeout-factor list 4 { target alpha*-*-* }
go-torture-execute ./$base-out.go
+ unset_timeout_vars
}
file delete $base-out.go
}
Index: lib/go.exp
===
--- lib/go.exp (revision 183732)
+++ lib/go.exp (working copy)
@@ -216,6 +216,7 @@
lappend options ldflags=${wrap_flags}
}
+lappend options timeout=[timeout_value]
lappend options compiler=$GOC_UNDER_TEST
set options [concat $ALWAYS_GOCFLAGS $options]
Re: [v3] Update Solaris baselines for GCC 4.7
Paolo Carlini paolo.carl...@oracle.com writes: I'm trying to understand why on Solaris you didn't see abi_check errors, because for sure on Linux those operators are in the baselines and normally exported, isn't just about the linker script. I repeat one last time: on Linux we started exporting the symbols @3.4.5, and for real, isn't just that the linker script mentioned the symbols. Then, we (or Jakub) updated the Linux baselines many times, and the baselines always included those symbols. There is nothing special going on on Linux. How you can profitably use this information to understand what't going on on Solaris, I don't know exactly. The first gcc release with symbol versioning support was 4.6, and those symbols are *not* in the 4.6 baselines, consistent across both sparc and x86. They only started to appear recently due to the code generation change I've identified. I've no idea why this happened, though. There seem two ways forward: * Understand why they appear now, caused by Martin's change, and didn't before. Perhaps there's a way to make them `go away'... * Accomodate them in gnu.ver by exporting them @3.4.17 *for Solaris only*. I can certainly do that, but would rather understand first what caused their appearance in the first place to avoid them to appear and disappear willy-nilly. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
RE: [Patch,wwwdocs,AVR]: AVR release notes
-Original Message- From: Georg-Johann Lay Sent: Monday, January 30, 2012 6:55 AM To: gcc-patches@gcc.gnu.org Cc: Gerald Pfeifer; Denis Chertykov; Weddington, Eric Subject: Re: [Patch,wwwdocs,AVR]: AVR release notes Attached an updated patch as there were many changes and so that Eric and Denis can easier catch up. Hi Johann, Comments: In the first hunk of the patch, you say that libgcc has been improved and enhanced. Can you elaborate just a little in the docs as to how it has been improved and enhanced? The reason is that we are telling users that they have recompile all their code with a new version of gcc because of these improvements and enhancements, but I think we are too vague in giving them a reason. Users will want to know why they have to do a rebuild. It doesn't have to go into great detail, but just a little less vague. s/Support has beed added/Support has been added/ If the list of built-in functions added is really long, I'm ok leaving out the whole list. But, can we give some sort of short description as to the types of built-in functions added? Other than those things, the updated patch looks good to me. Let me know if I can help with wording / language. Eric Weddington
Re: [Patch] PR51374: combine.c and volatile correctness
Georg-Johann Lay a...@gjlay.de writes:
Richard Sandiford wrote:
What do you think about instead changing:
/* If there are any volatile insns between INSN and I3, reject, because
they might affect machine state. */
for (p = NEXT_INSN (insn); p != i3; p = NEXT_INSN (p))
if (INSN_P (p) p != succ p != succ2 volatile_insn_p (PATTERN
(p)))
return 0;
to:
/* If INSN contains volatile references (specifically volatile MEMs),
we cannot combine across any other volatile references.
Even if INSN doesn't contain volatile references, any intervening
volatile insn might affect machine state. */
pred = volatile_refs_p (insn) ? volatile_refs_p : volatile_insn_p;
for (p = NEXT_INSN (insn); p != i3; p = NEXT_INSN (p))
if (NONDEBUG_INSN_P (p) p != succ p != succ2 pred (PATTERN (p)))
return 0;
This would still allow a volatile_refs_p to cross a volatile_insn_p?
No, volatile_insn_p = volatile_refs_p.
/* If INSN contains anything volatile, or is an `asm' (whether volatile
or not), reject, unless nothing volatile comes between it and I3 */
if (GET_CODE (src) == ASM_OPERANDS || volatile_refs_p (src))
{
/* Make sure neither succ nor succ2 contains a volatile reference. */
if (succ2 != 0 volatile_refs_p (PATTERN (succ2)))
return 0;
if (succ != 0 volatile_refs_p (PATTERN (succ)))
return 0;
/* We'll check insns between INSN and I3 below. */
}
Would our change (whatever it will look like) make that code superfluous?
No, the loop skips succ and succ2, and this if-block is handling
non-volatile ASM_OPERANDS as well as volatile ones.
Moreover, writes of the shape (set (zero_extract (mem ... update
mem_last_set.
Good catch. I think we should use note_stores for added safety though,
rather than call zero_extract out as a special case. (I realise the
function already handles subregs, but still.)
record_dead_and_set_regs_1 is called through note_stores so that (set
(zero_extract (mem)) is handled already and thus no change to
record_dead_and_set_regs_1 is needed, right?
Oops, yes.
Attached you find a new, tentative patch. It resolves the issue in my
small test program. However, I think someone with more insight into
combine should take over the patch.
OK, point taken :-) If you'd prefer someone else to approve it
that's fine.
Richard
[PATCH, go]: Do not panic in test/nilptr.go
Hello!
There is no need for a panic in test/nilptr.go if array doesn't get
allocated in first 256 meg of memory. The compiler has nothing to do
with this.
Index: test/nilptr.go
===
--- test/nilptr.go (revision 183732)
+++ test/nilptr.go (working copy)
@@ -22,7 +22,8 @@
// at the address that might be accidentally
// dereferenced below.
if uintptr(unsafe.Pointer(dummy)) 25620 {
- panic(dummy too far out)
+ println(dummy too far out)
+ return
}
shouldPanic(p1)
Tested on alphaev68-pc-linux-gnu where it fixes the failure.
After proposed patch(es), the only remaining failure on
alpha-linux-gnu is in test/chan/select2.go:
FAIL: go.test/test/chan/select2.go execution, -O2 -g
with
Executing on host: /space/uros/gcc-build/gcc/testsuite/go2/../../gccgo
-B/space/uros/gcc-build/gcc/testsuite/go2/../../
/home/uros/gcc-svn/trunk/gcc/testsuite/go.test/test/chan/select2.go
-I/space/uros/gcc-build/alphaev68-unknown-linux-gnu/./libgo -w -O2
-g -L/space/uros/gcc-build/alphaev68-unknown-linux-gnu/./libgo
-L/space/uros/gcc-build/alphaev68-unknown-linux-gnu/./libgo/.libs -lm
-o /space/uros/gcc-build/gcc/testsuite/go2/select2.x(timeout =
300)
spawn /space/uros/gcc-build/gcc/testsuite/go2/../../gccgo
-B/space/uros/gcc-build/gcc/testsuite/go2/../../
/home/uros/gcc-svn/trunk/gcc/testsuite/go.test/test/chan/select2.go
-I/space/uros/gcc-build/alphaev68-unknown-linux-gnu/./libgo -w -O2 -g
-L/space/uros/gcc-build/alphaev68-unknown-linux-gnu/./libgo
-L/space/uros/gcc-build/alphaev68-unknown-linux-gnu/./libgo/.libs -lm
-o /space/uros/gcc-build/gcc/testsuite/go2/select2.x^M
PASS: go.test/test/chan/select2.go compilation, -O2 -g
Setting LD_LIBRARY_PATH to
.:/space/uros/gcc-build/alphaev68-unknown-linux-gnu/./libgo/.libs:/home/uros/gcc-build/gcc:.:/space/uros/gcc-build/alphaev68-unknown-linux-gnu/./libgo/.libs:/home/uros/gcc-build/gcc
spawn [open ...]^M
BUG: too much memory for 100,000 selects: 2098576
FAIL: go.test/test/chan/select2.go execution, -O2 -g
The test works without problems otherwise. I suspect that memory
consumption threshold is set way too low...
Uros.
Re: [Patch,AVR]: avr.md code clean-up
2012/1/30 Georg-Johann Lay a...@gjlay.de:
This is code clean-up for avr.md.
* It resolves all AS1 and AS2 macros for string insertion.
There are plan strings now and no more needed because:
* All deprecated * quoted-c-code transformed to { c-code }.
so that avr.md matches http://gcc.gnu.org/backends.html
now, i.e. no 'b' in the avr line.
* insn-condition optimize or optimize 0 is redundant with
combine patterns as combine does not run at -O0
* Some minor coding style changes
For the AS1/AS2 removal I used the attached awk.
Ok to apply?
Johann
* config/avr/avr.md: Resolve all AS1 and AS2 macros.
Transform all * quoted-c-code to { c-code }.
Remove redundant test for optimize in combine patterns.
Move (include avr-dimode.md) to end of file.
Please apply.
Denis.
[committed] gcc.target/mips tweaks for mips-sde-elf
This patch fixes a few failures in gcc.target/mips for mips-sde-elf:
* char is unsigned for mips-sde-elf, so we need to explicitly
ask for a signed char if we want one.
* mips-sde-elf only supports 64-bit long doubles, so doesn't
provide TFmode.
* Function profiling isn't supported for MIPS16.
Tested on mips-sde-elf and applied.
Richard
gcc/testsuite/
* gcc.target/mips/extend-1.c (TEST_CHAR): Use signed char.
(TEST_SHORT): Reformat in the same way.
* gcc.target/mips/octeon-exts-6.c (TEST_CHAR): Use signed char.
(TEST_SHORT): Reformat in the same way.
* gcc.target/mips/octeon2-lx-1.c (TEST): Make sign explicit.
* gcc.target/mips/pr37362.c: Skip for mips-sde-elf.
* gcc.target/mips/mmcount-ra-address-1.c (bazl): Add NOMIPS16.
* gcc.target/mips/mmcount-ra-address-2.c (bar): Likewise.
* gcc.target/mips/mmcount-ra-address-3.c (bar): Likewise.
Index: gcc/testsuite/gcc.target/mips/extend-1.c
===
--- gcc/testsuite/gcc.target/mips/extend-1.c2012-01-30 19:01:41.0
+
+++ gcc/testsuite/gcc.target/mips/extend-1.c2012-01-30 19:03:46.0
+
@@ -3,10 +3,18 @@
/* { dg-final { scan-assembler-times \tdsra\t 5 } } */
/* { dg-final { scan-assembler-not \tsll\t } } */
-#define TEST_CHAR(T, N)\
- NOMIPS16 T f##N (long long d, T *a, T *r) { T b = (char) d; *r = b + *a; }
-#define TEST_SHORT(T, N) \
- NOMIPS16 T g##N (long long d, T *a, T *r) { T b = (short) d; *r = b + *a; }
+#define TEST_CHAR(T, N)\
+ NOMIPS16 T \
+ f##N (long long d, T *a, T *r) \
+ {\
+T b = (signed char) d; *r = b + *a;\
+ }
+#define TEST_SHORT(T, N) \
+ NOMIPS16 T \
+ g##N (long long d, T *a, T *r) \
+ {\
+T b = (short) d; *r = b + *a; \
+ }
#define TEST(T, N) TEST_CHAR (T, N) TEST_SHORT (T, N)
TEST (int, 1);
Index: gcc/testsuite/gcc.target/mips/octeon-exts-6.c
===
--- gcc/testsuite/gcc.target/mips/octeon-exts-6.c 2012-01-30
19:01:41.0 +
+++ gcc/testsuite/gcc.target/mips/octeon-exts-6.c 2012-01-30
19:04:52.0 +
@@ -3,10 +3,18 @@
/* { dg-final { scan-assembler-not \t(dsll|dsra)\t } } */
/* { dg-final { scan-assembler-not \tsll\t } } */
-#define TEST_CHAR(T, N)\
- NOMIPS16 T f##N (long long d, T *a, T *r) { T b = (char) d; *r = b + *a; }
-#define TEST_SHORT(T, N) \
- NOMIPS16 T g##N (long long d, T *a, T *r) { T b = (short) d; *r = b + *a; }
+#define TEST_CHAR(T, N)\
+ NOMIPS16 T \
+ f##N (long long d, T *a, T *r) \
+ {\
+T b = (signed char) d; *r = b + *a;\
+ }
+#define TEST_SHORT(T, N) \
+ NOMIPS16 T \
+ g##N (long long d, T *a, T *r) \
+ {\
+T b = (short) d; *r = b + *a; \
+ }
#define TEST(T, N) TEST_CHAR (T, N) TEST_SHORT (T, N)
TEST (int, 1);
Index: gcc/testsuite/gcc.target/mips/octeon2-lx-1.c
===
--- gcc/testsuite/gcc.target/mips/octeon2-lx-1.c2012-01-30
19:01:41.0 +
+++ gcc/testsuite/gcc.target/mips/octeon2-lx-1.c2012-01-30
19:02:30.0 +
@@ -2,9 +2,9 @@
/* { dg-options -march=octeon2 -O -mgp64 } */
#define TEST(N, R, T) \
- T fll##N (T j, R *b, long long i) { return j + b[i]; } \
+ T fll##N (T j, signed R *b, long long i) { return j + b[i]; } \
T gll##N (T j, unsigned R *b, long long i) { return j + b[i]; } \
- T fi##N (T j, R *b, int i) { return j + b[i]; } \
+ T fi##N (T j, signed R *b, int i) { return j + b[i]; } \
T gi##N (T j, unsigned R *b, int i) { return j + b[i]; } \
TEST (1, char, int)
Index: gcc/testsuite/gcc.target/mips/pr37362.c
===
--- gcc/testsuite/gcc.target/mips/pr37362.c 2012-01-30 19:01:41.0
+
+++ gcc/testsuite/gcc.target/mips/pr37362.c 2012-01-30 19:02:30.0
+
@@ -1,4 +1,5 @@
-/* { dg-do compile } */
+/* mips*-sde-elf doesn't have 128-bit long doubles. */
+/* { dg-do compile { target { ! mips*-sde-elf } } } */
/* { dg-options -march=mips64r2 -mabi=n32 } */
typedef float TFtype __attribute__((mode(TF)));
Index: gcc/testsuite/gcc.target/mips/mmcount-ra-address-1.c
===
--- gcc/testsuite/gcc.target/mips/mmcount-ra-address-1.c2012-01-30
19:02:15.0 +
+++
Re: Fix multi-reg regno_reg_rtx entry
Eric Botcazou ebotca...@adacore.com writes:
I'm not sure about the assertion though: if it happens to trigger, the
fix will probably entail far-reaching changes in the back-end, so it's
probably safer to delay it until the next stage #1.
Yeah, that's probably true. How does this version look?
Thanks,
Richard
gcc/
* function.h (regno_reg_rtx): Adjust comment.
* reginfo.c (init_reg_modes_target): Only use the previous mode
if it fits within one register. Remove MIPS comment.
Index: gcc/function.h
===
--- gcc/function.h 2012-01-30 19:23:22.0 +
+++ gcc/function.h 2012-01-30 19:23:51.0 +
@@ -87,10 +87,13 @@ struct GTY(()) emit_status {
};
-/* Indexed by pseudo register number, gives the rtx for that pseudo.
- Allocated in parallel with regno_pointer_align.
- FIXME: We could put it into emit_status struct, but gengtype is not able to
deal
- with length attribute nested in top level structures. */
+/* Indexed by register number, gives an rtx for that register (and only
+ that register). For pseudo registers, it is the unique rtx for
+ that pseudo. For hard registers, it is an rtx of the mode specified
+ by reg_raw_mode.
+
+ FIXME: We could put it into emit_status struct, but gengtype is not
+ able to deal with length attribute nested in top level structures. */
extern GTY ((length (crtl-emit.x_reg_rtx_no))) rtx * regno_reg_rtx;
Index: gcc/reginfo.c
===
--- gcc/reginfo.c 2012-01-30 19:01:55.0 +
+++ gcc/reginfo.c 2012-01-30 19:25:01.0 +
@@ -615,13 +615,15 @@ init_reg_modes_target (void)
{
reg_raw_mode[i] = choose_hard_reg_mode (i, 1, false);
- /* If we couldn't find a valid mode, just use the previous mode.
- ??? One situation in which we need to do this is on the mips where
-HARD_REGNO_NREGS (fpreg, [SD]Fmode) returns 2. Ideally we'd like
-to use DF mode for the even registers and VOIDmode for the odd
-(for the cpu models where the odd ones are inaccessible). */
+ /* If we couldn't find a valid mode, just use the previous mode
+if it is suitable, otherwise fall back on word_mode. */
if (reg_raw_mode[i] == VOIDmode)
- reg_raw_mode[i] = i == 0 ? word_mode : reg_raw_mode[i-1];
+ {
+ if (i 0 hard_regno_nregs[i][reg_raw_mode[i - 1]] == 1)
+ reg_raw_mode[i] = reg_raw_mode[i - 1];
+ else
+ reg_raw_mode[i] = word_mode;
+ }
}
}
Re: [PATCH] Fix PR 51910, -frepo/linker demangling interaction
On 01/30/2012 11:11 AM, Jakub Jelinek wrote: The *.rpo discovery can be many thousands of syscalls too for larger links and I think -frepo is quite rarely used. OK. Can't tlink just take into account that sometimes different symbols mangle the same, and handle those as a group (i.e. if the linker output requests S::~S(), and *.rpo files contain several _ZN1SD[0-9]Ev symbols, mark or tweak them all)? Emitting one doesn't necessary imply emitting all of them. Perhaps we could change the demangler to distinguish between the symbols, but of course that wouldn't affect current linkers. What if we use linker demangling only if the user has specified creating a linker map? Jason
Re: [libitm] Link eh-1.exe with -shared-libgcc on Solaris (PR libitm/51822)
On 01/31/2012 03:40 AM, Rainer Orth wrote: 2012-01-28 Rainer Orth r...@cebitec.uni-bielefeld.de PR libstdc++/51296 * testsuite/libitm.c++/c++.exp (lang_link_flags): Add -shared-libgcc. Correct libgomp references. Ok. r~
Re: [patch, fortran] Fix PR 51958, wrong-code regression with function elimination
Hi Tobias, I found a bug in my patch, which I am currently correcting. *grumble* Watch this space! Thomas
Re: [libitm] Link eh-1.exe with -shared-libgcc on Solaris (PR libitm/51822)
On Mon, Jan 30, 2012 at 12:24:07PM -0500, Patrick Marlier wrote: On 01/30/2012 12:15 PM, Jack Howarth wrote: On Mon, Jan 30, 2012 at 05:40:21PM +0100, Rainer Orth wrote: Richard Hendersonr...@redhat.com writes: On 01/25/2012 12:03 AM, Rainer Orth wrote: Er.. how did we get two copies? The link line boils down to ld -o eh-1.exe crt1.o crti.o crtbegin.o eh-1.o -litm -lstdc++ -lm -lgcc -lgcc_eh -lc -lgcc -lgcc_eh crtend.o crtn.o The eh-1.o reference to _Unwind_Resume drags in one copy of the unwinder from libgcc_eh.a, while libstdc++.so is linked against libgcc_s.so.1, providing another copy. So... are we linking with the gcc binary, not the g++ binary? Because I thought -shared-libgcc is the default for C++. If this goes too far down a rat-hole, your original patch is ok. The compiler used is currently set in libitm.exp (libitm_init) without considering the language used. Changing this seems too risky for stage4. I think we can get away with the following patch instead, which hardcodes -shared-libgcc for C++. I think it is safe even with --disable-shared since -shared-libgcc is simply ignored AFAICS, and is already used unconditionally in libffi.special/special.exp. Tested on i386-pc-solaris2.11. FYI, this fix has no impact on the eh-1.C execution failures seen at -m32/-m64 on x86_64 darwin10/11 when built with Xcode 4.2(.1). Problem was discussed here and not same problem as above: http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00329.html http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00285.html Patrick, My mistake. The issue on darwin with Xcode 4.x will either require avoiding the use of weakref for darwin or assuming that the user will either use Xcode 3.x or a future fixed Xcode 4.x release. I am told the weakref linker bug is fixed upstream but won't make it into Xcode 4.3 (so it is currently unknown when this fix will be available for Lion). Jack -- Patrick.
[Patch, Fortran] PR52029/52013 - small OOP fixes (pure _copy, CAF fix)
First, I am looking for someone to review my patch at
http://gcc.gnu.org/ml/fortran/2012-01/msg00241.html
This patch contains two patches:
a) Marking the polymorphic _copy function as pure. First, it helps with
code generation as the function is actually pure. Secondly, if one
defines the derived type in a PURE function, one currently gets an error
as the impure function _copy is called.
b) We need to build a different class container type for coarrays - the
attached test case is an example why (missing diagnosis as the container
didn't have the coarray attribute). At the same time, I fixes the hash
function criterion. Since the polymorphic array patch, one some long
module + type names were cropped instead of triggering the hash
mechanism, increasing the chance for name collision.
Build and regtested on x86-64-linux.
OK for the trunk?
Tobias
2012-01-30 Tobias Burnus bur...@net-b.de
PR fortran/52013
* class.c (get_unique_hashed_string): Adapt trim length.
(gfc_build_class_symbol) Encode also corank in the container name.
2012-01-30 Tobias Burnus bur...@net-b.de
PR fortran/52013
* gfortran.dg/elemental_args_check_6.f90: New.
Index: gcc/fortran/class.c
===
--- gcc/fortran/class.c (Revision 183737)
+++ gcc/fortran/class.c (Arbeitskopie)
@@ -294,8 +294,10 @@ get_unique_hashed_string (char *string, gfc_symbol
char tmp[2*GFC_MAX_SYMBOL_LEN+2];
get_unique_type_string (tmp[0], derived);
/* If string is too long, use hash value in hex representation (allow for
- extra decoration, cf. gfc_build_class_symbol gfc_find_derived_vtab). */
- if (strlen (tmp) GFC_MAX_SYMBOL_LEN - 11)
+ extra decoration, cf. gfc_build_class_symbol gfc_find_derived_vtab).
+ We need space to for 15 characters __class_ + symbol name + _%d_%da,
+ where %d is the (co)rank which can be up to n = 15. */
+ if (strlen (tmp) GFC_MAX_SYMBOL_LEN - 15)
{
int h = gfc_hash_value (derived);
sprintf (string, %X, h);
@@ -360,10 +362,10 @@ gfc_build_class_symbol (gfc_typespec *ts, symbol_a
/* Determine the name of the encapsulating type. */
get_unique_hashed_string (tname, ts-u.derived);
- if ((*as) (*as)-rank attr-allocatable)
-sprintf (name, __class_%s_%d_a, tname, (*as)-rank);
- else if ((*as) (*as)-rank)
-sprintf (name, __class_%s_%d, tname, (*as)-rank);
+ if ((*as) attr-allocatable)
+sprintf (name, __class_%s_%d_%da, tname, (*as)-rank, (*as)-corank);
+ else if ((*as))
+sprintf (name, __class_%s_%d_%d, tname, (*as)-rank, (*as)-corank);
else if (attr-pointer)
sprintf (name, __class_%s_p, tname);
else if (attr-allocatable)
Index: gcc/testsuite/gfortran.dg/elemental_args_check_6.f90
===
--- gcc/testsuite/gfortran.dg/elemental_args_check_6.f90 (Revision 0)
+++ gcc/testsuite/gfortran.dg/elemental_args_check_6.f90 (Arbeitskopie)
@@ -0,0 +1,15 @@
+! { dg-do compile }
+! { dg-options -fcoarray=single }
+!
+! PR fortran/52013
+!
+type t
+end type t
+contains
+ elemental subroutine f(x)
+class(t), intent(inout) :: x ! Valid
+ end subroutine
+ elemental subroutine g(y) ! { dg-error Coarray dummy argument 'y' at .1. to elemental procedure }
+class(t), intent(inout) :: y[*]
+ end subroutine
+end
2012-01-30 Tobias Burnus bur...@net-b.de
PR fortran/52029
* class.c (gfc_find_derived_vtab): Mark _copy function as pure.
2012-01-30 Tobias Burnus bur...@net-b.de
PR fortran/52029
* gfortran.dg/class_49.f90: New.
Index: gcc/fortran/class.c
===
--- gcc/fortran/class.c (Revision 183737)
+++ gcc/fortran/class.c (Arbeitskopie)
@@ -715,6 +717,7 @@ gfc_find_derived_vtab (gfc_symbol *derived)
sub_ns-proc_name = copy;
copy-attr.flavor = FL_PROCEDURE;
copy-attr.subroutine = 1;
+ copy-attr.pure = 1;
copy-attr.if_source = IFSRC_DECL;
/* This is elemental so that arrays are automatically
treated correctly by the scalarizer. */
Index: gcc/testsuite/gfortran.dg/class_49.f90
===
--- gcc/testsuite/gfortran.dg/class_49.f90 (Revision 0)
+++ gcc/testsuite/gfortran.dg/class_49.f90 (Arbeitskopie)
@@ -0,0 +1,11 @@
+! { dg-do compile }
+!
+! PR fortran/52029
+!
+
+elemental subroutine foo()
+ type t
+ end type t
+ class(t), allocatable :: x
+ if (allocated(x)) i = 5
+end
RE: [committed] PR 51931: force non-MIPS16ness for long-branch tests (NOW RFA: MIPS16 Long Branch Patch)
-Original Message-
From: Chung-Lin Tang [mailto:clt...@codesourcery.com]
Sent: Monday, January 30, 2012 4:36 AM
To: gcc-patches@gcc.gnu.org; rdsandif...@googlemail.com
Cc: Moore, Catherine
Subject: Re: [committed] PR 51931: force non-MIPS16ness for long-branch tests
On 2012/1/22 06:33 PM, Richard Sandiford wrote:
The MIPS16 port has never handled long branches properly; see PR 51931
for the details. It isn't easy to xfail MIPS16-specific problems at
the dejagnu level because of -mflip-mips16, so the patch below forces
a nomips16 attribute instead.
Tested on mips64-linux-gnu and applied.
Richard
CCing Catherine, I think we have a fix for this?
I do have a patch. It's a heuristic and will not work in all instances, but
it does allow many additional programs to successfully compile. For example,
this scheme allowed me to build glibc in MIPS16-mode for a MIPS-Linux
toolchain.
The patch causes reorg to examine mips16 branches. For branches that are
out-of-range, reorg will look for branches to the same target. If that branch
is in range, the destination of the original branch becomes the new branch. If
branches to the same target do not exist, then reorg will search for barriers
that are in range and insert label+ branch at the barrier.
Of the test cases mentioned in the bug report,
gcc.c-torture/compile/20001226-1.c still fails due to a lack of barriers in the
instruction stream. g++.dg/opt/longbranch1.C will pass.
I've set off a test run with my patch applied against mainline. In the
meantime, here's the patch. Richard, what do you think?
Catherine
2012-01-30 Catherine Moore c...@codesourcery.com
gcc/
* config/mips/mips.c (WALK_INSNS): New macro.
(OK_FOR_MIPS16_BRANCH_OFFSET): New macro.
(mips16_count_matching_branches): New function.
(walk_insns_forward): New function.
(walk_insns_reverse): New function.
(mips16_update_branch_info): New function.
(mips16_zero_branch_info): New function.
(mips16_check_branches): New function.
(mips_reorg_process_instructions): Call mips16_check_branches.
* config/mips.h (mips16_branch_info_t): New typedef.
Index: mips.c
===
--- mips.c (revision 183732)
+++ mips.c (working copy)
@@ -123,6 +123,12 @@
(SUBINSN) != NEXT_INSN (SEQ_END (INSN));
\
(SUBINSN) = NEXT_INSN (SUBINSN))
+/* Walk the instruction chain either backwards or forwards. */
+#define WALK_INSNS(START_INSN, INSN, WALK_FUNCTION)\
+ for ((INSN) = (WALK_FUNCTION) (START_INSN); \
+ (INSN) != 0;\
+ (INSN) = (WALK_FUNCTION) (INSN))
+
/* True if bit BIT is set in VALUE. */
#define BITSET_P(VALUE, BIT) (((VALUE) (1 (BIT))) != 0)
@@ -14938,7 +14944,214 @@
}
return INTVAL (offset) = entry-offset;
}
+#define OK_FOR_MIPS16_BRANCH(OFFSET) ((OFFSET) = -65000 (OFFSET) = 65000)
+static int
+mips16_count_matching_branches (rtx jump_insn)
+{
+ rtx insn;
+ int label_uid, jump_uid;
+ int matches = 0;
+
+ jump_uid = INSN_UID (jump_insn);
+ label_uid = INSN_UID (JUMP_LABEL (jump_insn));
+
+ /* Count the number of branches to the same label. */
+ for (insn = get_insns (); insn != 0; insn = NEXT_INSN (insn))
+{
+ if (simplejump_p (insn))
+ {
+ int insn_uid = INSN_UID (JUMP_LABEL (insn));
+ if (insn_uid != jump_uid label_uid == insn_uid)
+ matches++;
+ }
+}
+
+ return matches;
+}
+
+static rtx
+walk_insns_forward (rtx insn)
+{
+ return NEXT_INSN (insn);
+}
+
+static rtx
+walk_insns_reverse (rtx insn)
+{
+ return PREV_INSN (insn);
+}
+
+static void
+mips16_update_branch_info (mips16_branch_info_t *previous,
+ mips16_branch_info_t *current,
+ int insn_uid)
+{
+ /* Move current to previous. */
+ previous-uid = current-uid;
+ previous-address = current-address;
+ previous-distance_to_dest = current-distance_to_dest;
+ previous-distance_from_src = current-distance_from_src;
+
+ /* Update current. */
+ current-uid = insn_uid;
+ current-address = INSN_ADDRESSES (insn_uid);
+}
+
+static void
+mips16_zero_branch_info (mips16_branch_info_t *branch_info)
+{
+ branch_info-uid = 0;
+ branch_info-address = 0;
+ branch_info-distance_to_dest = 0;
+ branch_info-distance_from_src = 0;
+}
+
+static void
+mips16_check_branches (rtx jump_insn)
+{
+ int label1_uid, label2_uid, jump_uid, insn_uid;
+ int offset;
+ rtx label1;
+ rtx insn, new_label, new_label_insn, new_jump, new_jump_label;
+
+ rtx (*walk_function) (rtx);
+
+ mips16_branch_info_t first_branch, current, previous;
+
+ mips16_zero_branch_info (first_branch);
+ mips16_zero_branch_info (current);
+ mips16_zero_branch_info (previous);
+
+ jump_uid = INSN_UID
Re: [PATCH, go testsuite]: Fix PR48501, 64bit-out.go, select5-out.go, tmp.go compilation times out
Uros Bizjak ubiz...@gmail.com writes: 2012-01-30 Uros Bizjak ubiz...@gmail.com PR go/48501 * lib/go.exp (go_target_compile): Append timeout= to options. * go.test/go-test.exp (go-gc-tests): Add dg-timeout-factor for select5-out.go test on alpha*-*-* targets. This is OK. Thanks. Ian
Re: [Patch] PR51374: combine.c and volatile correctness
Richard Sandiford schrieb: Georg-Johann Lay avr@ writes: Attached you find a new, tentative patch. It resolves the issue in my small test program. However, I think someone with more insight into combine should take over the patch. OK, point taken :-) If you'd prefer someone else to approve it that's fine. Sorry for the misunderstanding. The someone else didn't refer to the approver part, it's because I am unexperienced with combine. If you are fine with the patch (and the local block around predicat) I'd gladly check it in and backport to 4.6 where the PR also pops up. Johann
New German PO file for 'gcc' (version 4.7-b20120128)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the German team of translators. The file is available at: http://translationproject.org/latest/gcc/de.po (This file, 'gcc-4.7-b20120128.de.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator. coordina...@translationproject.org
Re: [Patch] PR51374: combine.c and volatile correctness
Georg-Johann Lay a...@gjlay.de writes: Richard Sandiford schrieb: Georg-Johann Lay avr@ writes: Attached you find a new, tentative patch. It resolves the issue in my small test program. However, I think someone with more insight into combine should take over the patch. OK, point taken :-) If you'd prefer someone else to approve it that's fine. Sorry for the misunderstanding. The someone else didn't refer to the approver part, it's because I am unexperienced with combine. Ah, in that case I'm the one who should apologise. I probably misunderstood because it's all too true that I don't know this code very well. :-) If you are fine with the patch (and the local block around predicat) I'd gladly check it in and backport to 4.6 where the PR also pops up. I'd prefer it without the local block, and the variable declared (but not initialised) at the start of the function, but otherwise it's OK for both trunk and 4.6 as far as I'm concerned. I realise you posted the patch a while ago now, but let's leave it 24 hours just in case anyone wants to object. Thanks, Richard
Re: [4.7][google] Adding a new option -fstack-protector-strong. (issue 5461043)
Hi, ping? Could someone take a look at this patch, it has already been reviewed several rounds. I'm to submit it to gcc trunk. Thanks, -Han On Wed, Jan 25, 2012 at 9:41 PM, davi...@google.com wrote: ok for google branches with the above changes. Please continue to seek upstream approval. David http://codereview.appspot.com/5461043/diff/19001/gcc/doc/invoke.texi File gcc/doc/invoke.texi (right): http://codereview.appspot.com/5461043/diff/19001/gcc/doc/invoke.texi#newcode403 gcc/doc/invoke.texi:403: +-fstack-protector-strong -fstack-protector-all -fstrict-aliasing @gol Switch the order of -fstack-protector-all and -fstack-proctor-strong (in alphabetic order) http://codereview.appspot.com/5461043/diff/19001/gcc/doc/invoke.texi#newcode8446 gcc/doc/invoke.texi:8446: +@item -fstack-protector-strong Move this item after -fstack-protector-all http://codereview.appspot.com/5461043/
Re: Fix multi-reg regno_reg_rtx entry
* function.h (regno_reg_rtx): Adjust comment. * reginfo.c (init_reg_modes_target): Only use the previous mode if it fits within one register. Remove MIPS comment. OK, thanks. -- Eric Botcazou
Re: [Patch,wwwdocs,AVR]: AVR release notes
Weddington, Eric schrieb: From: Georg-Johann Lay Attached an updated patch as there were many changes and so that Eric and Denis can easier catch up. Hi Johann, Comments: In the first hunk of the patch, you say that libgcc has been improved and enhanced. Can you elaborate just a little in the docs as to how it has been improved and enhanced? The reason is that we are telling users that they have recompile all their code with a new version of gcc because of these improvements and enhancements, but I think we are too vague in giving them a reason. Users will want to know why they have to do a rebuild. It doesn't have to go into great detail, but just a little less vague. There are new assembler functions in libgcc. Just to mention some: __umulhisi3 __usmulhisi3 __mulshisi3 __mulohisi3 __muluhisi3 __mulsi3 __muldi3 __umoddi3 __udivdi3 __moddi3 __divdi3 __adddi3 __adddi3_s8 __subdi3 __cmpdi2 __cmpdi2_s8 __negdi2 __ashldi3 __ashrdi3 __lshrdi3 __rotldi3 __load_3 __load_4 __xload_1 __xload_2 __xload_3 __xload_4 __movmemx_qi __movmemx_hi __ffssi2 __ffshi2 __ctzsi2 __ctzhi2 __clzdi2 __clzsi2 __clzhi2 __paritydi2 __paritysi2 __parityhi2 __parityqi2 __popcountqi2 __popcounthi2 __popcountsi2 __popcountdi2 __bswapsi2 __bswapdi2 Some of these functions are new. Examples are __parityqi2 or __muluhisi3. Thus, if code contains references to such a function, you need the right libgcc version or otherwise you'll get a complain from the linker. Some of the function were already present in libgcc. Examples are __ashldi3 and __paritysi2. For many functions with assembler implementation the compiler has knowledge about the register footprint and can generate better code by exploiting that knowledge. If is's known that __ashldi3 does not clobber Z, for example, Z need not to be saved around that call resulting in better code. The problem with this kind of improvment is that you get an abi-per-function imlpementation as the compiler has explicit knowledge beyond ABI and makes use of that. Up to now, this was used in multiply, divide and modulo functions; but there was never an ABI change because these implementations are there since the beginning of time. But as soon as you write one single such function after beginning of time, it's the fall of man. And you can just as well write hundreds of them... So the goal was to add as many of such functions in 4.7 as possible, and not spread them over several versions -- or never add them. So we can blaime the users always nagging for better code quality and better 64-bit support ;-) As 4.7 comes with new features like named address spaces (and I also hoped to see Xmega support from you and fixed-point support from Sean), 4.7 can be regarded as milestone justifying such a transition. Built-ins also need libgcc support like __fmuls or PSImode support for __int24 and __uint24 (not listed above). Unfortunately, there was too little time to make even more use of the 4.6 - 4.7 transition, for example by raising fshort-double to a multilib option in order to render avr-gcc standard compliant and get rid of hard-coded double=float in avr.h. But I guess now it's too late? s/Support has beed added/Support has been added/ If the list of built-in functions added is really long, I'm ok leaving out the whole list. But, can we give some sort of short description as to the types of built-in functions added? There are built-ins that map to machine instructions like NOP or supply soft-equivalents like FMUL. There is built-in to map to a delay routine. There are built-ins to help user fiddle with non-contiguous port layouts. (The map8 built-in has a bug that's not yet fixed and I'd like to change semantics to render it more usable.) And there was proposal for thing like bool __builtin_avr_ram_p (const __memx void*); bool __builtin_avr_flash_p (const __memx void*); in order to test if memx pointer points to flash ot to RAM. Other than those things, the updated patch looks good to me. Let me know if I can help with wording / language. What about You = wording/language Me = technical details I think it's easier that way: Ask me if something is unclear with technical stuff, and native speaker compose first class text :-) You will be better than me with explaining technical stuff. You ar ebetter in english and I tend to go too deep into details. Johann
libgo patch committed: Support socket control messages
This patch to libgo adds support for socket control messages. The
source code was already there, but wasn't being built because mksysinfo
didn't generate the necessary type information. This patch fixes that.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.
Ian
diff -r e7bd4eb1ed7e libgo/Makefile.am
--- a/libgo/Makefile.am Fri Jan 27 14:36:52 2012 -0800
+++ b/libgo/Makefile.am Mon Jan 30 15:50:31 2012 -0800
@@ -1593,6 +1593,13 @@
syscall_uname_file = go/syscall/libcall_uname.go
endif
+# GNU/Linux specific socket control messages.
+if LIBGO_IS_LINUX
+syscall_sockcmsg_file = go/syscall/sockcmsg_linux.go
+else
+syscall_sockcmsg_file =
+endif
+
# Support for netlink sockets and messages.
if LIBGO_IS_LINUX
syscall_netlink_file = go/syscall/netlink_linux.go
@@ -1606,8 +1613,10 @@
go/syscall/libcall_support.go \
go/syscall/libcall_posix.go \
go/syscall/socket.go \
+ go/syscall/sockcmsg_unix.go \
go/syscall/str.go \
go/syscall/syscall.go \
+ $(syscall_sockcmsg_file) \
$(syscall_syscall_file) \
$(syscall_exec_file) \
$(syscall_exec_os_file) \
diff -r e7bd4eb1ed7e libgo/go/syscall/sockcmsg_unix.go
--- a/libgo/go/syscall/sockcmsg_unix.go Fri Jan 27 14:36:52 2012 -0800
+++ b/libgo/go/syscall/sockcmsg_unix.go Mon Jan 30 15:50:31 2012 -0800
@@ -14,7 +14,7 @@
// Round the length of a raw sockaddr up to align it propery.
func cmsgAlignOf(salen int) int {
- salign := sizeofPtr
+ salign := int(sizeofPtr)
// NOTE: It seems like 64-bit Darwin kernel still requires 32-bit
// aligned access to BSD subsystem.
if darwinAMD64 {
@@ -39,7 +39,7 @@
}
func cmsgData(cmsg *Cmsghdr) unsafe.Pointer {
- return unsafe.Pointer(uintptr(unsafe.Pointer(cmsg)) + SizeofCmsghdr)
+ return unsafe.Pointer(uintptr(unsafe.Pointer(cmsg)) + uintptr(SizeofCmsghdr))
}
type SocketControlMessage struct {
@@ -72,7 +72,7 @@
func socketControlMessageHeaderAndData(buf []byte) (*Cmsghdr, []byte, error) {
h := (*Cmsghdr)(unsafe.Pointer(buf[0]))
- if h.Len SizeofCmsghdr || int(h.Len) len(buf) {
+ if int(h.Len) SizeofCmsghdr || int(h.Len) len(buf) {
return nil, nil, EINVAL
}
return h, buf[cmsgAlignOf(SizeofCmsghdr):], nil
diff -r e7bd4eb1ed7e libgo/go/syscall/socket.go
--- a/libgo/go/syscall/socket.go Fri Jan 27 14:36:52 2012 -0800
+++ b/libgo/go/syscall/socket.go Mon Jan 30 15:50:31 2012 -0800
@@ -17,12 +17,12 @@
var SocketDisableIPv6 bool
type Sockaddr interface {
- sockaddr() (ptr *RawSockaddrAny, len Socklen_t, err error) // lowercase; only we can define Sockaddrs
+ sockaddr() (ptr *RawSockaddrAny, len Socklen_t, err error) // lowercase; only we can define Sockaddrs
}
type RawSockaddrAny struct {
Addr RawSockaddr
- Pad [12]int8
+ Pad [12]int8
}
const SizeofSockaddrAny = 0x1c
@@ -30,7 +30,7 @@
type SockaddrInet4 struct {
Port int
Addr [4]byte
- raw RawSockaddrInet4
+ raw RawSockaddrInet4
}
func (sa *SockaddrInet4) sockaddr() (*RawSockaddrAny, Socklen_t, error) {
@@ -40,7 +40,7 @@
sa.raw.Family = AF_INET
n := sa.raw.setLen()
p := (*[2]byte)(unsafe.Pointer(sa.raw.Port))
- p[0] = byte(sa.Port8)
+ p[0] = byte(sa.Port 8)
p[1] = byte(sa.Port)
for i := 0; i len(sa.Addr); i++ {
sa.raw.Addr[i] = sa.Addr[i]
@@ -49,10 +49,10 @@
}
type SockaddrInet6 struct {
- Port int
+ Port int
ZoneId uint32
- Addr [16]byte
- raw RawSockaddrInet6
+ Addr [16]byte
+ rawRawSockaddrInet6
}
func (sa *SockaddrInet6) sockaddr() (*RawSockaddrAny, Socklen_t, error) {
@@ -62,7 +62,7 @@
sa.raw.Family = AF_INET6
n := sa.raw.setLen()
p := (*[2]byte)(unsafe.Pointer(sa.raw.Port))
- p[0] = byte(sa.Port8)
+ p[0] = byte(sa.Port 8)
p[1] = byte(sa.Port)
sa.raw.Scope_id = sa.ZoneId
for i := 0; i len(sa.Addr); i++ {
@@ -73,7 +73,7 @@
type SockaddrUnix struct {
Name string
- raw RawSockaddrUnix
+ raw RawSockaddrUnix
}
func (sa *SockaddrUnix) sockaddr() (*RawSockaddrAny, Socklen_t, error) {
@@ -268,12 +268,12 @@
}
type Linger struct {
- Onoff int32;
- Linger int32;
+ Onoff int32
+ Linger int32
}
func SetsockoptLinger(fd, level, opt int, l *Linger) (err error) {
- return setsockopt(fd, level, opt, (*byte)(unsafe.Pointer(l)), Socklen_t(unsafe.Sizeof(*l)));
+ return setsockopt(fd, level, opt, (*byte)(unsafe.Pointer(l)), Socklen_t(unsafe.Sizeof(*l)))
}
func SetsockoptIPMreq(fd, level, opt int, mreq *IPMreq) (err error) {
@@ -405,3 +405,7 @@
func (msghdr *Msghdr) SetControllen(length int) {
msghdr.Controllen = Msghdr_controllen_t(length)
}
+
+func (cmsg *Cmsghdr) SetLen(length int) {
+ cmsg.Len = Cmsghdr_len_t(length)
+}
diff -r e7bd4eb1ed7e libgo/mksysinfo.sh
--- a/libgo/mksysinfo.sh Fri Jan 27 14:36:52 2012 -0800
+++ b/libgo/mksysinfo.sh Mon Jan 30 15:50:31 2012 -0800
@@ -483,6 +483,43 @@
-e 's/msg_flags/Flags/' \
${OUT}
+# The MSG_ flags for Msghdr.
+grep '^const _MSG_' gen-sysinfo.go | \
+ sed -e 's/^\(const \)_\(MSG_[^= ]*\)\(.*\)$/\1\2 = _\2/' ${OUT}
+
+# The cmsghdr struct.
+cmsghdr=`grep '^type
Re: [wwwdocs] Add section on diagnostics conventions
On Mon, Jan 30, 2012 at 9:21 AM, Joseph S. Myers jos...@codesourcery.com wrote: On Sun, 29 Jan 2012, Diego Novillo wrote: +licodeinternal_error/code is used for conditions that should not +be triggered by any user input whether valid or invalid and including +invalid asms and LTO binary data (sometimes, as an exception, there is +a call to codeerror/code before further information is printed and +an ICE is triggered)./li + +liAssertion failures should not be triggered by invalid input. +codeinform/code is for informative notes accompanying errors and +warnings. All diagnostics should be full sentences without English +fragments substituted in them, to facilitate translation./li The three sentences in this last list item are actually three independent and unrelated points. I think the first one about assertion failures should be moved up into the previous list item, while the remaining two sentences should each be a list item on its own. Agreed.
Re: [Patch, fortran] PR 51808 Heap allocate binding labels
On Sun, 29 Jan 2012, Janne Blomqvist wrote: .../gcc-HEAD/gcc/fortran/decl.c:5820:23: error: invalid conversion from 'const char*' to 'char*' [-fpermissive] gmake[3]: *** [fortran/decl.o] Error 1 Have you tried r183679, which should fix this? Yes, I now tried that update (my daily tester yesterday picked a state of the tree without that changeset) and bootstrap passed just fine. I had actually looked for follow-up patches yesterday, but did not see any on the list (possibly missed it). While I can speak only for myself, regtesting on x86_64-unknown-linux-gnu. For some reason this was/is flagged as a warning for me, not an error, so I missed it among all the other warnings. Perhaps something to do with me using --disable-bootstrap, and my host compiler (GCC 4.4) not flagging this as an error while 4.7 does? Yes, absolutely, that made the difference. Thanks for fixing this so quickly. Gerald
Re: Static branch prediction: compare IV to loop bound variable (issue 5504086)
Ok for google branches for now.
thanks,
David
http://codereview.appspot.com/5504086/diff/1004/gcc/predict.c
File gcc/predict.c (right):
http://codereview.appspot.com/5504086/diff/1004/gcc/predict.c#newcode958
gcc/predict.c:958: find_qualified_ssa_name (tree t1, tree t2)
Better change the name into 'strips_small_constant'
http://codereview.appspot.com/5504086/diff/1004/gcc/predict.c#newcode991
gcc/predict.c:991: Return NULL if T does not satisfy IV_COMPARE
condition. */
Fix comment -- there is no IV_COMPARE used here.
http://codereview.appspot.com/5504086/diff/1004/gcc/predict.c#newcode995
gcc/predict.c:995: {
Better change the name into 'get_base_value (tree t)' because the method
basically strips the constant 'offset' away.
http://codereview.appspot.com/5504086/diff/1004/gcc/predict.c#newcode1102
gcc/predict.c:1102: a similar variable. */
Fix the comments. Returns true if T1 and T2 are value coherent.
http://codereview.appspot.com/5504086/diff/1004/gcc/predict.c#newcode1106
gcc/predict.c:1106: {
May be changing the name to
expr_coherent_p (tree t1, tree t2)
http://codereview.appspot.com/5504086/diff/1004/gcc/predict.c#newcode1206
gcc/predict.c:1206: (compare_code == LT_EXPR || compare_code ==
LE_EXPR))
Fix indentation.
http://codereview.appspot.com/5504086/
[PATCH][Cilkplus] Gather Scatter Operations in Array Notations
Hello Everyone,
This patch is for the Cilkplus branch, affecting both the C and C++
Compilers. It implements the Gather, scatter operations.
Thanking You,
Yours Sincerely,
Balaji V. Iyer.diff --git a/gcc/ChangeLog.cilk b/gcc/ChangeLog.cilk
index 4297c91..5913883 100644
--- a/gcc/ChangeLog.cilk
+++ b/gcc/ChangeLog.cilk
@@ -1,3 +1,8 @@
+2012-01-31 Balaji V. Iyer balaji.v.i...@intel.com
+
+ * c-array-notation.c (build_array_notation_expr): Added another
+ dimension to lhs variables to handle gather scatter of array notations.
+
2012-01-26 Balaji V. Iyer balaji.v.i...@intel.com
* c-array-notation.c (fix_builtin_array_notation_fn): Initialized the
diff --git a/gcc/c-array-notation.c b/gcc/c-array-notation.c
index b3039a2..fe00520 100644
--- a/gcc/c-array-notation.c
+++ b/gcc/c-array-notation.c
@@ -283,12 +283,12 @@ build_array_notation_expr (location_t location, tree lhs,
tree lhs_origtype,
enum tree_code modifycode, location_t rhs_loc,
tree rhs, tree rhs_origtype)
{
- bool *lhs_vector = NULL, **rhs_vector = NULL, found_builtin_fn = false;
- tree *lhs_array = NULL, **rhs_array = NULL;
+ bool **lhs_vector = NULL, **rhs_vector = NULL, found_builtin_fn = false;
+ tree **lhs_array = NULL, **rhs_array = NULL;
tree array_expr_lhs = NULL_TREE, array_expr_rhs = NULL_TREE;
tree array_expr = NULL_TREE;
- tree *lhs_value = NULL, **rhs_value = NULL;
- tree *lhs_stride = NULL, *lhs_length = NULL, *lhs_start = NULL;
+ tree **lhs_value = NULL, **rhs_value = NULL;
+ tree **lhs_stride = NULL, **lhs_length = NULL, **lhs_start = NULL;
tree **rhs_stride = NULL, **rhs_length = NULL, **rhs_start = NULL;
tree loop = NULL_TREE, *lhs_var = NULL, *rhs_var = NULL;
tree *body_label = NULL, *body_label_expr = NULL;
@@ -296,12 +296,13 @@ build_array_notation_expr (location_t location, tree lhs,
tree lhs_origtype,
tree *if_stmt_label = NULL;
tree *lhs_expr_incr = NULL, *rhs_expr_incr = NULL;
tree *lhs_ind_init = NULL, *rhs_ind_init = NULL;
- bool *lhs_count_down = NULL, **rhs_count_down = NULL;
+ bool **lhs_count_down = NULL, **rhs_count_down = NULL;
tree *lhs_compare = NULL, *rhs_compare = NULL, *rhs_array_operand = NULL;
+ tree *lhs_array_operand = NULL;
int lhs_rank = 0, rhs_rank = 0, ii = 0, jj = 0;
- tree ii_tree = NULL_TREE, new_modify_expr;
+ tree ii_tree = NULL_TREE, new_modify_expr, *lhs_list = NULL;
tree *rhs_list = NULL, new_var = NULL_TREE, builtin_loop = NULL_TREE;
- int rhs_list_size = 0;
+ int rhs_list_size = 0, lhs_list_size = 0;
find_rank (rhs, false, rhs_rank);
@@ -349,6 +350,7 @@ build_array_notation_expr (location_t location, tree lhs,
tree lhs_origtype,
rhs_list_size = 0;
rhs_list = NULL;
extract_array_notation_exprs (rhs, true, rhs_list, rhs_list_size);
+ extract_array_notation_exprs (lhs, true, lhs_list, lhs_list_size);
if (lhs_rank == 0 rhs_rank != 0)
{
@@ -362,35 +364,51 @@ build_array_notation_expr (location_t location, tree lhs,
tree lhs_origtype,
return error_mark_node;
}
- lhs_vector = (bool *) xmalloc (sizeof (bool) * lhs_rank);
+ lhs_vector = (bool **) xmalloc (sizeof (bool *) * lhs_list_size);
+ for (ii = 0; ii lhs_list_size; ii++)
+lhs_vector[ii] = (bool *) xmalloc (sizeof (bool) * lhs_rank);
+
rhs_vector = (bool **) xmalloc (sizeof (bool *) * rhs_list_size);
for (ii = 0; ii rhs_list_size; ii++)
rhs_vector[ii] = (bool *) xmalloc (sizeof (bool) * rhs_rank);
- lhs_array = (tree *) xmalloc (sizeof (tree) * lhs_rank);
+ lhs_array = (tree **) xmalloc (sizeof (tree *) * lhs_list_size);
+ for (ii = 0; ii lhs_list_size; ii++)
+lhs_array[ii] = (tree *) xmalloc (sizeof (tree) * lhs_rank);
+
rhs_array = (tree **) xmalloc (sizeof (tree *) * rhs_list_size);
for (ii = 0; ii rhs_list_size; ii++)
rhs_array[ii] = (tree *) xmalloc (sizeof (tree) * rhs_rank);
- lhs_value = (tree *) xmalloc (sizeof (tree) * lhs_rank);
-
+ lhs_value = (tree **) xmalloc (sizeof (tree *) * lhs_list_size);
+ for (ii = 0; ii lhs_list_size; ii++)
+lhs_value[ii] = (tree *) xmalloc (sizeof (tree) * lhs_rank);
+
rhs_value = (tree **) xmalloc (sizeof (tree *) * rhs_list_size);
for (ii = 0; ii rhs_list_size; ii++)
rhs_value[ii] = (tree *) xmalloc (sizeof (tree) * rhs_rank);
- lhs_stride = (tree *) xmalloc (sizeof (tree) * lhs_rank);
-
+ lhs_stride = (tree **) xmalloc (sizeof (tree *) * lhs_list_size);
+ for (ii = 0; ii lhs_list_size; ii++)
+lhs_stride[ii] = (tree *) xmalloc (sizeof (tree *) * lhs_rank);
+
rhs_stride = (tree **) xmalloc (sizeof (tree *) * rhs_list_size);
for (ii = 0; ii rhs_list_size; ii++)
rhs_stride[ii] = (tree *) xmalloc (sizeof (tree) * rhs_rank);
- lhs_length = (tree *) xmalloc (sizeof (tree) * lhs_rank);
+ lhs_length = (tree **) xmalloc (sizeof (tree *) * lhs_list_size);
+ for (ii = 0; ii lhs_list_size; ii++)
+lhs_length[ii] = (tree *) xmalloc
[arm] Improve longlong.h umul_ppmm, count_trailing_zeros
I noticed this accidentally, while looking for something else.
There are significant improvements in the DImode multiplication
and division routines for armv4+.
Despite how trivial this is, I assume this must wait for stage1.
Ok?
r~
* longlong.h [arm] (umul_ppmm): Use umull.
[arm] (count_trailing_zeros): Use __builtin_ctz.
diff --git a/libgcc/longlong.h b/libgcc/longlong.h
index 30cc2e3..7204679 100644
--- a/libgcc/longlong.h
+++ b/libgcc/longlong.h
@@ -220,9 +220,12 @@ UDItype __umulsidi3 (USItype, USItype);
rI ((USItype) (bh)), \
r ((USItype) (al)), \
rI ((USItype) (bl)) __CLOBBER_CC)
-#define umul_ppmm(xh, xl, a, b) \
-{register USItype __t0, __t1, __t2;\
- __asm__ (%@ Inlined umul_ppmm\n\
+# if defined(__ARM_ARCH_2__) || defined(__ARM_ARCH_2A__) \
+ || defined(__ARM_ARCH_3__) || defined(__ARM_ARCH_3M__)
+# define umul_ppmm(xh, xl, a, b) \
+ do { \
+register USItype __t0, __t1, __t2; \
+__asm__ (%@ Inlined umul_ppmm\n \
mov %2, %5, lsr #16\n \
mov %0, %6, lsr #16\n \
bic %3, %5, %2, lsl #16\n \
@@ -239,14 +242,26 @@ UDItype __umulsidi3 (USItype, USItype);
=r ((USItype) (xl)), \
=r (__t0), =r (__t1), =r (__t2)\
: r ((USItype) (a)), \
-r ((USItype) (b)) __CLOBBER_CC );}
-#define UMUL_TIME 20
-#define UDIV_TIME 100
+r ((USItype) (b)) __CLOBBER_CC );\
+ } while (0)
+# define UMUL_TIME 20
+# else
+# define umul_ppmm(xh, xl, a, b) \
+ do { \
+/* Generate umull, under compiler control. */ \
+register UDItype __t0 = (UDItype)(USItype)(a) * (USItype)(b); \
+(xl) = (USItype)__t0; \
+(xh) = (USItype)(__t0 32); \
+ } while (0)
+# define UMUL_TIME 3
+# endif
+# define UDIV_TIME 100
#endif /* __arm__ */
#if defined(__arm__)
/* Let gcc decide how best to implement count_leading_zeros. */
#define count_leading_zeros(COUNT,X) ((COUNT) = __builtin_clz (X))
+#define count_trailing_zeros(COUNT,X) ((COUNT) = __builtin_ctz (X))
#define COUNT_LEADING_ZEROS_0 32
#endif
