RE: [PATCH, ARM, iWMMXT] Fix define_constants for WCGR
>At 2013-01-22 19:58:43,"Ramana Radhakrishnan" wrote:> > > On 01/22/13 09:21, Xinyu Qi wrote: > > > Ping, > > > > > > Fix ChangeLog > > > > The ChangeLog format includes . > > > > > > > > If you want a patch accepted in the future, please help by creating > > the Changelog entry in the correct format, i.e. fill in the author's > > name as well as email address as below. I've created an entry as > > below. Please remember to do so for every patch you submit - thanks. > > > > Xinyu Qi > > > > * config/arm/arm.h (FIRST_IWMMXT_GR_REGNUM): Add comment. > > * config/arm/iwmmxt.md (WCGR0): Update. > > (WCGR1, WCGR2, WCGR3): Likewise. > > > > The patch by itself is OK but surprisingly I never saw this earlier. > > Your ping has removed the date from the original post so I couldn't > > track it down. > > > > Anyway, please apply. > > > > > > regards, > > Ramana > > > > > Hi Ramana, Since I have no write access, would you mind to help to check in this patch? The patch is attached. ChangeLog 2013-01-31 Xinyu Qi * config/arm/arm.h (FIRST_IWMMXT_GR_REGNUM): Add comment. * config/arm/iwmmxt.md (WCGR0): Update. (WCGR1, WCGR2, WCGR3): Likewise. Thanks, Xinyu WCGR.DIFF Description: WCGR.DIFF
[C++ Patch] Clean-up a bit grokdeclarator
Hi,
as I mentioned a few days ago, since this function grew rather big, I
hope to clean it up a bit. For now at least nothing ground shaking: I
moved together some declarations and initializations; in other cases
exploited the opportunity C++ gives to defer declarations; consistently
changed some int flags to bool (and avoiding names ending by *p for non
bools); plus rather obvious stylistic tweaks (like wrapping way overlong
lines). I'm also improving a bit the diagnostics - see the new testcases
- telling apart and in two error messages. It's a
start. How does it look to you?
Tested x86_64-linux.
Thanks,
Paolo.
/
/cp
2013-03-20 Paolo Carlini
* decl.c (grokdeclarator): Tidy.
(bad_specifiers): Likewise.
(grokfndecl): Likewise; improve error messages.
/testsuite
2013-03-20 Paolo Carlini
* g++.dg/cpp0x/constexpr-friend-2.C: New.
* g++.dg/cpp0x/constexpr-main.C: Likewise.
Index: cp/decl.c
===
--- cp/decl.c (revision 196797)
+++ cp/decl.c (working copy)
@@ -77,8 +77,8 @@ static void record_unknown_type (tree, const char
static tree builtin_function_1 (tree, tree, bool);
static tree build_library_fn_1 (tree, enum tree_code, tree);
static int member_function_or_else (tree, tree, enum overload_flags);
-static void bad_specifiers (tree, enum bad_spec_place, int, int, int, int,
- int);
+static void bad_specifiers (tree, enum bad_spec_place, bool, bool, bool,
+ bool, bool);
static void check_for_uninitialized_const_var (tree);
static hashval_t typename_hash (const void *);
static int typename_compare (const void *, const void *);
@@ -7154,11 +7154,11 @@ member_function_or_else (tree ctype, tree cur_type
static void
bad_specifiers (tree object,
enum bad_spec_place type,
- int virtualp,
- int quals,
- int inlinep,
- int friendp,
- int raises)
+ bool virtualp,
+ bool quals,
+ bool inlinep,
+ bool friendp,
+ bool raises)
{
switch (type)
{
@@ -7310,14 +7310,15 @@ grokfndecl (tree ctype,
tree declarator,
tree parms,
tree orig_declarator,
- int virtualp,
+ bool virtualp,
enum overload_flags flags,
cp_cv_quals quals,
tree raises,
int check,
- int friendp,
- int publicp,
- int inlinep,
+ bool friendp,
+ bool publicp,
+ bool inlinep,
+ bool constexprp,
special_function_kind sfk,
bool funcdef_flag,
int template_count,
@@ -7326,7 +7327,7 @@ grokfndecl (tree ctype,
location_t location)
{
tree decl;
- int staticp = ctype && TREE_CODE (type) == FUNCTION_TYPE;
+ bool staticp = ctype && TREE_CODE (type) == FUNCTION_TYPE;
tree t;
if (raises)
@@ -7427,13 +7428,14 @@ grokfndecl (tree ctype,
return NULL_TREE;
}
- if (inlinep)
- {
- error ("% is not allowed in declaration of friend "
-"template specialization %qD",
-decl);
- return NULL_TREE;
- }
+ if (inlinep)
+ error ("% is not allowed in declaration of friend "
+ "template specialization %qD", decl);
+ if (constexprp)
+ error ("% is not allowed in declaration of friend "
+ "template specialization %qD", decl);
+ if (inlinep || constexprp)
+ return NULL_TREE;
}
}
@@ -7474,17 +7476,20 @@ grokfndecl (tree ctype,
error ("cannot declare %<::main%> to be a template");
if (inlinep)
error ("cannot declare %<::main%> to be inline");
+ if (constexprp)
+ error ("cannot declare %<::main%> to be constexpr");
if (!publicp)
error ("cannot declare %<::main%> to be static");
- inlinep = 0;
- publicp = 1;
+ inlinep = false;
+ constexprp = false;
+ publicp = true;
}
/* Members of anonymous types and local classes have no linkage; make
them internal. If a typedef is made later, this will be changed. */
if (ctype && (TYPE_ANONYMOUS_P (ctype)
|| decl_function_context (TYPE_MAIN_DECL (ctype
-publicp = 0;
+publicp = false;
if (publicp && cxx_dialect == cxx98)
{
@@ -7526,9 +7531,9 @@ grokfndecl (tree ctype,
}
/* If the declaration was declared inline, mark it as such. */
- if (inlinep)
+ if (inlinep || constexprp)
DECL_DECLARED_INLINE_P (decl) = 1;
- if (inlinep & 2)
+ if (constexprp)
DECL_DECLARED_CONSTEXPR_P (decl) = true;
DECL_EXTERNAL (decl) = 1;
@@ -7611,7 +7616,7 @@ grokfndecl (tree ctype,
decl = check_explicit
Re: [Ada, RFC patch] Fortran Interface: Update comment, add some of the Star/Kind type definitions
> Looks fine, including the factor of 2 distinction between Kind and Star for > Complex types. I don't have any opinion on how complete > this is, someone who uses Fortran more extensively will know whether other > interface types might be useful. Thanks Ed. So Tobias: you can go ahead and commit these changes, assuming a clean build/test for Ada. Arno
Re: [Ada, RFC patch] Fortran Interface: Update comment, add some of the Star/Kind type definitions
Looks fine, including the factor of 2 distinction between Kind and Star for Complex types. I don't have any opinion on how complete this is, someone who uses Fortran more extensively will know whether other interface types might be useful. Ed On Mar 19, 2013, at 5:51 PM, Arnaud Charlet wrote: >> I would like if some of the Ada/GNAT experts could have a look - as >> this is really my first look at Ada code. > > Patch looks reasonable to me at first sight, but I'm not a Fortran specialist. > > Ed, Robert, could you have a look? > >> 2013-03-19 Tobias Burnus >> >> * i-fortra.ads: Update comment, add Ada 2012's optional >> Star and Kind data types for enhanced interoperability. >> >> diff --git a/gcc/ada/i-fortra.ads b/gcc/ada/i-fortra.ads >> index 992eb28..270c819 100644 >> --- a/gcc/ada/i-fortra.ads >> +++ b/gcc/ada/i-fortra.ads >> @@ -26,11 +26,11 @@ package Interfaces.Fortran is >>type Logical is new Boolean; >>for Logical'Size use Integer'Size; >>pragma Convention (Fortran, Logical); >> - -- As required by Fortran standard, stand alone logical allocates same >> - -- space as integer (but what about the array case???). The convention >> - -- is important, since in Fortran, Booleans have zero/non-zero semantics >> - -- for False/True, and the pragma Convention (Fortran) activates the >> - -- special handling required in this case. >> + -- As required by Fortran standard, logical allocates same space as >> + -- an integer. The convention is important, since in Fortran, Booleans >> + -- are implemented with zero/non-zero semantics for False/True, and the >> + -- pragma Convention (Fortran) activates the special handling required >> + -- in this case. >> >>package Single_Precision_Complex_Types is >> new Ada.Numerics.Generic_Complex_Types (Real); >> @@ -50,6 +50,53 @@ package Interfaces.Fortran is >> >>type Fortran_Character is array (Positive range <>) of >>Character_Set; >> >> + -- Additional declarations as permitted by Ada 2012, p.608, paragraph >> 21. >> + -- Interoperability with Fortran 77's vendor extension using star >> + -- notation and Fortran 90's intrinsic types with kind=n parameter. >> + -- The following assumes that `n' matches the byte size, which >> + -- most Fortran compiler, including GCC's follow. >> + >> + type Integer_Star_1 is new Integer_8; >> + type Integer_Kind_1 is new Integer_8; >> + type Integer_Star_2 is new Integer_16; >> + type Integer_Kind_2 is new Integer_16; >> + type Integer_Star_4 is new Integer_32; >> + type Integer_Kind_4 is new Integer_32; >> + type Integer_Star_8 is new Integer_64; >> + type Integer_Kind_8 is new Integer_64; >> + >> + type Logical_Star_1 is new Boolean; >> + type Logical_Star_2 is new Boolean; >> + type Logical_Star_4 is new Boolean; >> + type Logical_Star_8 is new Boolean; >> + for Logical_Star_1'Size use Integer_8'Size; >> + for Logical_Star_2'Size use Integer_16'Size; >> + for Logical_Star_4'Size use Integer_32'Size; >> + for Logical_Star_8'Size use Integer_64'Size; >> + pragma Convention (Fortran, Logical_Star_1); >> + pragma Convention (Fortran, Logical_Star_2); >> + pragma Convention (Fortran, Logical_Star_4); >> + pragma Convention (Fortran, Logical_Star_8); >> + >> + type Logical_Kind_1 is new Logical_Star_1; >> + type Logical_Kind_2 is new Logical_Star_2; >> + type Logical_Kind_4 is new Logical_Star_4; >> + type Logical_Kind_8 is new Logical_Star_8; >> + >> + type Real_Star_4 is new Float; >> + type Real_Kind_4 is new Float; >> + type Real_Star_8 is new Long_Float; >> + type Real_Kind_8 is new Long_Float; >> + >> + -- In the kind syntax, n is the same as the associated real kind. >> + -- In the star syntax, n is twice as large (real+imaginary size) >> + type Complex_Star_8 is new Complex; >> + type Complex_Kind_4 is new Complex; >> + type Complex_Star_16 is new Double_Complex; >> + type Complex_Kind_8 is new Double_Complex; >> + >> + type Character_Kind_n is new Fortran_Character; >> + >>function To_Fortran (Item : Character) return Character_Set; >>function To_Ada (Item : Character_Set) return Character;
Re: [Ada, RFC patch] Fortran Interface: Update comment, add some of the Star/Kind type definitions
> I would like if some of the Ada/GNAT experts could have a look - as > this is really my first look at Ada code. Patch looks reasonable to me at first sight, but I'm not a Fortran specialist. Ed, Robert, could you have a look? > 2013-03-19 Tobias Burnus > > * i-fortra.ads: Update comment, add Ada 2012's optional > Star and Kind data types for enhanced interoperability. > > diff --git a/gcc/ada/i-fortra.ads b/gcc/ada/i-fortra.ads > index 992eb28..270c819 100644 > --- a/gcc/ada/i-fortra.ads > +++ b/gcc/ada/i-fortra.ads > @@ -26,11 +26,11 @@ package Interfaces.Fortran is > type Logical is new Boolean; > for Logical'Size use Integer'Size; > pragma Convention (Fortran, Logical); > - -- As required by Fortran standard, stand alone logical allocates same > - -- space as integer (but what about the array case???). The convention > - -- is important, since in Fortran, Booleans have zero/non-zero semantics > - -- for False/True, and the pragma Convention (Fortran) activates the > - -- special handling required in this case. > + -- As required by Fortran standard, logical allocates same space as > + -- an integer. The convention is important, since in Fortran, Booleans > + -- are implemented with zero/non-zero semantics for False/True, and the > + -- pragma Convention (Fortran) activates the special handling required > + -- in this case. > > package Single_Precision_Complex_Types is >new Ada.Numerics.Generic_Complex_Types (Real); > @@ -50,6 +50,53 @@ package Interfaces.Fortran is > > type Fortran_Character is array (Positive range <>) of > Character_Set; > > + -- Additional declarations as permitted by Ada 2012, p.608, paragraph 21. > + -- Interoperability with Fortran 77's vendor extension using star > + -- notation and Fortran 90's intrinsic types with kind=n parameter. > + -- The following assumes that `n' matches the byte size, which > + -- most Fortran compiler, including GCC's follow. > + > + type Integer_Star_1 is new Integer_8; > + type Integer_Kind_1 is new Integer_8; > + type Integer_Star_2 is new Integer_16; > + type Integer_Kind_2 is new Integer_16; > + type Integer_Star_4 is new Integer_32; > + type Integer_Kind_4 is new Integer_32; > + type Integer_Star_8 is new Integer_64; > + type Integer_Kind_8 is new Integer_64; > + > + type Logical_Star_1 is new Boolean; > + type Logical_Star_2 is new Boolean; > + type Logical_Star_4 is new Boolean; > + type Logical_Star_8 is new Boolean; > + for Logical_Star_1'Size use Integer_8'Size; > + for Logical_Star_2'Size use Integer_16'Size; > + for Logical_Star_4'Size use Integer_32'Size; > + for Logical_Star_8'Size use Integer_64'Size; > + pragma Convention (Fortran, Logical_Star_1); > + pragma Convention (Fortran, Logical_Star_2); > + pragma Convention (Fortran, Logical_Star_4); > + pragma Convention (Fortran, Logical_Star_8); > + > + type Logical_Kind_1 is new Logical_Star_1; > + type Logical_Kind_2 is new Logical_Star_2; > + type Logical_Kind_4 is new Logical_Star_4; > + type Logical_Kind_8 is new Logical_Star_8; > + > + type Real_Star_4 is new Float; > + type Real_Kind_4 is new Float; > + type Real_Star_8 is new Long_Float; > + type Real_Kind_8 is new Long_Float; > + > + -- In the kind syntax, n is the same as the associated real kind. > + -- In the star syntax, n is twice as large (real+imaginary size) > + type Complex_Star_8 is new Complex; > + type Complex_Kind_4 is new Complex; > + type Complex_Star_16 is new Double_Complex; > + type Complex_Kind_8 is new Double_Complex; > + > + type Character_Kind_n is new Fortran_Character; > + > function To_Fortran (Item : Character) return Character_Set; > function To_Ada (Item : Character_Set) return Character;
RE: [Patch, microblaze]: Enable DWARF exception handling support
> -Original Message- > From: Michael Eager [mailto:ea...@eagerm.com] > Sent: Wednesday, 20 March 2013 3:05 am > To: David Holsgrove > Cc: gcc-patches@gcc.gnu.org; Edgar Iglesias; John Williams; Vinod Kathail; > Vidhumouli Hunsigida; Nagaraju Mekala; Tom Shui > Subject: Re: [Patch, microblaze]: Enable DWARF exception handling support > > On 03/18/2013 05:47 AM, David Holsgrove wrote: > > Add DWARF exception handling support for MicroBlaze. > > > > Changelog > > > > 2013-03-18 Edgar E. Iglesias > > David Holsgrove > > > > * common/config/microblaze/microblaze-common.c: Remove > > TARGET_EXCEPT_UNWIND_INFO definition. > > * config/microblaze/microblaze-protos.h: Add microblaze_eh_return > prototype. > > * gcc/config/microblaze/microblaze.c: (microblaze_must_save_register, > > microblaze_expand_epilogue, microblaze_return_addr): Handle > > calls_eh_return > > (microblaze_eh_return): New function. > > * gcc/config/microblaze/microblaze.h: Define RETURN_ADDR_OFFSET, > > EH_RETURN_DATA_REGNO, MB_EH_STACKADJ_REGNUM, > EH_RETURN_STACKADJ_RTX, > > ASM_PREFERRED_EH_DATA_FORMAT > > * gcc/config/microblaze/microblaze.md: Define eh_return pattern. > > Hi David -- > > I see about 50 more failures (an increase from 137 to 189) in the g++ > regression tests after applying this patch. I haven't looked at the > failures in detail. > Hi Michael, Thanks I'll have another look at the regression tests today. We should be enabling new tests now by supporting DWARF, but I don’t think my last run with a microblaze-xilinx-linux-gnu was giving me as many failures as you see; === g++ Summary === # of expected passes26617 # of unexpected failures17 # of unexpected successes 2 # of expected failures 167 # of unresolved testcases 3 # of unsupported tests 433 thanks, David > > -- > Michael Eager ea...@eagercon.com > 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
RE: FW: [PATCH] [MIPS] microMIPS gcc support
> -Original Message-
> From: Richard Sandiford [mailto:rdsandif...@googlemail.com]
> Sent: Tuesday, March 19, 2013 3:26 PM
> To: Moore, Catherine
> Cc: gcc-patches@gcc.gnu.org; Rozycki, Maciej
> Subject: Re: FW: [PATCH] [MIPS] microMIPS gcc support
>
> "Moore, Catherine" writes:
> >> >> -Original Message-
> >> >> From: Richard Sandiford [mailto:rdsandif...@googlemail.com]
> >> >> Sent: Tuesday, March 05, 2013 4:06 PM
> >> >> To: Moore, Catherine
> >> >> Cc: gcc-patches@gcc.gnu.org; Rozycki, Maciej
> >> >> Subject: Re: FW: [PATCH] [MIPS] microMIPS gcc support:
> >> >>
> >> >> We have a few internal-only undocumented constraints that aren't
> >> >> used much, so we should be able to move them to the "Y" space
> instead.
> >> >> The patch below does this for "T" and "U". Then we could use "U"
> >> >> for new, longer constraints.
> >> >>
> >> >>
> >> >> U
> >> >>
> >> >> where is:
> >> >>
> >> >> s for signed
> >> >> u for unsigned
> >> >> d for decremented unsigned (-1 ... N)
> >> >> i for incremented unsigned (1 ... N)
> >> >>
> >> >> where is:
> >> >>
> >> >> b for "byte" (*1)
> >> >> h for "halfwords" (*2)
> >> >> w for "words" (*4)
> >> >> d for "doublewords" (*8) -- useful for 64-bit MIPS16 but probably not
> >> >> needed for 32-bit microMIPS
> >> >>
> >> >> and where is the number of bits. and could
> >> >> be replaced with an ad-hoc two-letter combination for special cases.
> >> >> E.g. "Uas9" ("add stack") for ADDISUP.
> >> >>
> >> >> Just a suggestion though. I'm not saying these names are totally
> >> >> intuitive or anything, but they should at least be better than
> >> >> arbitrary
> >> letters.
> >> >>
> >> >> Also, could be two digits if necessary, or we could just
> >> >> use hex
> >> digits.
> >> >
> >> > I extended this proposal a bit by:
> >> > 1. Adding a e for encoded. The constraint will start with
> >> > Ue, when the operand is an encoded value.
> >> > 2. I decided to use two digits for .
> >> > 3. The ad-hoc combination is used for anything else.
> >>
> >> First of all, thanks for coming up with a counter-suggestion. I'm
> >> hopeless at naming things, so I was hoping there would be at least some
> pushback.
> >>
> >> "e" for "encoded" sounds good. I'm less keen on the mixture of
> >> single- and double-digit widths though (single digit for some "Ue"s,
> >> double digits for other "U"s.) I think we should either:
> >>
> >> (a) use the same number of digits for all "U" constraints. That leaves
> >> one character for the "Ue" type, which isn't as mnemonic, but is in
> >> line with what we do elsewhere.
> >>
> >> (b) avoid digits in the "Ue" forms and just have an ad-hoc letter
> combination.
>
> FWIW, as far as this point goes, the patch still has "Uea4".
>
> >> > +/* Return true if X is a legitimate address that conforms to the
> >> requirements
> >> > + for any of the short microMIPS LOAD or STORE instructions except
> LWSP
> >> > + or SWSP. */
> >> > +
> >> > +bool
> >> > +umips_address_p (rtx x, bool load, enum machine_mode mode) {
> >> > +
> >> > + struct mips_address_info addr;
> >> > + bool ok = mips_classify_address (&addr, x, mode, false)
> >> > +&& addr.type == ADDRESS_REG
> >> > +&& M16_REG_P (REGNO (addr.reg))
> >> > +&& CONST_INT_P (addr.offset);
> >> > +
> >> > + if (!ok)
> >> > +return false;
> >> > +
> >> > + if (mips_unsigned_immediate_p (INTVAL (addr.offset), 4, 2)
> >> > + || mips_unsigned_immediate_p (INTVAL (addr.offset), 4, 1))
> >> > +return true;
> >> > +
> >> > + if (load && IN_RANGE (INTVAL (addr.offset), -1, 14))
> >> > +return true;
> >> > +
> >> > + if (!load && IN_RANGE (INTVAL (addr.offset), 0, 15))
> >> > +return true;
> >> > +
> >> > + return false;
> >> > +
> >> > +}
> >>
> >> No blank lines after "{" and before "}".
> >>
> >> More importantly, what cases are these range tests covering?
> >> Both binutils and qemu seem to think that LW and SW need offsets that
> >> exactly match:
> >>
> >> mips_unsigned_immediate_p (INTVAL (addr.offset), 4, 2)
> >>
> >
> > Those range tests are for the LBU16 and SB16 instructions. LBU16
> > supports offsets from -1 to 14 (encodes -1 as 15) while the SB16 insn
> > supports offsets from 0-15.
>
> They need to use separate constraints in that case. The patch as written
> allows -1 offsets for LW16 too. (In rare cases, offsets like -1 can be used
> even
> with aligned word loads.)
>
> E.g. we could have:
>
> /* Return true if X is legitimate for accessing values of mode MODE,
>if it is based on a MIPS16 register, and if the offset satisfies
>OFFSET_PREDICATE. */
>
> bool
> m16_based_address_p (rtx x, enum machine_mode mode,
>insn_operand_predicate_fn predicate) {
> struct mips_address_info addr;
> return (mips_classify_address (&addr, x, mode, false)
> && addr.type == ADDRESS_REG
> && M16_REG_P (REGNO (addr.reg))
> && offse
Re: FW: [PATCH] [MIPS] microMIPS gcc support
"Moore, Catherine" writes:
>> -Original Message-
>> From: Richard Sandiford [mailto:rdsandif...@googlemail.com]
>> Sent: Tuesday, March 19, 2013 3:26 PM
>> To: Moore, Catherine
>> Cc: gcc-patches@gcc.gnu.org; Rozycki, Maciej
>> Subject: Re: FW: [PATCH] [MIPS] microMIPS gcc support
>>
>> "Moore, Catherine" writes:
>> >> >> -Original Message-
>> >> >> From: Richard Sandiford [mailto:rdsandif...@googlemail.com]
>> >> >> Sent: Tuesday, March 05, 2013 4:06 PM
>> >> >> To: Moore, Catherine
>> >> >> Cc: gcc-patches@gcc.gnu.org; Rozycki, Maciej
>> >> >> Subject: Re: FW: [PATCH] [MIPS] microMIPS gcc support:
>> >> >>
>> >> >> We have a few internal-only undocumented constraints that aren't
>> >> >> used much, so we should be able to move them to the "Y" space
>> instead.
>> >> >> The patch below does this for "T" and "U". Then we could use "U"
>> >> >> for new, longer constraints.
>> >> >>
>> >> >>
>> >> >> U
>> >> >>
>> >> >> where is:
>> >> >>
>> >> >> s for signed
>> >> >> u for unsigned
>> >> >> d for decremented unsigned (-1 ... N)
>> >> >> i for incremented unsigned (1 ... N)
>> >> >>
>> >> >> where is:
>> >> >>
>> >> >> b for "byte" (*1)
>> >> >> h for "halfwords" (*2)
>> >> >> w for "words" (*4)
>> >> >> d for "doublewords" (*8) -- useful for 64-bit MIPS16 but probably not
>> >> >> needed for 32-bit microMIPS
>> >> >>
>> >> >> and where is the number of bits. and could
>> >> >> be replaced with an ad-hoc two-letter combination for special cases.
>> >> >> E.g. "Uas9" ("add stack") for ADDISUP.
>> >> >>
>> >> >> Just a suggestion though. I'm not saying these names are totally
>> >> >> intuitive or anything, but they should at least be better than
>> >> >> arbitrary
>> >> letters.
>> >> >>
>> >> >> Also, could be two digits if necessary, or we could just
>> >> >> use hex
>> >> digits.
>> >> >
>> >> > I extended this proposal a bit by:
>> >> > 1. Adding a e for encoded. The constraint will start with
>> >> > Ue, when the operand is an encoded value.
>> >> > 2. I decided to use two digits for .
>> >> > 3. The ad-hoc combination is used for anything else.
>> >>
>> >> First of all, thanks for coming up with a counter-suggestion. I'm
>> >> hopeless at naming things, so I was hoping there would be at least some
>> pushback.
>> >>
>> >> "e" for "encoded" sounds good. I'm less keen on the mixture of
>> >> single- and double-digit widths though (single digit for some "Ue"s,
>> >> double digits for other "U"s.) I think we should either:
>> >>
>> >> (a) use the same number of digits for all "U" constraints. That leaves
>> >> one character for the "Ue" type, which isn't as mnemonic, but is in
>> >> line with what we do elsewhere.
>> >>
>> >> (b) avoid digits in the "Ue" forms and just have an ad-hoc letter
>> combination.
>>
>> FWIW, as far as this point goes, the patch still has "Uea4".
>>
>> >> > +/* Return true if X is a legitimate address that conforms to the
>> >> requirements
>> >> > + for any of the short microMIPS LOAD or STORE instructions except
>> LWSP
>> >> > + or SWSP. */
>> >> > +
>> >> > +bool
>> >> > +umips_address_p (rtx x, bool load, enum machine_mode mode) {
>> >> > +
>> >> > + struct mips_address_info addr;
>> >> > + bool ok = mips_classify_address (&addr, x, mode, false)
>> >> > + && addr.type == ADDRESS_REG
>> >> > + && M16_REG_P (REGNO (addr.reg))
>> >> > + && CONST_INT_P (addr.offset);
>> >> > +
>> >> > + if (!ok)
>> >> > +return false;
>> >> > +
>> >> > + if (mips_unsigned_immediate_p (INTVAL (addr.offset), 4, 2)
>> >> > + || mips_unsigned_immediate_p (INTVAL (addr.offset), 4, 1))
>> >> > +return true;
>> >> > +
>> >> > + if (load && IN_RANGE (INTVAL (addr.offset), -1, 14))
>> >> > +return true;
>> >> > +
>> >> > + if (!load && IN_RANGE (INTVAL (addr.offset), 0, 15))
>> >> > +return true;
>> >> > +
>> >> > + return false;
>> >> > +
>> >> > +}
>> >>
>> >> No blank lines after "{" and before "}".
>> >>
>> >> More importantly, what cases are these range tests covering?
>> >> Both binutils and qemu seem to think that LW and SW need offsets that
>> >> exactly match:
>> >>
>> >> mips_unsigned_immediate_p (INTVAL (addr.offset), 4, 2)
>> >>
>> >
>> > Those range tests are for the LBU16 and SB16 instructions. LBU16
>> > supports offsets from -1 to 14 (encodes -1 as 15) while the SB16 insn
>> > supports offsets from 0-15.
>>
>> They need to use separate constraints in that case. The patch as written
>> allows -1 offsets for LW16 too. (In rare cases, offsets like -1 can be used
>> even
>> with aligned word loads.)
>>
>> E.g. we could have:
>>
>> /* Return true if X is legitimate for accessing values of mode MODE,
>>if it is based on a MIPS16 register, and if the offset satisfies
>>OFFSET_PREDICATE. */
>>
>> bool
>> m16_based_address_p (rtx x, enum machine_mode mode,
>> insn_operand_predicate_fn predicate) {
>> struct mips_address_info addr;
Re: [PATCH 2/4] Avoid non constant memory model uses in libatomic
On 03/16/2013 06:29 AM, Andi Kleen wrote: > 2013-03-15 Andi Kleen > > * gcas.c: (EXACT_INLINE): Use __ATOMIC_SEQ_CST. > * gexch.c: (EXACT_INLINE): Use __ATOMIC_SEQ_CST. > * gload.c: (EXACT_INLINE): Use __ATOMIC_SEQ_CST. > * gstore.c: (EXACT_INLINE): Use __ATOMIC_SEQ_CST. Ok. r~
Re: [PATCH 3/4] Avoid nonconst memmodels in libitm's local outdated copy of too
On 03/16/2013 06:29 AM, Andi Kleen wrote: > 2013-03-15 Andi Kleen > > * local_atomic (__always_inline): Add. > (__calculate_memory_order, atomic_thread_fence, >atomic_signal_fence, test_and_set, clear, store, load, > exchange, compare_exchange_weak, compare_exchange_strong, > fetch_add, fetch_sub, fetch_and, fetch_or, fetch_xor): > Add __always_inline to force inlining. Ok. One day we'll get the build fixed so this copy isn't necessary... r~
Re: [PATCH 4/4] Add warning for non-constant memory models
On 03/16/2013 06:29 AM, Andi Kleen wrote: > +"Non constant memory model: Assuming __ATOMIC_SEQ_CST"); Warnings and error messages are all lower case. Otherwise it seems... well, I didn't want to say "ok", but certainly "unavoidable". r~
Re: [RTL, i386] Use subreg instead of UNSPEC_CAST
On 03/19/2013 08:47 AM, Marc Glisse wrote: > (define_insn_and_split "avx__" >[(set (match_operand:AVX256MODE2P 0 "nonimmediate_operand" "=x,m") > - (unspec:AVX256MODE2P > - [(match_operand: 1 "nonimmediate_operand" "xm,x")] > - UNSPEC_CAST))] > + (subreg:AVX256MODE2P > + (match_operand: 1 "nonimmediate_operand" "xm,x") 0))] >"TARGET_AVX" >"#" >"&& reload_completed" >[(const_int 0)] I'm not fond of this, primarily because I believe the pattern should not exist at all. One of the following is true: (1) reload needs working around (thus all the reload_completed nonsense) or (2) the entire pattern is useless and would be subsumed by mov or (3) the entire pattern is useless and is *already* subsumed by mov, since mov is earlier in the md file, making this pattern dead code. r~
Re: [Patch, libfortran, 2nd version] PR 48618 - Negative unit number in OPEN(...) is sometimes allowed
On Tue, 19 Mar 2013 12:01:12 +0100, Tobias Burnus wrote: Am 07.03.2013 17:35, schrieb Tilo Schwarz: On Thu, 07 Mar 2013 12:46:10 +0100, Tobias Burnus wrote: Tilo Schwarz wrote: this patch fixes PR 48618. Built and regtested on Linux 3.2.0-4-686-pae. Thanks for the patch, which mostly looks okay. A few remarks: Thank you for the feedback. I incorporated all remarks into the new attached patch. The patch looks good and is okay for the 4.9 trunk. Thanks for your efforts! If you commit yourself, you need to recall to split the ChangeLog into the parts which go into libgfortran/ChangeLog and gcc/testsuite/ChangeLog. For the commit log, use "svn log|less" to see what others do for the commit log. If you want me to commit this (and the other) patch instead, please tell me. Yes, I'm glad if you commit the two patches. I'll set up the svn for future patches. Regards, Tilo
Re: [Patch, fortran] PR51976 - [F2003] Support deferred-length character components of derived types (allocatable string length)
Dear Paul, dear all,
On February 24, 2013 Paul Richard Thomas wrote:
The attached patch represents progress to date. It fixes the original
problem in this PR and allows John Reid's version of
iso_varying_string/vocabulary_word_count.f90 to compile and run
correctly. It even bootstraps and regtests!
Attached is a re-diffed patch; I have additionally fixed some indenting
issues.
Additionally, I have tested the patch - and it fails with
deferred-length *array* character components. See attached test case.
Also, the following line of the included test case leaks memory:
allocate (array(2), source = [t("abcedefg","hi"), t("jkl","mnop")])
I think at least the array bug should be fixed prior committal. (Fixing
the memory leak and some of the below-mentioned issues would be nice,
too.) Otherwise, I think the patch looks fine. For completeness, I have
some naming remarks, which I would also like to considered:
http://thread.gmane.org/gmane.comp.gcc.fortran/40393/focus=281580
Tobias
However, it doe not fix:
PR51976 comment #6 and PR51550 - allocate with typespec ICEs
PR51976 comment #6 FORALL assignment is messed up and ICEs..
PR47545 the compiler complains about the lack of an initializer for
the hidden character length field.
PR45170 will need going through from one end to the other - there is a
lot of "stuff" here!
Of these, I consider the fix of the PR47545 problem to be a must and
the allocate with typespec desirable.
type t
character(len=:), pointer :: p(:)
character(len=:), allocatable :: a(:)
end type t
type(T) :: x
character(len=5), target :: y(2)
y = ["abc","def"]
x%p => y
x%a = y
print '(">",a,"<")', x%p ! Doesn't print anything
print '(">",a,"<")', x%a ! Doesn't print anything
print '(">",a,"<")', x%p(1) ! Doesn't print anything
print '(">",a,"<")', x%p(2) ! Doesn't print anything
print '(">",a,"<")', x%a(1) ! Prints "def " (expected: "abc ")
print '(">",a,"<")', x%a(2) ! Prints "def " (okay)
end
2013-03-19 Paul Thomas gcc.gnu.org>
PR fortran/51976
* gfortran.h : Add deferred_parameter attribute.
* primary.c (build_actual_constructor): It is not an error if
a missing component has the deferred_parameter attribute;
equally, if one is given a value, it is an error.
* resolve.c (resolve_fl_derived0): Remove error for deferred
character length components. Add the hidden string length
field to the structure. Give it the deferred_parameter
attribute.
* trans-array.c (duplicate_allocatable): Add a strlen field
which is used as the element size if it is non-null.
(gfc_duplicate_allocatable, gfc_copy_allocatable_data): Pass a
NULL to the new argument in duplicate_allocatable.
(structure_alloc_comps): Set the hidden string length as
appropriate. Use it in calls to duplicate_allocatable.
(gfc_alloc_allocatable_for_assignment): When a deferred length
backend declaration is variable, use that; otherwise use the
string length from the expression evaluation.
* trans-expr.c (gfc_conv_component_ref): If this is a deferred
character length component, the string length should have the
value of the hidden string length field.
(gfc_trans_subcomponent_assign): Set the hidden string length
field for deferred character length components. Allocate the
necessary memory for the string.
(alloc_scalar_allocatable_for_assignment): Same change as in
gfc_alloc_allocatable_for_assignment above.
* trans-stmt.c (gfc_trans_allocate): Likewise.
* trans-types.c (gfc_get_derived_type): Set the tree type for
a deferred character length component.
* trans.c (gfc_deferred_strlen): New function.
* trans.h : Prototype for the new function.
2013-03-19 Paul Thomas gcc.gnu.org>
PR fortran/51976
* gfortran.dg/deferred_type_component_1.f90 : New test.
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index 76d2797..6956d33 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -811,6 +811,9 @@ typedef struct
/* Attributes set by compiler extensions (!GCC$ ATTRIBUTES). */
unsigned ext_attr:EXT_ATTR_NUM;
+ /* Is a parameter associated with a deferred type component. */
+ unsigned deferred_parameter:1;
+
/* The namespace where the attribute has been set. */
struct gfc_namespace *volatile_ns, *asynchronous_ns;
}
diff --git a/gcc/fortran/primary.c b/gcc/fortran/primary.c
index d149224..34a55b5 100644
--- a/gcc/fortran/primary.c
+++ b/gcc/fortran/primary.c
@@ -2349,7 +2349,7 @@ build_actual_constructor (gfc_structure_ctor_component **comp_head,
}
/* If it was not found, try the default initializer if there's any;
- otherwise, it's an error. */
+ otherwise, it's an error unless this is a deferred parameter. */
if (!comp_iter)
{
if (comp->initializer)
@@ -2360,7 +2360,7 @@ build_actual_constructor (gfc_structure_ctor_component **comp_head,
return FAILURE;
value = gfc_copy_expr (comp->initializer);
}
- else
+ else if (!comp->attr.deferred_parameter)
{
gfc_error ("No initiali
Re: FW: [PATCH] [MIPS] microMIPS gcc support
"Moore, Catherine" writes:
>> >> -Original Message-
>> >> From: Richard Sandiford [mailto:rdsandif...@googlemail.com]
>> >> Sent: Tuesday, March 05, 2013 4:06 PM
>> >> To: Moore, Catherine
>> >> Cc: gcc-patches@gcc.gnu.org; Rozycki, Maciej
>> >> Subject: Re: FW: [PATCH] [MIPS] microMIPS gcc support:
>> >>
>> >> We have a few internal-only undocumented constraints that aren't used
>> >> much, so we should be able to move them to the "Y" space instead.
>> >> The patch below does this for "T" and "U". Then we could use "U" for
>> >> new, longer constraints.
>> >>
>> >>
>> >> U
>> >>
>> >> where is:
>> >>
>> >> s for signed
>> >> u for unsigned
>> >> d for decremented unsigned (-1 ... N)
>> >> i for incremented unsigned (1 ... N)
>> >>
>> >> where is:
>> >>
>> >> b for "byte" (*1)
>> >> h for "halfwords" (*2)
>> >> w for "words" (*4)
>> >> d for "doublewords" (*8) -- useful for 64-bit MIPS16 but probably not
>> >> needed for 32-bit microMIPS
>> >>
>> >> and where is the number of bits. and could be
>> >> replaced with an ad-hoc two-letter combination for special cases.
>> >> E.g. "Uas9" ("add stack") for ADDISUP.
>> >>
>> >> Just a suggestion though. I'm not saying these names are totally
>> >> intuitive or anything, but they should at least be better than arbitrary
>> letters.
>> >>
>> >> Also, could be two digits if necessary, or we could just use hex
>> digits.
>> >
>> > I extended this proposal a bit by:
>> > 1. Adding a e for encoded. The constraint will start with Ue,
>> > when the operand is an encoded value.
>> > 2. I decided to use two digits for .
>> > 3. The ad-hoc combination is used for anything else.
>>
>> First of all, thanks for coming up with a counter-suggestion. I'm hopeless
>> at
>> naming things, so I was hoping there would be at least some pushback.
>>
>> "e" for "encoded" sounds good. I'm less keen on the mixture of single- and
>> double-digit widths though (single digit for some "Ue"s, double digits for
>> other "U"s.) I think we should either:
>>
>> (a) use the same number of digits for all "U" constraints. That leaves
>> one character for the "Ue" type, which isn't as mnemonic, but is in
>> line with what we do elsewhere.
>>
>> (b) avoid digits in the "Ue" forms and just have an ad-hoc letter
>> combination.
FWIW, as far as this point goes, the patch still has "Uea4".
>> > +/* Return true if X is a legitimate address that conforms to the
>> requirements
>> > + for any of the short microMIPS LOAD or STORE instructions except LWSP
>> > + or SWSP. */
>> > +
>> > +bool
>> > +umips_address_p (rtx x, bool load, enum machine_mode mode) {
>> > +
>> > + struct mips_address_info addr;
>> > + bool ok = mips_classify_address (&addr, x, mode, false)
>> > + && addr.type == ADDRESS_REG
>> > + && M16_REG_P (REGNO (addr.reg))
>> > + && CONST_INT_P (addr.offset);
>> > +
>> > + if (!ok)
>> > +return false;
>> > +
>> > + if (mips_unsigned_immediate_p (INTVAL (addr.offset), 4, 2)
>> > + || mips_unsigned_immediate_p (INTVAL (addr.offset), 4, 1))
>> > +return true;
>> > +
>> > + if (load && IN_RANGE (INTVAL (addr.offset), -1, 14))
>> > +return true;
>> > +
>> > + if (!load && IN_RANGE (INTVAL (addr.offset), 0, 15))
>> > +return true;
>> > +
>> > + return false;
>> > +
>> > +}
>>
>> No blank lines after "{" and before "}".
>>
>> More importantly, what cases are these range tests covering?
>> Both binutils and qemu seem to think that LW and SW need offsets that
>> exactly match:
>>
>> mips_unsigned_immediate_p (INTVAL (addr.offset), 4, 2)
>>
>
> Those range tests are for the LBU16 and SB16 instructions. LBU16
> supports offsets from -1 to 14 (encodes -1 as 15) while the SB16 insn
> supports offsets from 0-15.
They need to use separate constraints in that case. The patch as written
allows -1 offsets for LW16 too. (In rare cases, offsets like -1 can be
used even with aligned word loads.)
E.g. we could have:
/* Return true if X is legitimate for accessing values of mode MODE,
if it is based on a MIPS16 register, and if the offset satisfies
OFFSET_PREDICATE. */
bool
m16_based_address_p (rtx x, enum machine_mode mode,
insn_operand_predicate_fn predicate)
{
struct mips_address_info addr;
return (mips_classify_address (&addr, x, mode, false)
&& addr.type == ADDRESS_REG
&& M16_REG_P (REGNO (addr.reg))
&& offset_predicate (addr.offset));
}
Perhaps if there are so many of these, we should define "T???" to be
a memory constraint in which the base register is an M16_REG and in
which "???" has the same format as for "U". E.g. "Tuw4" for LW and SW.
That's just a suggestion though.
Thanks,
Richard
Re: [PATCH RFC] Finer grained reg classes.
On Tue, Mar 19, 2013 at 7:31 PM, Jeff Law wrote: > On 03/19/2013 11:58 AM, Ian Lance Taylor wrote: >> >> On Tue, Mar 19, 2013 at 8:33 AM, David Miller wrote: >>> >>> >>> So this patch tries to rework the semantics of hard register classes, >>> such that if a hard register is present in the set it is implied that >>> the rest of the registers in a multi-register group are present as >>> well. So we can add a register class called EVEN_REGS and only have >>> to set the even register bits. >> >> >> I haven't really looked at your patch, but I just want to say that I >> think this is the right way to go. > > Likewise. I've certainly worked on ports where this would have been helpful > in the past. It could also help simplify existing ports. rs6000 has a few places where this could be useful (dfp). At least arm (VFP_REGNO_OK_FOR_DOUBLE), avr, and h8300, too. And ISTR s390 plays funny subreg tricks to get this right. Finally, it's been discussed on the gcc@ mailing list for out-of-tree ports a few times in recent history. So yes, great if this can be done! Ciao! Steven
[Ada, RFC patch] Fortran Interface: Update comment, add some of the Star/Kind type definitions
This patch updates one comment regarding "logical": * The Fortran standard requires that (default-kind) "logical" and "integer" have the same size; that's generally the case, i.e. also for arrays or in structures (derived types) * Fortran does not use zero/nonzero semantics but only .true. and .false. However, the standard does not specify the value of .true. and .false. While .false. seems to be universally 0, I have seen .true. being 1 (majority of compilers) and -1 (few compilers, but one popular among them). GCC's gfortran uses 0 and 1 - and will give wrong code with a "-1" .true. (when ".not." is applied to it, it will become -2, which is also regarded as ".true."). Hence, for GCC/gfortran interop, the semantic matches gnat's; but for wider compatibility, keeping the nonzero/zero semantics is reasonable. In addition, Ada 2012 allows optionally to define types for Fortran's "real*8" and "integer(kind=2)". The former syntax is not permitted by any Fortran standard but an extremely common vendor extension, effectively supported by all compilers. The second one is standard conform since Fortran 90; however, the value (here "2") is not defined by the standard. By far most compilers use the byte size for that value. I know of one compiler, which doesn't by default (only with -kind=byte). Thus, that addition should be interop with effectively all compilers. See Fortran interop appendix B.5 to Ada 2012. Quickest link to the standard: Look at the attachment of the email http://mailman.j3-fortran.org/pipermail/j3/2013-February/006162.html – or in the standard itself (also linked from that email). I would like if some of the Ada/GNAT experts could have a look - as this is really my first look at Ada code. Tobias 2013-03-19 Tobias Burnus * i-fortra.ads: Update comment, add Ada 2012's optional Star and Kind data types for enhanced interoperability. diff --git a/gcc/ada/i-fortra.ads b/gcc/ada/i-fortra.ads index 992eb28..270c819 100644 --- a/gcc/ada/i-fortra.ads +++ b/gcc/ada/i-fortra.ads @@ -26,11 +26,11 @@ package Interfaces.Fortran is type Logical is new Boolean; for Logical'Size use Integer'Size; pragma Convention (Fortran, Logical); - -- As required by Fortran standard, stand alone logical allocates same - -- space as integer (but what about the array case???). The convention - -- is important, since in Fortran, Booleans have zero/non-zero semantics - -- for False/True, and the pragma Convention (Fortran) activates the - -- special handling required in this case. + -- As required by Fortran standard, logical allocates same space as + -- an integer. The convention is important, since in Fortran, Booleans + -- are implemented with zero/non-zero semantics for False/True, and the + -- pragma Convention (Fortran) activates the special handling required + -- in this case. package Single_Precision_Complex_Types is new Ada.Numerics.Generic_Complex_Types (Real); @@ -50,6 +50,53 @@ package Interfaces.Fortran is type Fortran_Character is array (Positive range <>) of Character_Set; + -- Additional declarations as permitted by Ada 2012, p.608, paragraph 21. + -- Interoperability with Fortran 77's vendor extension using star + -- notation and Fortran 90's intrinsic types with kind=n parameter. + -- The following assumes that `n' matches the byte size, which + -- most Fortran compiler, including GCC's follow. + + type Integer_Star_1 is new Integer_8; + type Integer_Kind_1 is new Integer_8; + type Integer_Star_2 is new Integer_16; + type Integer_Kind_2 is new Integer_16; + type Integer_Star_4 is new Integer_32; + type Integer_Kind_4 is new Integer_32; + type Integer_Star_8 is new Integer_64; + type Integer_Kind_8 is new Integer_64; + + type Logical_Star_1 is new Boolean; + type Logical_Star_2 is new Boolean; + type Logical_Star_4 is new Boolean; + type Logical_Star_8 is new Boolean; + for Logical_Star_1'Size use Integer_8'Size; + for Logical_Star_2'Size use Integer_16'Size; + for Logical_Star_4'Size use Integer_32'Size; + for Logical_Star_8'Size use Integer_64'Size; + pragma Convention (Fortran, Logical_Star_1); + pragma Convention (Fortran, Logical_Star_2); + pragma Convention (Fortran, Logical_Star_4); + pragma Convention (Fortran, Logical_Star_8); + + type Logical_Kind_1 is new Logical_Star_1; + type Logical_Kind_2 is new Logical_Star_2; + type Logical_Kind_4 is new Logical_Star_4; + type Logical_Kind_8 is new Logical_Star_8; + + type Real_Star_4 is new Float; + type Real_Kind_4 is new Float; + type Real_Star_8 is new Long_Float; + type Real_Kind_8 is new Long_Float; + + -- In the kind syntax, n is the same as the associated real kind. + -- In the star syntax, n is twice as large (real+imaginary size) + type Complex_Star_8 is new Complex; + type Complex_Kind_4 is new Complex; + type Complex_Star_16 is new Double_Complex;
[PATCH 3/n, i386]: Slightly improve and fix {TF,DF,SF,TI,DI,SI}mode move patterns
Hello!
Attached patch slightly improves {TF,DF,SF,TI,DI,SI}mode move patterns
by calculating various attributes in a more clear way, the patch
reorders operand alternatives to avoid checks for interleaved
"alternatives" and implements various other janitorial improvements.
In addition, the patch fixes wrong declaration of type attribute for
alternatives 3,4 of SFmode pattern and adds missing prefix_data16
calculations in SFmode and DFmode patterns.
The later fixes will be backported to other branches, after 4.8.0 is released.
2013-03-19 Uros Bizjak
* config/i386/i386.md (*movti_internal): Set prefix attribute to
maybe_vex for sselog1 and ssemov types.
(*movdi_internal): Reorder operand constraints.
(*movsi_internal): Ditto. Set prefix attribute to
maybe_vex for sselog1 and ssemov types.
(*movtf_internal): Set prefix attribute to maybe_vex
for sselog1 and ssemov types.
(*movdf_internal): Ditto. Set prefix_data16 attribute for
DImode ssemov types. Reorder operand constraints.
(*movsf_internal): Set type of alternatives 3,4 to imov. Set prefix
attribute to maybe_vex for sselog1 and ssemov types. Set prefix_data16
attribute for SImode ssemov types. Reorder operand constraints.
Tested on x86_64-pc-linux-gnu {,-m32}. Will be committed to mainline
SVN once servers come into operating order.
Uros.
Index: i386.md
===
--- i386.md (revision 196784)
+++ i386.md (working copy)
@@ -1832,7 +1832,10 @@
}
[(set_attr "isa" "x64,x64,*,*,*")
(set_attr "type" "*,*,sselog1,ssemov,ssemov")
- (set_attr "prefix" "*,*,maybe_vex,maybe_vex,maybe_vex")
+ (set (attr "prefix")
+ (if_then_else (eq_attr "type" "sselog1,ssemov")
+ (const_string "maybe_vex")
+ (const_string "orig")))
(set (attr "mode")
(cond [(eq_attr "alternative" "0,1")
(const_string "DI")
@@ -1859,9 +1862,9 @@
(define_insn "*movdi_internal"
[(set (match_operand:DI 0 "nonimmediate_operand"
-"=r ,o ,r,r ,r,m ,*y,m*y,*y,?*y,?r ,?*Ym,*x,m ,*x,*x,?r ,?*Yi,?*x,?*Ym")
+"=r ,o ,r,r ,r,m ,*y,m*y,*y,?*y,?r ,?*Ym,*x,*x,*x,m ,?r ,?*Yi,?*x,?*Ym")
(match_operand:DI 1 "general_operand"
-"riFo,riF,Z,rem,i,re,C ,*y ,m ,m ,*Ym,r ,C ,*x,*x,m ,*Yi,r ,*Ym,*x"))]
+"riFo,riF,Z,rem,i,re,C ,*y ,m ,m ,*Ym,r ,C ,*x,m ,*x,*Yi,r ,*Ym,*x"))]
"!(MEM_P (operands[0]) && MEM_P (operands[1]))"
{
switch (get_attr_type (insn))
@@ -1970,7 +1973,7 @@
(set (attr "mode")
(cond [(eq_attr "alternative" "2")
(const_string "SI")
- (eq_attr "alternative" "12,14")
+ (eq_attr "alternative" "12,13")
(cond [(ior (not (match_test "TARGET_SSE2"))
(match_test "TARGET_SSE_PACKED_SINGLE_INSN_OPTIMAL"))
(const_string "V4SF")
@@ -1981,7 +1984,7 @@
]
(const_string "TI"))
- (and (eq_attr "alternative" "13,15")
+ (and (eq_attr "alternative" "14,15")
(not (match_test "TARGET_SSE2")))
(const_string "V2SF")
]
@@ -1998,9 +2001,9 @@
(define_insn "*movsi_internal"
[(set (match_operand:SI 0 "nonimmediate_operand"
- "=r,m ,*y,*y,?rm,?*y,*x,*x,?r ,m ,?*Yi,*x")
+ "=r,m ,*y,*y,?rm,?*y,*x,*x,*x,m ,?r ,?*Yi")
(match_operand:SI 1 "general_operand"
- "g ,re,C ,*y,*y ,rm ,C ,*x,*Yi,*x,r ,m"))]
+ "g ,re,C ,*y,*y ,rm ,C ,*x,m ,*x,*Yi,r"))]
"!(MEM_P (operands[0]) && MEM_P (operands[1]))"
{
switch (get_attr_type (insn))
@@ -2056,9 +2059,9 @@
]
(const_string "imov")))
(set (attr "prefix")
- (if_then_else (eq_attr "alternative" "0,1,2,3,4,5")
- (const_string "orig")
- (const_string "maybe_vex")))
+ (if_then_else (eq_attr "type" "sselog1,ssemov")
+ (const_string "maybe_vex")
+ (const_string "orig")))
(set (attr "prefix_data16")
(if_then_else (and (eq_attr "type" "ssemov") (eq_attr "mode" "SI"))
(const_string "1")
@@ -2067,17 +2070,17 @@
(cond [(eq_attr "alternative" "2,3")
(const_string "DI")
(eq_attr "alternative" "6,7")
- (cond [(match_test "TARGET_SSE_PACKED_SINGLE_INSN_OPTIMAL")
+ (cond [(ior (not (match_test "TARGET_SSE2"))
+ (match_test "TARGET_SSE_PACKED_SINGLE_INSN_OPTIMAL"))
(const_string "V4SF")
(match_test "TARGET_AVX")
(const_string "TI")
-(ior (not (match_test "TARGET_SSE2"))
- (match_test "optimize_function_for_size_p (cfun)"))
+(match_test "optimize_function_for_size_p (cfun)")
(const_string "V4SF")
Re: [PATCH RFC] Finer grained reg classes.
On 03/19/2013 11:58 AM, Ian Lance Taylor wrote: On Tue, Mar 19, 2013 at 8:33 AM, David Miller wrote: So this patch tries to rework the semantics of hard register classes, such that if a hard register is present in the set it is implied that the rest of the registers in a multi-register group are present as well. So we can add a register class called EVEN_REGS and only have to set the even register bits. I haven't really looked at your patch, but I just want to say that I think this is the right way to go. Likewise. I've certainly worked on ports where this would have been helpful in the past. Jeff
Re: C++ PATCH for c++/54277 (wrong cv-quals in lambda)
On 13-03-16 10:40 PM, Jason Merrill wrote:
On 03/16/2013 03:28 PM, Jason Merrill wrote:
I have no idea why the existing code tried to deduce the desired quals
from current_class_ref rather than just look at the object it has.
Well, maybe now I do; when I tested all my changes again before checking
in, this one caused a crash because I had left out another change that
it depends on. Previously we gave the 'this' capture in a lambda a
DECLTYPE_TYPE type since the enclosing class is a dependent type, but
that means that *this has no type at all and so we can't look at its
quals. But that isn't necessary; we know enough about the type of
'this' that it's a pointer to some instantiation of this class template,
so we can give the capture field and proxy that type rather than mess
with DECLTYPE_TYPE. We could limit this change to only POINTER_TYPE,
but we might as well save a bit of memory and only use the DECLTYPE_TYPE
when we really don't know anything about the type being captured;
specifically, when we don't know whether or not it's a reference.
Tested x86_64-pc-linux-gnu, applying to trunk.
Hi Jason,
It seems this change introduced the following segfault building
compatibility-thread-c++0x.cc for an arm eabi target.
ice.ii:48:20: internal compiler error: Segmentation fault
(__args) ...);
^
0xa7b67f crash_signal
../../gcc/toplev.c:332
0x4e98e2 resolve_args
../../gcc/cp/call.c:3739
0x5022d7 build_new_function_call(tree_node*, vecvl_embed>**, bool, int)
../../gcc/cp/call.c:3849
0x66dc42 finish_call_expr(tree_node*, vecvl_embed>**, bool, bool, int)
../../gcc/cp/semantics.c:2214
Attached is a reduced testcase. Sorry, for reporting it on gcc-patches
but bugzilla is currently offline.
Regards,
Ryan Mansfield
namespace std __attribute__ ((__visibility__ ("default")))
{
template < typename _Tp > struct remove_reference
{
typedef _Tp type;
};
template < typename _Tp > constexpr _Tp
&& forward (typename std::remove_reference < _Tp >::type & __t) noexcept
{
return static_cast < _Tp && >(__t);
}
template < typename _Res, typename _T1,
typename _T2 >
struct _Reference_wrapper_base <_Res (_T1::*) (_T2) const volatile
>:binary_function < const volatile _T1 *, _T2, _Res >
{
};
template < typename _Tp > class reference_wrapper:public
_Reference_wrapper_base < typename remove_cv <
_Tp >::type >
{
};
template < typename _Tp > inline reference_wrapper < _Tp >
ref (_Tp & __t) noexcept
{
}
template < typename _Signature > struct _Bind_simple;
template < typename _Func, typename ... _BoundArgs > struct
_Bind_simple_helper
{
typedef _Bind_simple < __func_type (typename decay <
_BoundArgs >::type ...) > __type;
};
template < typename _Callable,
typename ... _Args > typename _Bind_simple_helper < _Callable,
_Args ... >::__type __bind_simple (_Callable && __callable, _Args
&& ... __args)
{
}
template < typename _Signature > class function;
struct once_flag
{
};
template < typename _Callable,
typename ... _Args > void call_once (once_flag & __once, _Callable
&& __f, _Args && ... __args)
{
auto __callable = std::__bind_simple (std::forward < _Callable > (__f),
std::forward < _Args >
(__args) ...);
__once_functor =[&]()
{
__callable ();
};
}
class _State_base
{
once_flag _M_once;
void _M_set_result (function < _Ptr_type () > __res,
bool __ignore_failure = false)
{
bool __set = __ignore_failure;
call_once (_M_once, &_State_base::_M_do_set, this, ref (__res),
ref (__set));
}
private:void _M_do_set (function < _Ptr_type () > &__f, bool & __set)
{
}
}
}
Re: [gomp 4.0] Handle OMP_DISPLAY_ENV
On Tue, Mar 19, 2013 at 07:05:12PM +0100, Tobias Burnus wrote: > I assume, you will create the gomp-4_0-branch when gcc.gnu.org is > fully operational. Additionally, I presume, the change-log > information should go to the file ChangeLog.gomp and not to > ChangeLog. Yes and yes. > 2013-03-19 Tobias Burnus > > * env.c (handle_omp_display_env): New function. > (initialize_env): Use it. Ok, thanks. Jakub
Re: [gomp 4.0] Handle OMP_DISPLAY_ENV
Jakub Jelinek wrote:
+#include
+#include /* For PRIu64. */
stdio.h is fine, but inttypes.h needs to be
#ifdef HAVE_INTTYPES_H
# include
#endif
for portability (libgomp/configure already checks for that).
Good point. Attached the updated patch.
I assume, you will create the gomp-4_0-branch when gcc.gnu.org is fully
operational. Additionally, I presume, the change-log information should
go to the file ChangeLog.gomp and not to ChangeLog.
Tobias
2013-03-19 Tobias Burnus
* env.c (handle_omp_display_env): New function.
(initialize_env): Use it.
diff --git a/libgomp/env.c b/libgomp/env.c
index 65cbba8..5cd1164 100644
--- a/libgomp/env.c
+++ b/libgomp/env.c
@@ -29,6 +29,10 @@
#include "libgomp_f.h"
#include
#include
+#include
+#ifdef HAVE_INTTYPES_H
+# include /* For PRIu64. */
+#endif
#ifdef STRING_WITH_STRINGS
# include
# include
@@ -565,6 +569,122 @@ parse_affinity (void)
return false;
}
+
+static void
+handle_omp_display_env (bool proc_bind, unsigned long stacksize,
+ int wait_policy)
+{
+ const char *env;
+ bool display = false;
+ bool verbose = false;
+ int i;
+
+ env = getenv ("OMP_DISPLAY_ENV");
+ if (env == NULL)
+return;
+
+ while (isspace ((unsigned char) *env))
+++env;
+ if (strncasecmp (env, "true", 4) == 0)
+{
+ env += 4;
+}
+ else if (strncasecmp (env, "false", 5) == 0)
+{
+ display = false;
+ env += 5;
+}
+ else if (strncasecmp (env, "verbose", 7) == 0)
+{
+ display = true;
+ verbose = true;
+ env += 7;
+}
+ else
+env = "X";
+ while (isspace ((unsigned char) *env))
+++env;
+ if (*env != '\0')
+gomp_error ("Invalid value for environment variable OMP_DISPLAY_ENV");
+
+ if (!display)
+return;
+
+ fputs ("\nOPENMP DISPLAY ENVIRONMENT BEGIN\n", stderr);
+
+ fputs (" _OPENMP = '201107'\n", stderr);
+ fprintf (stderr, " OMP_DYNAMIC = '%s'\n",
+ gomp_global_icv.dyn_var ? "TRUE" : "FALSE");
+ fprintf (stderr, " OMP_NESTED = '%s'\n",
+ gomp_global_icv.nest_var ? "TRUE" : "FALSE");
+
+ fprintf (stderr, " OMP_NUM_THREADS = '%lu", gomp_global_icv.nthreads_var);
+ for (i = 1; i < gomp_nthreads_var_list_len; i++)
+fprintf (stderr, ",%lu", gomp_nthreads_var_list[i]);
+ fputs ("'\n", stderr);
+
+ fprintf (stderr, " OMP_SCHEDULE = '");
+ switch (gomp_global_icv.run_sched_var)
+{
+case GFS_RUNTIME:
+ fputs ("RUNTIME", stderr);
+ break;
+case GFS_STATIC:
+ fputs ("STATIC", stderr);
+ break;
+case GFS_DYNAMIC:
+ fputs ("DYNAMIC", stderr);
+ break;
+case GFS_GUIDED:
+ fputs ("GUIDED", stderr);
+ break;
+case GFS_AUTO:
+ fputs ("AUTO", stderr);
+ break;
+}
+ fputs ("'\n", stderr);
+
+ fprintf (stderr, " OMP_PROC_BIND = '%s'\n",
+ proc_bind ? "TRUE" : "FALSE");
+ fprintf (stderr, " OMP_STACKSIZE = '%lu'\n", stacksize);
+
+ /* GOMP's default value is actually neither active nor passive. */
+ fprintf (stderr, " OMP_WAIT_POLICY = '%s'\n",
+ wait_policy > 0 ? "ACTIVE" : "PASSIVE");
+ fprintf (stderr, " OMP_THREAD_LIMIT = '%lu'\n",
+ gomp_thread_limit_var);
+ fprintf (stderr, " OMP_MAX_ACTIVE_LEVELS = '%lu'\n",
+ gomp_max_active_levels_var);
+
+/* FIXME: Unimplemented OpenMP 4.0 environment variables.
+ fprintf (stderr, " OMP_PLACES = ''\n");
+ fprintf (stderr, " OMP_CANCELLATION = ''\n");
+ fprintf (stderr, " OMP_DEFAULT_DEVICE = ''\n"); */
+
+ if (verbose)
+{
+ fputs (" GOMP_CPU_AFFINITY = '", stderr);
+ if (gomp_cpu_affinity_len)
+ {
+ fprintf (stderr, "%d", gomp_cpu_affinity[0]);
+ for (i = 1; i < gomp_cpu_affinity_len; i++)
+ fprintf (stderr, " %d", gomp_cpu_affinity[i]);
+ }
+ fputs ("'\n", stderr);
+ fprintf (stderr, " GOMP_STACKSIZE = '%lu'\n", stacksize);
+#ifdef HAVE_INTTYPES_H
+ fprintf (stderr, " GOMP_SPINCOUNT = '%"PRIu64"'\n",
+ (uint64_t) gomp_spin_count_var);
+#else
+ fprintf (stderr, " GOMP_SPINCOUNT = '%lu'\n",
+ (unsigned long) gomp_spin_count_var);
+#endif
+}
+
+ fputs ("OPENMP DISPLAY ENVIRONMENT END\n", stderr);
+}
+
+
static void __attribute__((constructor))
initialize_env (void)
{
@@ -645,6 +765,8 @@ initialize_env (void)
if (err != 0)
gomp_error ("Stack size change failed: %s", strerror (err));
}
+
+ handle_omp_display_env (bind_var, stacksize, wait_policy);
}
Re: [PATCH RFC] Finer grained reg classes.
On Tue, Mar 19, 2013 at 8:33 AM, David Miller wrote: > > So this patch tries to rework the semantics of hard register classes, > such that if a hard register is present in the set it is implied that > the rest of the registers in a multi-register group are present as > well. So we can add a register class called EVEN_REGS and only have > to set the even register bits. I haven't really looked at your patch, but I just want to say that I think this is the right way to go. Ian
Re: [PATCH 1/4] Mark all member functions with memory models always inline
On Tue, Mar 19, 2013 at 05:10:22PM +0100, Jakub Jelinek wrote: > On Tue, Mar 19, 2013 at 08:51:21AM -0700, Andi Kleen wrote: > > > Using __always_inline as the name of the macro is a bad idea, glibc > > > headers use that macro already. Just use something else in public headers > > > that aren't part of glibc. > > > > That's why I had the ifdef, but ok. I'll use __force_inline then. > > I'd say Jonathan's _GLIBCXX_ALWAYS_INLINE would be better. > > BTW, have you verified always_inline works fine for -O0? I did some simple tests and it seemed to work. But thanks for the counter example. > > with -O0 -mhle doesn't result in xacquire, guess for !optimize > get_memmodel would need to look through chain of SSA_NAMEs if SSA_NAME > (that can appear because of inlining), looking for INTEGER_CSTs. interesting. so need more fixes. i'll look into that. Is there already a convenient helper for it? There was an alternative approach of using a template, but I suppose that would have the same problem. -Andi
Re: [Patch, fortran, 4.9] Use bool type instead gfc_try
Am 19.03.2013 13:15, schrieb Janne Blomqvist: now that the Fortran frontend is C++ we can use the primitive bool type instead of inventing our own. Well, C99's "bool" (_Bool) was already used before. The advantage of FAILURE and SUCCESS is that they immediately make clear whether some call was successful or not. "true" and "false" don't. Thus, one should consider whether some procedures should be renamed to make clear that true is successful and false is not. For instance, if (gfc_notify_standard (...) == FAILURE) return MATCH_ERROR; becomes with your patch: if (gfc_notify_standard (...) == false) return MATCH_ERROR; I think a more logical expression would be if (gfc_notify_standard (...)) return MATCH_ERROR; which removes the "== false" but also swaps true/false for the return value. There are probably some more cases. Without such a clean up, I fear that the code will become less readable than it is currently. While I think such changes can be done as follow up, I think committing the gfc_try -> bool patch only makes sense if you commit yourself to do such a cleanup. Tobias PS: Generally, please wait with committals until GCC's web mail archive works again for gcc-cvs. That will hopefully be soon. 2013-03-19 Janne Blomqvist * gfortran.h: Remove enum gfc_try, replace gfc_try with bool type. * arith.c: Replace gfc_try with bool type. * array.c: Likewise. * check.c: Likewise. * class.c: Likewise. * cpp.c: Likewise. * cpp.h: Likewise. * data.c: Likewise. * data.h: Likewise. * decl.c: Likewise. * error.c: Likewise. * expr.c: Likewise. * f95-lang.c: Likewise. * interface.c: Likewise. * intrinsic.c: Likewise. * intrinsic.h: Likewise. * io.c: Likewise. * match.c: Likewise. * match.h: Likewise. * module.c: Likewise. * openmp.c: Likewise. * parse.c: Likewise. * parse.h: Likewise. * primary.c: Likewise. * resolve.c: Likewise. * scanner.c: Likewise. * simplify.c: Likewise. * symbol.c: Likewise. * trans-intrinsic.c: Likewise. * trans-openmp.c: Likewise. * trans-stmt.c: Likewise. * trans-types.c: Likewise.
Re: [gomp 4.0] Handle OMP_DISPLAY_ENV
On Tue, Mar 19, 2013 at 04:24:04PM +0100, Tobias Burnus wrote: > 2013-03-19 Tobias Burnus > > * env.c (handle_omp_display_env): New function. > (initialize_env): Use it. > > diff --git a/libgomp/env.c b/libgomp/env.c > index 65cbba8..e228bd9 100644 > --- a/libgomp/env.c > +++ b/libgomp/env.c > @@ -29,6 +29,8 @@ > #include "libgomp_f.h" > #include > #include > +#include > +#include /* For PRIu64. */ stdio.h is fine, but inttypes.h needs to be #ifdef HAVE_INTTYPES_H # include #endif for portability (libgomp/configure already checks for that). Guess this then needs to be guarded with #ifdef HAVE_INTTYPES_H > + fprintf (stderr, " GOMP_SPINCOUNT = '%"PRIu64"'\n", > +(uint64_t) gomp_spin_count_var); and if not defined, use %ld with (unsigned long) cast instead. Jakub
Re: [testsuite] Don't XFAIL gfortran.dg/do_1.f90 (PR fortran/54932)
Rainer Orth wrote: As discussed in PR fortran/54932, the gfortran.dg/do_1.f90 execution tests recently stated to XPASS at all optimization levels, adding lots of testsuite noise. The following patch removes the xfail, allowing all tests to pass. Tested with the appropriate runtest invocations on x86_64-unknown-linux-gnu, i386-pc-solaris2.11, and sparc-sun-solaris2.11. Ok for mainline and 4.8 branch? Removing the xfail is okay. However, I wonder whether it would be better to leave a reference to the PR in case the failure pops up again. As the code is ill-defined, the failures might pop up in the future and the reference can help with analysis. OK - as is or with an updated reference to the PR. – For the branch, it is the RMs' call when it can be committed. Please wait with the committal until GCC's web mail archive works again for gcc-cvs. Thanks! Tobias 2013-03-19 Rainer Orth PR fortran/54932 * gfortran.dg/do_1.f90: Don't xfail.
[RTL] Canonicalize commutative operations more
Hello,
as explained in the PR, the goal of this patch is to have a more canonical
form for RTL expressions, so it is easier to model them with a small
number of patterns.
This patch passes bootstrap+testsuite on x86_64-linux-gnu. Using the
opposite arbitrary order in compare_commutative_operands_precedence
(exchange x and y in the line with GET_CODE) passes as well. The
simplify-rtx bit is because I get an infinite recursion otherwise.
Surprisingly, that infinite recursion occurs only in var-tracking, and
only for a single file in bootstrap+testsuite (not the same one depending
on the arbitrary order). I am not sure that is the best place to break the
recursion, but it seems to work.
I don't really expect the patch to be accepted as is, but it seems good
enough to start the conversation.
2013-03-19 Marc Glisse
PR rtl-optimization/55611
* rtl.h (commutative_operand_precedence): Remove.
(compare_commutative_operands_precedence): Declare.
* optabs.c (swap_commutative_operands_with_target): Use
compare_commutative_operands_precedence.
* simplify-rtx.c (simplify_associative_operation): Break the
recursion cycle.
(simplify_plus_minus_op_data_cmp): Use
compare_commutative_operands_precedence.
* rtlanal.c (commutative_operand_precedence): Make static.
(compare_commutative_operands_precedence): New function.
(swap_commutative_operands_p): Use it.
--
Marc GlisseIndex: rtlanal.c
===
--- rtlanal.c (revision 196633)
+++ rtlanal.c (working copy)
@@ -3076,21 +3076,21 @@ regno_use_in (unsigned int regno, rtx x)
return NULL_RTX;
}
/* Return a value indicating whether OP, an operand of a commutative
operation, is preferred as the first or second operand. The higher
the value, the stronger the preference for being the first operand.
We use negative values to indicate a preference for the first operand
and positive values for the second operand. */
-int
+static int
commutative_operand_precedence (rtx op)
{
enum rtx_code code = GET_CODE (op);
/* Constants always come the second operand. Prefer "nice" constants. */
if (code == CONST_INT)
return -8;
if (code == CONST_DOUBLE)
return -7;
if (code == CONST_FIXED)
@@ -3138,28 +3138,43 @@ commutative_operand_precedence (rtx op)
case RTX_UNARY:
/* Then prefer NEG and NOT. */
if (code == NEG || code == NOT)
return 1;
default:
return 0;
}
}
+/* Return < 0 if it is necessary to swap operands of commutative operation
+ in order to canonicalize expression, > 0 if it is wrong to swap the
+ operands, and 0 if we don't know. */
+
+int
+compare_commutative_operands_precedence (rtx x, rtx y)
+{
+ int px = commutative_operand_precedence (x);
+ int py = commutative_operand_precedence (y);
+ if (px != py)
+return px - py;
+
+ /* Use some arbitrary order to avoid pattern explosion. */
+ return (int) GET_CODE (x) - (int) GET_CODE (y);
+}
+
/* Return 1 iff it is necessary to swap operands of commutative operation
in order to canonicalize expression. */
bool
swap_commutative_operands_p (rtx x, rtx y)
{
- return (commutative_operand_precedence (x)
- < commutative_operand_precedence (y));
+ return compare_commutative_operands_precedence (x, y) < 0;
}
/* Return 1 if X is an autoincrement side effect and the register is
not the stack pointer. */
int
auto_inc_p (const_rtx x)
{
switch (GET_CODE (x))
{
case PRE_INC:
Index: optabs.c
===
--- optabs.c(revision 196633)
+++ optabs.c(working copy)
@@ -1285,33 +1285,29 @@ expand_simple_binop (enum machine_mode m
rtx op1, rtx target, int unsignedp,
enum optab_methods methods)
{
optab binop = code_to_optab (code);
gcc_assert (binop);
return expand_binop (mode, binop, op0, op1, target, unsignedp, methods);
}
/* Return whether OP0 and OP1 should be swapped when expanding a commutative
- binop. Order them according to commutative_operand_precedence and, if
- possible, try to put TARGET or a pseudo first. */
+ binop. Order them according to compare_commutative_operands_precedence and,
+ if possible, try to put TARGET or a pseudo first. */
static bool
swap_commutative_operands_with_target (rtx target, rtx op0, rtx op1)
{
- int op0_prec = commutative_operand_precedence (op0);
- int op1_prec = commutative_operand_precedence (op1);
+ int cmp = compare_commutative_operands_precedence (op0, op1);
- if (op0_prec < op1_prec)
-return true;
-
- if (op0_prec > op1_prec)
-return false;
+ if (cmp != 0)
+return cmp < 0;
/* With equal precedence, both orders are ok, but it is better if the
first operand is TARGET, or if both TARGET and OP0 are pseudos. */
i
Re: [Patch, microblaze]: Enable DWARF exception handling support
On 03/18/2013 05:47 AM, David Holsgrove wrote: Add DWARF exception handling support for MicroBlaze. Changelog 2013-03-18 Edgar E. Iglesias David Holsgrove * common/config/microblaze/microblaze-common.c: Remove TARGET_EXCEPT_UNWIND_INFO definition. * config/microblaze/microblaze-protos.h: Add microblaze_eh_return prototype. * gcc/config/microblaze/microblaze.c: (microblaze_must_save_register, microblaze_expand_epilogue, microblaze_return_addr): Handle calls_eh_return (microblaze_eh_return): New function. * gcc/config/microblaze/microblaze.h: Define RETURN_ADDR_OFFSET, EH_RETURN_DATA_REGNO, MB_EH_STACKADJ_REGNUM, EH_RETURN_STACKADJ_RTX, ASM_PREFERRED_EH_DATA_FORMAT * gcc/config/microblaze/microblaze.md: Define eh_return pattern. Hi David -- I see about 50 more failures (an increase from 137 to 189) in the g++ regression tests after applying this patch. I haven't looked at the failures in detail. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: i * i is nonnegative
On Tue, 19 Mar 2013, Jeff Law wrote: On 03/19/2013 10:08 AM, Marc Glisse wrote: Hello, this patch extends the property that x*x is non-negative, which was already known for floats, to integers with undefined overflow. 2013-03-19 Marc Glisse PR tree-optimization/56355 gcc/ * fold-const.c (tree_binary_nonnegative_warnv_p) : Also handle integers with undefined overflow. gcc/testsuite/ * gcc.dg/pr56355-1.c: New file. Fine for the trunk. Though I would suggest waiting for http service & web archives to return before committing. Yep. BTW, did you check if VRP creates a non-negative range for this case as well? It doesn't :-( It would probably need to be done in extract_range_from_binary_expr since extract_range_from_binary_expr_1 does not see the expression, maybe after calling extract_range_from_binary_expr_1, and we would remove the negative part of the interval it returned. -- Marc Glisse
Re: [gomp 4.0] libgomp.texi: Add OMP_DISPLAY_ENV and GOMP_SPINCOUNT
On Tue, Mar 19, 2013 at 05:34:08PM +0100, Tobias Burnus wrote: > This patch adds documentation for OMP_DISPLAY_ENV, which was added > by previously submitted patch, and it documents GOMP_SPINCOUNT, > which was added 2010-12-02 but not yet documented. > > Additionally, I have updated the section references to OpenMP 4.0 > (but only for the environment section) and did some minor cleanups. > > Tested with make pdf and make info. > OK for the branch - after it has been created? Yes, thanks. > 2013-03-19 Tobias Burnus > > * libgomp.texi (Environment Variables): Minor cleanup, > update section refs to OpenMP 4.0rc2. > (OMP_DISPLAY_ENV, GOMP_SPINCOUNT): Document these > environment variables. Jakub
[gomp 4.0] libgomp.texi: Add OMP_DISPLAY_ENV and GOMP_SPINCOUNT
This patch adds documentation for OMP_DISPLAY_ENV, which was added by
previously submitted patch, and it documents GOMP_SPINCOUNT, which was
added 2010-12-02 but not yet documented.
Additionally, I have updated the section references to OpenMP 4.0 (but
only for the environment section) and did some minor cleanups.
Tested with make pdf and make info.
OK for the branch - after it has been created?
Tobias
2013-03-19 Tobias Burnus
* libgomp.texi (Environment Variables): Minor cleanup,
update section refs to OpenMP 4.0rc2.
(OMP_DISPLAY_ENV, GOMP_SPINCOUNT): Document these
environment variables.
diff --git a/libgomp/libgomp.texi b/libgomp/libgomp.texi
index 40c3830..c54fb2f 100644
--- a/libgomp/libgomp.texi
+++ b/libgomp/libgomp.texi
@@ -1083,12 +1083,9 @@ guaranteed not to change during the execution of the program.
@node Environment Variables
@chapter Environment Variables
-The variables @env{OMP_DYNAMIC}, @env{OMP_MAX_ACTIVE_LEVELS},
-@env{OMP_NESTED}, @env{OMP_NUM_THREADS}, @env{OMP_SCHEDULE},
-@env{OMP_STACKSIZE},@env{OMP_THREAD_LIMIT} and @env{OMP_WAIT_POLICY}
-are defined by section 4 of the OpenMP specifications in version 3.1,
-while @env{GOMP_CPU_AFFINITY} and @env{GOMP_STACKSIZE} are GNU
-extensions.
+The environment variables which beginning with @env{OMP_} are defined by
+section 4 of the OpenMP specification in version 4.0, while those
+beginning with @env{GOMP_} are GNU extensions.
@menu
* OMP_DYNAMIC:: Dynamic adjustment of threads
@@ -1099,9 +1096,11 @@ extensions.
* OMP_SCHEDULE:: How threads are scheduled
* OMP_THREAD_LIMIT:: Set the maximum number of threads
* OMP_WAIT_POLICY:: How waiting threads are handled
+* OMP_DISPLAY_ENV:: Show OpenMP version and environment variables
* OMP_PROC_BIND:: Whether theads may be moved between CPUs
* GOMP_CPU_AFFINITY:: Bind threads to specific CPUs
* GOMP_STACKSIZE::Set default thread stack size
+* GOMP_SPINCOUNT::Set the busy-wait spin count
@end menu
@@ -1119,7 +1118,7 @@ disabled by default.
@ref{omp_set_dynamic}
@item @emph{Reference}:
-@uref{http://www.openmp.org/, OpenMP specifications v3.1}, section 4.3
+@uref{http://www.openmp.org/, OpenMP specifications v4.0}, section 4.3
@end table
@@ -1137,7 +1136,7 @@ If undefined, the number of active levels is unlimited.
@ref{omp_set_max_active_levels}
@item @emph{Reference}:
-@uref{http://www.openmp.org/, OpenMP specifications v3.1}, section 4.8
+@uref{http://www.openmp.org/, OpenMP specifications v4.0}, section 4.9
@end table
@@ -1157,7 +1156,7 @@ regions are disabled by default.
@ref{omp_set_nested}
@item @emph{Reference}:
-@uref{http://www.openmp.org/, OpenMP specifications v3.1}, section 4.5
+@uref{http://www.openmp.org/, OpenMP specifications v4.0}, section 4.6
@end table
@@ -1177,7 +1176,7 @@ level. If undefined one thread per CPU is used.
@ref{omp_set_num_threads}
@item @emph{Reference}:
-@uref{http://www.openmp.org/, OpenMP specifications v3.1}, section 4.2
+@uref{http://www.openmp.org/, OpenMP specifications v4.0}, section 4.2
@end table
@@ -1198,7 +1197,7 @@ dynamic scheduling and a chunk size of 1 is used.
@ref{omp_set_schedule}
@item @emph{Reference}:
-@uref{http://www.openmp.org/, OpenMP specifications v3.1}, sections 2.5.1 and 4.1
+@uref{http://www.openmp.org/, OpenMP specifications v4.0}, sections 2.7.1 and 4.1
@end table
@@ -1218,7 +1217,7 @@ stack size is left unchanged. If undefined, the stack size is system
dependent.
@item @emph{Reference}:
-@uref{http://www.openmp.org/, OpenMP specifications v3.1}, sections 4.6
+@uref{http://www.openmp.org/, OpenMP specifications v4.0}, section 4.7
@end table
@@ -1237,7 +1236,7 @@ the number of threads is not limited.
@ref{omp_get_thread_limit}
@item @emph{Reference}:
-@uref{http://www.openmp.org/, OpenMP specifications v3.1}, section 4.9
+@uref{http://www.openmp.org/, OpenMP specifications v4.0}, section 4.10
@end table
@@ -1250,10 +1249,14 @@ the number of threads is not limited.
Specifies whether waiting threads should be active or passive. If
the value is @code{PASSIVE}, waiting threads should not consume CPU
power while waiting; while the value is @code{ACTIVE} specifies that
-they should.
+they should. If undefined, threads wait actively for a short time
+before waiting passively.
+
+@item @emph{See also}:
+@ref{GOMP_SPINCOUNT}
@item @emph{Reference}:
-@uref{http://www.openmp.org/, OpenMP specifications v3.1}, sections 4.7
+@uref{http://www.openmp.org/, OpenMP specifications v4.0}, section 4.8
@end table
@@ -1264,14 +1267,32 @@ they should.
@table @asis
@item @emph{Description}:
Specifies whether threads may be moved between processors. If set to
-@code{true}, OpenMP theads should not be moved, if set to @code{false}
-they may be moved.
+@code{TRUE}, OpenMP theads should not be moved, if set to @code{FALSE}
+they may be moved. If undefined, threads may move between p
Re: i * i is nonnegative
On 03/19/2013 10:08 AM, Marc Glisse wrote: Hello, this patch extends the property that x*x is non-negative, which was already known for floats, to integers with undefined overflow. 2013-03-19 Marc Glisse PR tree-optimization/56355 gcc/ * fold-const.c (tree_binary_nonnegative_warnv_p) : Also handle integers with undefined overflow. gcc/testsuite/ * gcc.dg/pr56355-1.c: New file. Fine for the trunk. Though I would suggest waiting for http service & web archives to return before committing. BTW, did you check if VRP creates a non-negative range for this case as well? jeff
Re: [PATCH 1/4] Mark all member functions with memory models always inline
On Tue, Mar 19, 2013 at 08:51:21AM -0700, Andi Kleen wrote:
> > Using __always_inline as the name of the macro is a bad idea, glibc
> > headers use that macro already. Just use something else in public headers
> > that aren't part of glibc.
>
> That's why I had the ifdef, but ok. I'll use __force_inline then.
I'd say Jonathan's _GLIBCXX_ALWAYS_INLINE would be better.
BTW, have you verified always_inline works fine for -O0?
int x;
inline __attribute__((always_inline)) bool
test_and_set(int __m = 5)
{
return __atomic_test_and_set (&x, __m);
}
int
foo (void)
{
return test_and_set (65536 | 5);
}
with -O0 -mhle doesn't result in xacquire, guess for !optimize
get_memmodel would need to look through chain of SSA_NAMEs if SSA_NAME
(that can appear because of inlining), looking for INTEGER_CSTs.
If there is:
_7 = 0x10005;
_8 = _7;
_9 = _8;
__atomic_test_and_set (&x, _9);
still return 0x10005 rather than MEMMODEL_SEQ_CST.
Jakub
i * i is nonnegative
Hello,
this patch extends the property that x*x is non-negative, which was
already known for floats, to integers with undefined overflow.
2013-03-19 Marc Glisse
PR tree-optimization/56355
gcc/
* fold-const.c (tree_binary_nonnegative_warnv_p) :
Also handle integers with undefined overflow.
gcc/testsuite/
* gcc.dg/pr56355-1.c: New file.
--
Marc GlisseIndex: gcc/testsuite/gcc.dg/pr56355-1.c
===
--- gcc/testsuite/gcc.dg/pr56355-1.c(revision 0)
+++ gcc/testsuite/gcc.dg/pr56355-1.c(revision 0)
@@ -0,0 +1,8 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -Wstrict-overflow=4" } */
+
+int
+f (int i)
+{
+ return __builtin_abs (i * i); /* { dg-warning "assuming signed overflow" } */
+}
Property changes on: gcc/testsuite/gcc.dg/pr56355-1.c
___
Added: svn:eol-style
+ native
Added: svn:keywords
+ Author Date Id Revision URL
Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 196633)
+++ gcc/fold-const.c(working copy)
@@ -15286,29 +15286,32 @@ tree_binary_nonnegative_warnv_p (enum tr
&& TREE_CODE (inner2) == INTEGER_TYPE && TYPE_UNSIGNED (inner2))
{
unsigned int prec = MAX (TYPE_PRECISION (inner1),
TYPE_PRECISION (inner2)) + 1;
return prec < TYPE_PRECISION (type);
}
}
break;
case MULT_EXPR:
- if (FLOAT_TYPE_P (type))
+ if (FLOAT_TYPE_P (type) || TYPE_OVERFLOW_UNDEFINED (type))
{
- /* x * x for floating point x is always non-negative. */
- if (operand_equal_p (op0, op1, 0))
- return true;
- return (tree_expr_nonnegative_warnv_p (op0,
-strict_overflow_p)
- && tree_expr_nonnegative_warnv_p (op1,
- strict_overflow_p));
+ /* x * x is always non-negative for floating point x
+or without overflow. */
+ if (operand_equal_p (op0, op1, 0)
+ || (tree_expr_nonnegative_warnv_p (op0, strict_overflow_p)
+ && tree_expr_nonnegative_warnv_p (op1, strict_overflow_p)))
+ {
+ if (TYPE_OVERFLOW_UNDEFINED (type))
+ *strict_overflow_p = true;
+ return true;
+ }
}
/* zero_extend(x) * zero_extend(y) is non-negative if x and y are
both unsigned and their total bits is shorter than the result. */
if (TREE_CODE (type) == INTEGER_TYPE
&& (TREE_CODE (op0) == NOP_EXPR || TREE_CODE (op0) == INTEGER_CST)
&& (TREE_CODE (op1) == NOP_EXPR || TREE_CODE (op1) == INTEGER_CST))
{
tree inner0 = (TREE_CODE (op0) == NOP_EXPR)
? TREE_TYPE (TREE_OPERAND (op0, 0))
Re: [PATCH 1/4] Mark all member functions with memory models always inline
> Using __always_inline as the name of the macro is a bad idea, glibc > headers use that macro already. Just use something else in public headers > that aren't part of glibc. That's why I had the ifdef, but ok. I'll use __force_inline then. -Andi
[RTL, i386] Use subreg instead of UNSPEC_CAST
Hello,
the following patch passes bootstrap+testsuite on x86_64-linux-gnu. I
don't see any particular reason to forbid vector subregs of vectors, since
we can already do it through a scalar. And not using unspecs helps avoid
unnecessary copies.
2013-01-03 Marc Glisse
PR target/50829
gcc/
* config/i386/sse.md (enum unspec): Remove UNSPEC_CAST.
(avx__): Use subreg.
* emit-rtl.c (validate_subreg): Allow vector-vector subregs.
gcc/testsuite/
* gcc.target/i386/pr50829.c: New file.
--
Marc GlisseIndex: gcc/testsuite/gcc.target/i386/pr50829.c
===
--- gcc/testsuite/gcc.target/i386/pr50829.c (revision 0)
+++ gcc/testsuite/gcc.target/i386/pr50829.c (revision 0)
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options "-O1 -mavx" } */
+
+#include
+
+__m256d
+concat (__m128d x)
+{
+ __m256d z = _mm256_castpd128_pd256 (x);
+ return _mm256_insertf128_pd (z, x, 1);
+}
+
+/* { dg-final { scan-assembler-not "vmov" } } */
Property changes on: gcc/testsuite/gcc.target/i386/pr50829.c
___
Added: svn:keywords
+ Author Date Id Revision URL
Added: svn:eol-style
+ native
Index: gcc/config/i386/sse.md
===
--- gcc/config/i386/sse.md (revision 196633)
+++ gcc/config/i386/sse.md (working copy)
@@ -66,21 +66,20 @@
UNSPEC_AESKEYGENASSIST
;; For PCLMUL support
UNSPEC_PCLMUL
;; For AVX support
UNSPEC_PCMP
UNSPEC_VPERMIL
UNSPEC_VPERMIL2
UNSPEC_VPERMIL2F128
- UNSPEC_CAST
UNSPEC_VTESTP
UNSPEC_VCVTPH2PS
UNSPEC_VCVTPS2PH
;; For AVX2 support
UNSPEC_VPERMVAR
UNSPEC_VPERMTI
UNSPEC_GATHER
UNSPEC_VSIBADDR
])
@@ -11089,23 +11088,22 @@
"TARGET_AVX"
"vmaskmov\t{%2, %1, %0|%0, %1, %2}"
[(set_attr "type" "sselog1")
(set_attr "prefix_extra" "1")
(set_attr "prefix" "vex")
(set_attr "btver2_decode" "vector")
(set_attr "mode" "")])
(define_insn_and_split "avx__"
[(set (match_operand:AVX256MODE2P 0 "nonimmediate_operand" "=x,m")
- (unspec:AVX256MODE2P
- [(match_operand: 1 "nonimmediate_operand" "xm,x")]
- UNSPEC_CAST))]
+ (subreg:AVX256MODE2P
+ (match_operand: 1 "nonimmediate_operand" "xm,x") 0))]
"TARGET_AVX"
"#"
"&& reload_completed"
[(const_int 0)]
{
rtx op0 = operands[0];
rtx op1 = operands[1];
if (REG_P (op0))
op0 = gen_rtx_REG (mode, REGNO (op0));
else
Index: gcc/emit-rtl.c
===
--- gcc/emit-rtl.c (revision 196633)
+++ gcc/emit-rtl.c (working copy)
@@ -707,20 +707,23 @@ validate_subreg (enum machine_mode omode
else if ((COMPLEX_MODE_P (imode) || VECTOR_MODE_P (imode))
&& GET_MODE_INNER (imode) == omode)
;
/* ??? x86 sse code makes heavy use of *paradoxical* vector subregs,
i.e. (subreg:V4SF (reg:SF) 0). This surely isn't the cleanest way to
represent this. It's questionable if this ought to be represented at
all -- why can't this all be hidden in post-reload splitters that make
arbitrarily mode changes to the registers themselves. */
else if (VECTOR_MODE_P (omode) && GET_MODE_INNER (omode) == imode)
;
+ else if (VECTOR_MODE_P (omode) && VECTOR_MODE_P (imode)
+ && GET_MODE_INNER (omode) == GET_MODE_INNER (imode))
+;
/* Subregs involving floating point modes are not allowed to
change size. Therefore (subreg:DI (reg:DF) 0) is fine, but
(subreg:SI (reg:DF) 0) isn't. */
else if (FLOAT_MODE_P (imode) || FLOAT_MODE_P (omode))
{
if (! (isize == osize
/* LRA can use subreg to store a floating point value in
an integer mode. Although the floating point and the
integer modes need the same number of hard registers,
the size of floating point mode can be less than the
Re: [PATCH] Fix vectorizer fallout
On Tue, 19 Mar 2013, Jakub Jelinek wrote: > On Tue, Mar 19, 2013 at 04:21:46PM +0100, Richard Biener wrote: > > > > This fixes fallout reported for "Fix ???s in find_uses_to_rename". > > > > Bootstrapped and tested on x86_64-unknown-linux-gnu, scheduled for > > commit. > > > > Richard. > > > > 2013-03-19 Richard Biener > > > > PR tree-optimization/ > > Missing PR number? > Are you just waiting for bugzilla to come up to fill it in? Yes. Richard.
Re: [PATCH] Fix vectorizer fallout
On Tue, Mar 19, 2013 at 04:21:46PM +0100, Richard Biener wrote: > > This fixes fallout reported for "Fix ???s in find_uses_to_rename". > > Bootstrapped and tested on x86_64-unknown-linux-gnu, scheduled for > commit. > > Richard. > > 2013-03-19 Richard Biener > > PR tree-optimization/ Missing PR number? Are you just waiting for bugzilla to come up to fill it in? > * tree-vect-loop-manip.c (slpeel_can_duplicate_loop_p): Do not > check whether an SSA update is needed. > > Index: gcc/tree-vect-loop-manip.c > === > --- gcc/tree-vect-loop-manip.c(revision 196791) > +++ gcc/tree-vect-loop-manip.c(working copy) > @@ -848,9 +848,6 @@ slpeel_can_duplicate_loop_p (const struc >gimple orig_cond = get_loop_exit_condition (loop); >gimple_stmt_iterator loop_exit_gsi = gsi_last_bb (exit_e->src); > > - if (need_ssa_update_p (cfun)) > -return false; > - >if (loop->inner >/* All loops have an outer scope; the only case loop->outer is NULL is > for > the function itself. */ Jakub
[PATCH RFC] Finer grained reg classes.
This is very much a work in progress, but I think it has potential to solve the problem at hand. A major blocker for using LRA on sparc is a fundamental limitation of register classes as currently implemented. If you have an instruction that requires an evenly aligned hard register pair, you cannot describe this alone using register classes. That's because register classes must contain all registers of a multiple register set, which effectively would allow both even and odd registers, thus not constraining the hard registers which are valid at all. Targets work around this by using HARD_REGNO_MODE_OK(), which causes pre-LRA reload to fix up all the hard register allocation mistakes made by IRA, the latter of which relies largely upon register classes. LRA relies upon register classes completely, so targets really have to express an instruction's exact needs using register classes rather than ad-hoc constraints like the "U" constraint sparc is using: (define_constraint "U" "Pseudo-register or hard even-numbered integer register" (and (match_test "TARGET_ARCH32") (match_code "reg") (ior (match_test "REGNO (op) < FIRST_PSEUDO_REGISTER") (not (match_test "reload_in_progress && reg_renumber [REGNO (op)] < 0"))) (match_test "register_ok_for_ldd (op)"))) So this patch tries to rework the semantics of hard register classes, such that if a hard register is present in the set it is implied that the rest of the registers in a multi-register group are present as well. So we can add a register class called EVEN_REGS and only have to set the even register bits. The patch below is enough to get zero regressions for the c/c++ testsuite on 32-bit sparc, but I do know that there are some problems that need to be resolved still. For example, I think we need some way to validate a regclass based upon the mode, something slightly different from HARD_REGNO_MODE_OK. This would be used for things like the "a" constraint on x86 so that on 32-bit a user couldn't try to use the "a" constraint in an inline asm for a 64-bit value. In the compiler itself, this really isn't an issue, because the machine description would only use register classes for the proper mode. I intend to also use this new regclass scheme to represent FPU double register pairs on sparc as well. Anyways, any comments would be appreciated, thanks. diff --git a/gcc/config/sparc/constraints.md b/gcc/config/sparc/constraints.md index 5dec3dd..cd082ad 100644 --- a/gcc/config/sparc/constraints.md +++ b/gcc/config/sparc/constraints.md @@ -44,6 +44,9 @@ (define_register_constraint "h" "(TARGET_V9 && TARGET_V8PLUS ? I64_REGS : NO_REGS)" "64-bit global or out register in V8+ mode") +(define_register_constraint "U" "(TARGET_ARCH32 ? EVEN_REGS : NO_REGS)" + "Even-numbered integer register") + ;; Floating-point constant constraints (define_constraint "G" @@ -135,51 +138,6 @@ (match_code "mem") (match_test "memory_ok_for_ldd (op)"))) -;; This awkward register constraint is necessary because it is not -;; possible to express the "must be even numbered register" condition -;; using register classes. The problem is that membership in a -;; register class requires that all registers of a multi-regno -;; register be included in the set. It is add_to_hard_reg_set -;; and in_hard_reg_set_p which populate and test regsets with these -;; semantics. -;; -;; So this means that we would have to put both the even and odd -;; register into the register class, which would not restrict things -;; at all. -;; -;; Using a combination of GENERAL_REGS and HARD_REGNO_MODE_OK is not a -;; full solution either. In fact, even though IRA uses the macro -;; HARD_REGNO_MODE_OK to calculate which registers are prohibited from -;; use in certain modes, it still can allocate an odd hard register -;; for DImode values. This is due to how IRA populates the table -;; ira_useful_class_mode_regs[][]. It suffers from the same problem -;; as using a register class to describe this restriction. Namely, it -;; sets both the odd and even part of an even register pair in the -;; regset. Therefore IRA can and will allocate odd registers for -;; DImode values on 32-bit. -;; -;; There are legitimate cases where DImode values can end up in odd -;; hard registers, the most notable example is argument passing. -;; -;; What saves us is reload and the DImode splitters. Both are -;; necessary. The odd register splitters cannot match if, for -;; example, we have a non-offsetable MEM. Reload will notice this -;; case and reload the address into a single hard register. -;; -;; The real downfall of this awkward register constraint is that it does -;; not evaluate to a true register class like a bonafide use of -;; define_register_constraint would. This currently means that we cannot -;; use LRA on Sparc, since the constraint processing of LRA really depends -;; upon whether an extra constraint is for registers or not. It uses -;; REG_CLASS_FROM_C
[gomp 4.0] Handle OMP_DISPLAY_ENV
Attached is a first shot for OMP_DISPLAY_ENV. One could think about how
to handle GOMP_CPU_AFFINITY and OMP_WAIT_POLICY. I currently print an
empty list for affinity (although using GOMP_CPU_AFFINITY='' leads to a
warning that the list is empty) and for OMP_WAIT_POLICY, an unset
variable is handled as something between ACTIVE and PASSIVE; the patch
prints PASSIVE in that case.
Build and regtested on x86-64-gnu-linux.
OK for the gomp-4_0-branch - after is has been created?
Tobias
2013-03-19 Tobias Burnus
* env.c (handle_omp_display_env): New function.
(initialize_env): Use it.
diff --git a/libgomp/env.c b/libgomp/env.c
index 65cbba8..e228bd9 100644
--- a/libgomp/env.c
+++ b/libgomp/env.c
@@ -29,6 +29,8 @@
#include "libgomp_f.h"
#include
#include
+#include
+#include /* For PRIu64. */
#ifdef STRING_WITH_STRINGS
# include
# include
@@ -565,6 +567,117 @@ parse_affinity (void)
return false;
}
+
+static void
+handle_omp_display_env (bool proc_bind, unsigned long stacksize,
+ int wait_policy)
+{
+ const char *env;
+ bool display = false;
+ bool verbose = false;
+ int i;
+
+ env = getenv ("OMP_DISPLAY_ENV");
+ if (env == NULL)
+return;
+
+ while (isspace ((unsigned char) *env))
+++env;
+ if (strncasecmp (env, "true", 4) == 0)
+{
+ env += 4;
+}
+ else if (strncasecmp (env, "false", 5) == 0)
+{
+ display = false;
+ env += 5;
+}
+ else if (strncasecmp (env, "verbose", 7) == 0)
+{
+ display = true;
+ verbose = true;
+ env += 7;
+}
+ else
+env = "X";
+ while (isspace ((unsigned char) *env))
+++env;
+ if (*env != '\0')
+gomp_error ("Invalid value for environment variable OMP_DISPLAY_ENV");
+
+ if (!display)
+return;
+
+ fputs ("\nOPENMP DISPLAY ENVIRONMENT BEGIN\n", stderr);
+
+ fputs (" _OPENMP = '201107'\n", stderr);
+ fprintf (stderr, " OMP_DYNAMIC = '%s'\n",
+ gomp_global_icv.dyn_var ? "TRUE" : "FALSE");
+ fprintf (stderr, " OMP_NESTED = '%s'\n",
+ gomp_global_icv.nest_var ? "TRUE" : "FALSE");
+
+ fprintf (stderr, " OMP_NUM_THREADS = '%lu", gomp_global_icv.nthreads_var);
+ for (i = 1; i < gomp_nthreads_var_list_len; i++)
+fprintf (stderr, ",%lu", gomp_nthreads_var_list[i]);
+ fputs ("'\n", stderr);
+
+ fprintf (stderr, " OMP_SCHEDULE = '");
+ switch (gomp_global_icv.run_sched_var)
+{
+case GFS_RUNTIME:
+ fputs ("RUNTIME", stderr);
+ break;
+case GFS_STATIC:
+ fputs ("STATIC", stderr);
+ break;
+case GFS_DYNAMIC:
+ fputs ("DYNAMIC", stderr);
+ break;
+case GFS_GUIDED:
+ fputs ("GUIDED", stderr);
+ break;
+case GFS_AUTO:
+ fputs ("AUTO", stderr);
+ break;
+}
+ fputs ("'\n", stderr);
+
+ fprintf (stderr, " OMP_PROC_BIND = '%s'\n",
+ proc_bind ? "TRUE" : "FALSE");
+ fprintf (stderr, " OMP_STACKSIZE = '%lu'\n", stacksize);
+
+ /* GOMP's default value is actually neither active nor passive. */
+ fprintf (stderr, " OMP_WAIT_POLICY = '%s'\n",
+ wait_policy > 0 ? "ACTIVE" : "PASSIVE");
+ fprintf (stderr, " OMP_THREAD_LIMIT = '%lu'\n",
+ gomp_thread_limit_var);
+ fprintf (stderr, " OMP_MAX_ACTIVE_LEVELS = '%lu'\n",
+ gomp_max_active_levels_var);
+
+/* FIXME: Unimplemented OpenMP 4.0 environment variables.
+ fprintf (stderr, " OMP_PLACES = ''\n");
+ fprintf (stderr, " OMP_CANCELLATION = ''\n");
+ fprintf (stderr, " OMP_DEFAULT_DEVICE = ''\n"); */
+
+ if (verbose)
+{
+ fputs (" GOMP_CPU_AFFINITY = '", stderr);
+ if (gomp_cpu_affinity_len)
+ {
+ fprintf (stderr, "%d", gomp_cpu_affinity[0]);
+ for (i = 1; i < gomp_cpu_affinity_len; i++)
+ fprintf (stderr, " %d", gomp_cpu_affinity[i]);
+ }
+ fputs ("'\n", stderr);
+ fprintf (stderr, " GOMP_STACKSIZE = '%lu'\n", stacksize);
+ fprintf (stderr, " GOMP_SPINCOUNT = '%"PRIu64"'\n",
+ (uint64_t) gomp_spin_count_var);
+}
+
+ fputs ("OPENMP DISPLAY ENVIRONMENT END\n", stderr);
+}
+
+
static void __attribute__((constructor))
initialize_env (void)
{
@@ -645,6 +758,8 @@ initialize_env (void)
if (err != 0)
gomp_error ("Stack size change failed: %s", strerror (err));
}
+
+ handle_omp_display_env (bind_var, stacksize, wait_policy);
}
[PATCH] Fix vectorizer fallout
This fixes fallout reported for "Fix ???s in find_uses_to_rename". Bootstrapped and tested on x86_64-unknown-linux-gnu, scheduled for commit. Richard. 2013-03-19 Richard Biener PR tree-optimization/ * tree-vect-loop-manip.c (slpeel_can_duplicate_loop_p): Do not check whether an SSA update is needed. Index: gcc/tree-vect-loop-manip.c === --- gcc/tree-vect-loop-manip.c (revision 196791) +++ gcc/tree-vect-loop-manip.c (working copy) @@ -848,9 +848,6 @@ slpeel_can_duplicate_loop_p (const struc gimple orig_cond = get_loop_exit_condition (loop); gimple_stmt_iterator loop_exit_gsi = gsi_last_bb (exit_e->src); - if (need_ssa_update_p (cfun)) -return false; - if (loop->inner /* All loops have an outer scope; the only case loop->outer is NULL is for the function itself. */
Re: Property for vector lowering
On Thu, Dec 6, 2012 at 6:19 PM, Marc Glisse wrote:
> Hello,
>
> this patch (for 4.9) introduces a property so we can check if vector
> operations have been lowered yet. It mimics the complex lowering property,
> and this required moving the -O0 vector lowering pass (otherwise it breaks
> many testcases with "covariant" in their name).
>
> The tree-ssa-forwprop.c part was mostly to test if this was working, it may
> need some changes and I am fine with leaving it out for now. One day,
> lower_vec_perm might be able to do something cleverer than a constructor of
> element bitfields, for instance in the case where the vector is only twice
> the size of supported vector operations and both arguments are the same,
> then we could lower: vec_perm_expr(v,v,m) into {vec_perm_expr(v0,v1,m0),
> vec_perm_expr(v0,v1,m1)} where v0 is the first half of v, etc.
>
> Passes bootstrap+testsuite on x86_64-linux (same number of PASS afterwards,
> it is hard to compare lines exactly with the pass numbering changes).
Ok with leaving out the tree-ssa-forwprop.c changes for now.
Thanks,
Richard.
> 2012-12-06 Marc Glisse
>
> * tree-pass.h (PROP_gimple_lvec): New.
> * passes.c (dump_properties): Handle PROP_gimple_lvec.
> (init_optimization_passes): Move pass_lower_vector.
> * tree-vect-generic.c (gate_expand_vector_operations_ssa): Test
> PROP_gimple_lvec.
> (pass_lower_vector): Provide PROP_gimple_lvec.
> (pass_lower_vector_ssa): Likewise.
> * cfgexpand.c (pass_expand): Require PROP_gimple_lvec.
> * tree-ssa-forwprop.c (simplify_vector_constructor): Test
> PROP_gimple_lvec.
>
> --
> Marc Glisse
> Index: passes.c
> ===
> --- passes.c(revision 194247)
> +++ passes.c(working copy)
> @@ -1305,21 +1305,20 @@ init_optimization_passes (void)
>NEXT_PASS (pass_ipa_free_lang_data);
>NEXT_PASS (pass_ipa_function_and_variable_visibility);
>NEXT_PASS (pass_early_local_passes);
> {
>struct opt_pass **p = &pass_early_local_passes.pass.sub;
>NEXT_PASS (pass_fixup_cfg);
>NEXT_PASS (pass_init_datastructures);
>NEXT_PASS (pass_expand_omp);
>
>NEXT_PASS (pass_build_ssa);
> - NEXT_PASS (pass_lower_vector);
>NEXT_PASS (pass_early_warn_uninitialized);
>NEXT_PASS (pass_rebuild_cgraph_edges);
>NEXT_PASS (pass_inline_parameters);
>NEXT_PASS (pass_early_inline);
>NEXT_PASS (pass_all_early_optimizations);
> {
> struct opt_pass **p = &pass_all_early_optimizations.pass.sub;
> NEXT_PASS (pass_remove_cgraph_callee_edges);
> NEXT_PASS (pass_rename_ssa_copies);
> NEXT_PASS (pass_ccp);
> @@ -1549,20 +1548,21 @@ init_optimization_passes (void)
>NEXT_PASS (pass_uncprop);
>NEXT_PASS (pass_local_pure_const);
> }
>NEXT_PASS (pass_tm_init);
> {
>struct opt_pass **p = &pass_tm_init.pass.sub;
>NEXT_PASS (pass_tm_mark);
>NEXT_PASS (pass_tm_memopt);
>NEXT_PASS (pass_tm_edges);
> }
> + NEXT_PASS (pass_lower_vector);
>NEXT_PASS (pass_lower_complex_O0);
>NEXT_PASS (pass_asan_O0);
>NEXT_PASS (pass_tsan_O0);
>NEXT_PASS (pass_cleanup_eh);
>NEXT_PASS (pass_lower_resx);
>NEXT_PASS (pass_nrv);
>NEXT_PASS (pass_mudflap_2);
>NEXT_PASS (pass_cleanup_cfg_post_optimizing);
>NEXT_PASS (pass_warn_function_noreturn);
>
> @@ -2769,20 +2769,22 @@ dump_properties (FILE *dump, unsigned in
>if (props & PROP_ssa)
> fprintf (dump, "PROP_ssa\n");
>if (props & PROP_no_crit_edges)
> fprintf (dump, "PROP_no_crit_edges\n");
>if (props & PROP_rtl)
> fprintf (dump, "PROP_rtl\n");
>if (props & PROP_gimple_lomp)
> fprintf (dump, "PROP_gimple_lomp\n");
>if (props & PROP_gimple_lcx)
> fprintf (dump, "PROP_gimple_lcx\n");
> + if (props & PROP_gimple_lvec)
> +fprintf (dump, "PROP_gimple_lvec\n");
>if (props & PROP_cfglayout)
> fprintf (dump, "PROP_cfglayout\n");
> }
>
> DEBUG_FUNCTION void
> debug_properties (unsigned int props)
> {
>dump_properties (stderr, props);
> }
>
> Index: tree-pass.h
> ===
> --- tree-pass.h (revision 194247)
> +++ tree-pass.h (working copy)
> @@ -142,20 +142,21 @@ struct simple_ipa_opt_pass
> #define PROP_gimple_lcf(1 << 1)/* lowered control
> flow */
> #define PROP_gimple_leh(1 << 2)/* lowered eh */
> #define PROP_cfg (1 << 3)
> #define PROP_ssa (1 << 5)
> #define PROP_no_crit_edges (1 << 6)
> #define PROP_rtl (1 << 7)
> #define PROP_gimple_lomp (1 << 8)/* lowered OpenMP directives
> */
> #define PROP_cfglayout (1 << 9)/* cfglayout mode on RTL */
> #define PROP_gimple_lcx(1 << 10) /* lowered comp
Re: Fold VEC_COND_EXPR to abs, min, max
On Tue, Mar 19, 2013 at 9:06 AM, Marc Glisse wrote:
> Hello,
>
> new version of the patch. Note that for the simplification from {-1,-1}?a:b
> to a, I removed the test that b has no side effects and call
> pedantic_omit_one_operand_loc instead.
>
>
> Bootstrap + testsuite on x86_64-linux-gnu.
Ok.
Thanks,
Richard.
> 2013-03-19 Marc Glisse
>
> gcc/
> * tree.h (VECTOR_TYPE_P): New macro.
> (VECTOR_INTEGER_TYPE_P, VECTOR_FLOAT_TYPE_P, FLOAT_TYPE_P,
> TYPE_MODE): Use it.
>
> * fold-const.c (fold_cond_expr_with_comparison): Use build_zero_cst.
> VEC_COND_EXPR cannot be lvalues.
> (fold_ternary_loc) : Merge with the COND_EXPR case.
>
>
> gcc/cp/
> * call.c (build_conditional_expr_1): Fold VEC_COND_EXPR.
>
> gcc/testsuite/
> * g++.dg/ext/vector21.C: New testcase.
>
>
> --
> Marc Glisse
>
> Index: gcc/testsuite/g++.dg/ext/vector21.C
> ===
> --- gcc/testsuite/g++.dg/ext/vector21.C (revision 0)
> +++ gcc/testsuite/g++.dg/ext/vector21.C (revision 0)
> @@ -0,0 +1,39 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O -fdump-tree-gimple" } */
> +
> +typedef int vec __attribute__ ((vector_size (4 * sizeof (int;
> +
> +void f1 (vec *x)
> +{
> + *x = (*x >= 0) ? *x : -*x;
> +}
> +void f2 (vec *x)
> +{
> + *x = (0 < *x) ? *x : -*x;
> +}
> +void g1 (vec *x)
> +{
> + *x = (*x < 0) ? -*x : *x;
> +}
> +void g2 (vec *x)
> +{
> + *x = (0 > *x) ? -*x : *x;
> +}
> +void h (vec *x, vec *y)
> +{
> + *x = (*x < *y) ? *y : *x;
> +}
> +void i (vec *x, vec *y)
> +{
> + *x = (*x < *y) ? *x : *y;
> +}
> +void j (vec *x, vec *y)
> +{
> + *x = (*x < *y) ? *x : *x;
> +}
> +
> +/* { dg-final { scan-tree-dump-times "ABS_EXPR" 4 "gimple" } } */
> +/* { dg-final { scan-tree-dump "MIN_EXPR" "gimple" } } */
> +/* { dg-final { scan-tree-dump "MAX_EXPR" "gimple" } } */
> +/* { dg-final { scan-tree-dump-not "VEC_COND_EXPR" "gimple" } } */
> +/* { dg-final { cleanup-tree-dump "gimple" } } */
>
> Property changes on: gcc/testsuite/g++.dg/ext/vector21.C
> ___
> Added: svn:eol-style
>+ native
> Added: svn:keywords
>+ Author Date Id Revision URL
>
> Index: gcc/cp/call.c
> ===
> --- gcc/cp/call.c (revision 196748)
> +++ gcc/cp/call.c (working copy)
> @@ -4430,23 +4430,23 @@ build_conditional_expr_1 (tree arg1, tre
> || TYPE_SIZE (arg1_type) != TYPE_SIZE (arg2_type))
> {
> if (complain & tf_error)
> error ("incompatible vector types in conditional expression: "
>"%qT, %qT and %qT", TREE_TYPE (arg1), TREE_TYPE
> (orig_arg2),
>TREE_TYPE (orig_arg3));
> return error_mark_node;
> }
>
>if (!COMPARISON_CLASS_P (arg1))
> - arg1 = build2 (NE_EXPR, signed_type_for (arg1_type), arg1,
> + arg1 = fold_build2 (NE_EXPR, signed_type_for (arg1_type), arg1,
>build_zero_cst (arg1_type));
> - return build3 (VEC_COND_EXPR, arg2_type, arg1, arg2, arg3);
> + return fold_build3 (VEC_COND_EXPR, arg2_type, arg1, arg2, arg3);
> }
>
>/* [expr.cond]
>
> The first expression is implicitly converted to bool (clause
> _conv_). */
>arg1 = perform_implicit_conversion_flags (boolean_type_node, arg1,
> complain,
> LOOKUP_NORMAL);
>if (error_operand_p (arg1))
> return error_mark_node;
> Index: gcc/tree.h
> ===
> --- gcc/tree.h (revision 196748)
> +++ gcc/tree.h (working copy)
> @@ -974,20 +974,24 @@ extern void omp_clause_range_check_faile
> && (TREE_TYPE (EXP)\
> == TREE_TYPE (TREE_OPERAND (EXP, 0 \
> (EXP) = TREE_OPERAND (EXP, 0)
>
> /* Remove unnecessary type conversions according to
> tree_ssa_useless_type_conversion. */
>
> #define STRIP_USELESS_TYPE_CONVERSION(EXP) \
>(EXP) = tree_ssa_strip_useless_type_conversions (EXP)
>
> +/* Nonzero if TYPE represents a vector type. */
> +
> +#define VECTOR_TYPE_P(TYPE) (TREE_CODE (TYPE) == VECTOR_TYPE)
> +
> /* Nonzero if TYPE represents an integral type. Note that we do not
> include COMPLEX types here. Keep these checks in ascending code
> order. */
>
> #define INTEGRAL_TYPE_P(TYPE) \
>(TREE_CODE (TYPE) == ENUMERAL_TYPE \
> || TREE_CODE (TYPE) == BOOLEAN_TYPE \
> || TREE_CODE (TYPE) == INTEGER_TYPE)
>
> /* Nonzero if TYPE represents a non-saturating fixed-point type. */
> @@ -1009,39 +1013,39 @@ extern void omp_clause_range_check_faile
> #define SCALAR_FLOAT_TYPE_P(TYPE) (TREE_CODE (TYPE) == REAL_TYPE)
>
> /* Nonzero if TYPE represents a complex floating-point type. */
>
> #define COMPLEX_FLOAT_TYPE_P(TYPE) \
>(TREE_CODE (TYPE) == COMPLE
Re: [PATCH][RFC] Remove TODO_ggc_collect, collect unconditionally
On Tue, 19 Mar 2013, Richard Biener wrote: > > This adds a GC collection point after each pass instead just after > those with TODO_ggc_collect in their todo. The patch will possibly > slow-down gcac checking a bit (80 passes have TODO_ggc_collect, > I didn't try to enumerate those that do not, but a grep shows we > may have up to 212 passes. OTOH gcac checking will now "properly" > verify that all pass boundaries are suitable for collection. > > A complete patch will remove TODO_ggc_collect and all its uses > as well. > > The patch should result in lower peak memory consumption for > some of the odd testcases that we worked on. > > Bootstrap & regtest scheduled on x86_64-unknown-linux-gnu. Which shows that I need to merge the IRA and reload/lra passes. Honza tells me that they are considered "separate" has historical reasons only. Given that reload pushes TV_IRA and that the boundary isn't GC safe I don't think that is too bad (dump files will now be shared, of course). I'll schedule a gcac checking bootstrap over night as well. Richard.
[testsuite] Don't XFAIL gfortran.dg/do_1.f90 (PR fortran/54932)
As discussed in PR fortran/54932, the gfortran.dg/do_1.f90 execution
tests recently stated to XPASS at all optimization levels, adding lots
of testsuite noise. The following patch removes the xfail, allowing all
tests to pass.
Tested with the appropriate runtest invocations on
x86_64-unknown-linux-gnu, i386-pc-solaris2.11, and
sparc-sun-solaris2.11. Ok for mainline and 4.8 branch?
Thanks.
Rainer
2013-03-19 Rainer Orth
PR fortran/54932
* gfortran.dg/do_1.f90: Don't xfail.
# HG changeset patch
# Parent 1f55250777e2b41e8669c029843210c76bf9e40d
Don't XFAIL gfortran.dg/do_1.f90 (PR fortran/54932)
diff --git a/gcc/testsuite/gfortran.dg/do_1.f90 b/gcc/testsuite/gfortran.dg/do_1.f90
--- a/gcc/testsuite/gfortran.dg/do_1.f90
+++ b/gcc/testsuite/gfortran.dg/do_1.f90
@@ -1,5 +1,4 @@
-! { dg-do run { xfail *-*-* } }
-! XFAIL is tracked in PR 54932
+! { dg-do run }
! Program to check corner cases for DO statements.
program do_1
implicit none
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
[PATCH][RFC] Remove TODO_ggc_collect, collect unconditionally
This adds a GC collection point after each pass instead just after those with TODO_ggc_collect in their todo. The patch will possibly slow-down gcac checking a bit (80 passes have TODO_ggc_collect, I didn't try to enumerate those that do not, but a grep shows we may have up to 212 passes. OTOH gcac checking will now "properly" verify that all pass boundaries are suitable for collection. A complete patch will remove TODO_ggc_collect and all its uses as well. The patch should result in lower peak memory consumption for some of the odd testcases that we worked on. Bootstrap & regtest scheduled on x86_64-unknown-linux-gnu. Richard. 2013-03-19 Richard Biener * passes.c (execute_todo): Do not call ggc_collect conditional here. (execute_one_ipa_transform_pass): But unconditionally here. (execute_one_pass): And here. Index: trunk/gcc/passes.c === *** trunk.orig/gcc/passes.c 2013-03-19 12:25:46.0 +0100 --- trunk/gcc/passes.c 2013-03-19 13:25:49.757259321 +0100 *** execute_todo (unsigned int flags) *** 2016,2024 fflush (dump_file); } - if (flags & TODO_ggc_collect) - ggc_collect (); - /* Now that the dumping has been done, we can get rid of the optional df problems. */ if (flags & TODO_df_finish) --- 2016,2021 *** execute_one_ipa_transform_pass (struct c *** 2190,2195 --- 2187,2195 pass_fini_dump_file (pass); current_pass = NULL; + + /* Signal this is a suitable GC collection point. */ + ggc_collect (); } /* For the current function, execute all ipa transforms. */ *** execute_one_pass (struct opt_pass *pass) *** 2367,2372 --- 2367,2375 current_pass = NULL; + /* Signal this is a suitable GC collection point. */ + ggc_collect (); + return true; }
[build] Default to DWARF 4 on Solaris if linker supports CIEv3
As described in
Don't use DWARF 4 on Solaris
http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00445.html
the Solaris linker couldn't handle CIEv3 in .eh_frame, so we defaulted
to DWARF 2 on Solaris in any configuration (Sun or GNU ld). This has
changed in Solaris 11.1, where the necessary support was added. The
following patch checks for this and defaults to DWARF 4 if either a
sufficiently recent Sun ld or GNU ld >= 2.16 is used.
Bootstrapped without regressions on i386-pc-solaris2.11 (Solaris 11.1)
with Sun ld and gld 2.23.1, and on i386-pc-solaris2.10 with Sun ld.
Ok for mainline?
Rainer
2013-03-18 Rainer Orth
* configure.ac (gcc_cv_ld_eh_frame_ciev3): New test.
* configure: Regenerate.
* config.in: Regenerate.
* config/sol2.c (solaris_override_options): Only enforce DWARF 2
if !HAVE_LD_EH_FRAME_CIEV3.
# HG changeset patch
# Parent 3a306dae3cef5064a01f87c8a575de5e630d3412
Default to DWARF 4 on Solaris if linker supports CIEv3
diff --git a/gcc/config/sol2.c b/gcc/config/sol2.c
--- a/gcc/config/sol2.c
+++ b/gcc/config/sol2.c
@@ -286,8 +286,8 @@ solaris_file_end (void)
void
solaris_override_options (void)
{
- /* Don't emit DWARF3/4 unless specifically selected. Solaris ld cannot
- handle CIE version 3 in .eh_frame. */
- if (!global_options_set.x_dwarf_version)
+ /* Older versions of Solaris ld cannot handle CIE version 3 in .eh_frame.
+ Don't emit DWARF3/4 unless specifically selected if so. */
+ if (!HAVE_LD_EH_FRAME_CIEV3 && !global_options_set.x_dwarf_version)
dwarf_version = 2;
}
diff --git a/gcc/configure.ac b/gcc/configure.ac
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -4335,6 +4335,42 @@ if test x"$gcc_cv_ld_eh_frame_hdr" = xye
fi
AC_MSG_RESULT($gcc_cv_ld_eh_frame_hdr)
+AC_MSG_CHECKING(linker CIEv3 in .eh_frame support)
+gcc_cv_ld_eh_frame_ciev3=no
+if test $in_tree_ld = yes ; then
+ if test "$gcc_cv_gld_major_version" -eq 2 -a "$gcc_cv_gld_minor_version" -ge 16 -o "$gcc_cv_gld_major_version" -gt 2 \
+ && test $in_tree_ld_is_elf = yes; then
+gcc_cv_ld_eh_frame_ciev3=yes
+ fi
+elif test x$gcc_cv_ld != x; then
+ if echo "$ld_ver" | grep GNU > /dev/null; then
+gcc_cv_ld_eh_frame_ciev3=yes
+if test 0"$ld_date" -lt 20040513; then
+ if test -n "$ld_date"; then
+ # If there was date string, but was earlier than 2004-05-13, fail
+ gcc_cv_ld_eh_frame_ciev3=no
+ elif test "$ld_vers_major" -lt 2; then
+ gcc_cv_ld_eh_frame_ciev3=no
+ elif test "$ld_vers_major" -eq 2 -a "$ld_vers_minor" -lt 16; then
+ gcc_cv_ld_eh_frame_ciev3=no
+ fi
+fi
+ else
+case "$target" in
+ *-*-solaris2*)
+# Sun ld added support for CIE v3 in .eh_frame in Solaris 11.1.
+if test "$ld_vers_major" -gt 1 || test "$ld_vers_minor" -ge 2324; then
+ gcc_cv_ld_eh_frame_ciev3=yes
+fi
+;;
+esac
+ fi
+fi
+AC_DEFINE_UNQUOTED(HAVE_LD_EH_FRAME_CIEV3,
+ [`if test x"$gcc_cv_ld_eh_frame_ciev3" = xyes; then echo 1; else echo 0; fi`],
+ [Define 0/1 if your linker supports CIE v3 in .eh_frame.])
+AC_MSG_RESULT($gcc_cv_ld_eh_frame_ciev3)
+
AC_MSG_CHECKING(linker position independent executable support)
gcc_cv_ld_pie=no
if test $in_tree_ld = yes ; then
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
[PATCH] Streamline loop verifier, make it less prone to ICE
The following fixes the most annoying ICE during loop verification
(get_loop_body ICEing) and re-structures things a bit. It also
fixes an ICE that occurs when trying to graph a corrupt loop tree
(I'm using that heavily, and ICEing within the graphing is
annoying - this doesn't fix the corresponding get_loop_body ICE there)
Bootstrapped and tested on x86_64-unknown-linux-gnu.
Richard.
2013-03-19 Richard Biener
* cfgloop.c (verify_loop_structure): Streamline and avoid
ICEing on corrupt loop tree.
* graph.c (draw_cfg_nodes_for_loop): Avoid ICEing on corrupt
loop tree.
Index: gcc/cfgloop.c
===
--- gcc/cfgloop.c (revision 196784)
+++ gcc/cfgloop.c (working copy)
@@ -1319,7 +1319,7 @@ verify_loop_structure (void)
{
unsigned *sizes, i, j;
sbitmap irreds;
- basic_block bb;
+ basic_block bb, *bbs;
struct loop *loop;
int err = 0;
edge e;
@@ -1335,43 +1335,51 @@ verify_loop_structure (void)
else
verify_dominators (CDI_DOMINATORS);
- /* Check sizes. */
- sizes = XCNEWVEC (unsigned, num);
- sizes[0] = 2;
-
- FOR_EACH_BB (bb)
-for (loop = bb->loop_father; loop; loop = loop_outer (loop))
- sizes[loop->num]++;
-
- FOR_EACH_LOOP (li, loop, LI_INCLUDE_ROOT)
-{
- i = loop->num;
-
- if (loop->num_nodes != sizes[i])
- {
- error ("size of loop %d should be %d, not %d",
- i, sizes[i], loop->num_nodes);
- err = 1;
- }
-}
-
/* Check the headers. */
FOR_EACH_BB (bb)
-if (bb_loop_header_p (bb)
- && bb->loop_father->header != bb)
+if (bb_loop_header_p (bb))
+ {
+ if (bb->loop_father->header == NULL)
+ {
+ error ("loop with header %d marked for removal", bb->index);
+ err = 1;
+ }
+ else if (bb->loop_father->header != bb)
+ {
+ error ("loop with header %d not in loop tree", bb->index);
+ err = 1;
+ }
+ }
+else if (bb->loop_father->header == bb)
{
- error ("loop with header %d not in loop tree", bb->index);
+ error ("non-loop with header %d not marked for removal", bb->index);
err = 1;
}
- /* Check get_loop_body. */
+ /* Check the recorded loop father and sizes of loops. */
visited = sbitmap_alloc (last_basic_block);
bitmap_clear (visited);
+ bbs = XNEWVEC (basic_block, n_basic_blocks);
FOR_EACH_LOOP (li, loop, LI_FROM_INNERMOST)
{
- basic_block *bbs = get_loop_body (loop);
+ unsigned n;
- for (j = 0; j < loop->num_nodes; j++)
+ if (loop->header == NULL)
+ {
+ error ("removed loop %d in loop tree", loop->num);
+ err = 1;
+ continue;
+ }
+
+ n = get_loop_body_with_size (loop, bbs, n_basic_blocks);
+ if (loop->num_nodes != n)
+ {
+ error ("size of loop %d should be %d, not %d",
+loop->num, n, loop->num_nodes);
+ err = 1;
+ }
+
+ for (j = 0; j < n; j++)
{
bb = bbs[j];
@@ -1394,16 +1402,16 @@ verify_loop_structure (void)
err = 1;
}
}
-
- free (bbs);
}
+ free (bbs);
sbitmap_free (visited);
/* Check headers and latches. */
FOR_EACH_LOOP (li, loop, 0)
{
i = loop->num;
-
+ if (loop->header == NULL)
+ continue;
if (!bb_loop_header_p (loop->header))
{
error ("loop %d%'s header is not a loop header", i);
@@ -1561,6 +1569,7 @@ verify_loop_structure (void)
{
unsigned n_exits = 0, eloops;
+ sizes = XCNEWVEC (unsigned, num);
memset (sizes, 0, sizeof (unsigned) * num);
FOR_EACH_BB (bb)
{
@@ -1624,11 +1633,12 @@ verify_loop_structure (void)
err = 1;
}
}
+
+ free (sizes);
}
gcc_assert (!err);
- free (sizes);
if (!dom_available)
free_dominance_info (CDI_DOMINATORS);
}
Index: gcc/graph.c
===
--- gcc/graph.c (revision 196784)
+++ gcc/graph.c (working copy)
@@ -213,7 +213,8 @@ draw_cfg_nodes_for_loop (pretty_printer
unsigned int i;
const char *fillcolors[3] = { "grey88", "grey77", "grey66" };
- if (loop->latch != EXIT_BLOCK_PTR)
+ if (loop->header != NULL
+ && loop->latch != EXIT_BLOCK_PTR)
pp_printf (pp,
"\tsubgraph cluster_%d_%d {\n"
"\tstyle=\"filled\";\n"
@@ -229,6 +230,9 @@ draw_cfg_nodes_for_loop (pretty_printer
for (struct loop *inner = loop->inner; inner; inner = inner->next)
draw_cfg_nodes_for_loop (pp, funcdef_no, inner);
+ if (loop->header == NULL)
+return;
+
if (loop->latch == EXIT_BLOCK_PTR)
body = get_loop_body (loop);
else
Re: [Patch, libfortran] Get rid of "enum try"
On Fri, Jan 18, 2013 at 1:32 AM, Steve Kargl wrote: > On Fri, Jan 18, 2013 at 01:19:37AM +0200, Janne Blomqvist wrote: >> >> the attached patch gets rid of the "enum try" in the Fortran runtime >> library, replacing its usage with the standard C99 _Bool/bool. >> >> Regtested on x86_64-unknown-linux-gnu, Ok for trunk? >> >> 2013-01-18 Janne Blomqvist >> >> * libgfortran.h: Include stdbool.h. >> (enum try): Remove. >> (notify_std): Change return type to bool. >> * intrinsics/chmod.c: Don't include stdbool.h. >> * intrinsics/execute_command_line.c: Likewise. >> * io/format.c: Likewise. >> * io/list_read.c (nml_parse_qualifier): Change return type to bool. >> (nml_read_obj): Likewise. >> (nml_get_obj_data): Likewise. >> * io/transfer.c (read_block_form): Fix comment. >> (write_buf): Change return type to bool. >> * io/write.c: Don't include stdbool.h. >> * io/write_float.def (output_float): Change return type to bool. >> (output_float_FMT_G_ ## x): Change type of result variable. >> * runtime/error.c (notify_std): Change return type to bool. >> >> > > The patch looks fine to me. As this doesn't fix a regression > or documentation, you may want to wait for trunk to re-open > before applying the patch (or ask RM). Thanks for the review. Committed to trunk (4.9), now that it's re-opened, as r196791. -- Janne Blomqvist
Re: [Patch, libfortran, 2nd version] PR 48618 - Negative unit number in OPEN(...) is sometimes allowed
Am 07.03.2013 17:35, schrieb Tilo Schwarz: On Thu, 07 Mar 2013 12:46:10 +0100, Tobias Burnus wrote: Tilo Schwarz wrote: this patch fixes PR 48618. Built and regtested on Linux 3.2.0-4-686-pae. Thanks for the patch, which mostly looks okay. A few remarks: Thank you for the feedback. I incorporated all remarks into the new attached patch. The patch looks good and is okay for the 4.9 trunk. Thanks for your efforts! If you commit yourself, you need to recall to split the ChangeLog into the parts which go into libgfortran/ChangeLog and gcc/testsuite/ChangeLog. For the commit log, use "svn log|less" to see what others do for the commit log. If you want me to commit this (and the other) patch instead, please tell me. Tobias
Re: [PATCH 2/n, i386]: Merge TImode and DImode move patterns
On Tue, Mar 19, 2013 at 9:35 AM, Jakub Jelinek wrote:
>> Attached patch merges TImode and DImode move patterns using x64 and
>> nox64 isa attributes.
>>
>> 2013-03-19 Uros Bizjak
>>
>> * config/i386/i386.md (*movti_internal): Merge from
>> *movti_internal_rex64 and *movti_internal_sse. Use x64 isa attribute.
>> (*movdi_internal): Merge with *movdi_internal_rex64. Use x64 and
>> nox64 isa attributes.
>>
>> Tested on x86_64-pc-linux-gnu {,-m32}, committed to mainline.
>
> Please don't commit to SVN yet, e.g. gcc-cvs doesn't seem to be working
> at all this morning.
Eh, I already committed the patch, I was not aware that mailing lists
are not functional. OTOH, I hope that messages to MLs are queued
somewhere and will be handled appropriately when servers work again.
Sorry for troubles :(
Uros.
Re: [PATCH] Exchange late VRP and DOM passes
On Mon, 18 Mar 2013, Richard Biener wrote:
>
> This moves VRP after late DOM. This is because VRP has a hard
> time dealing with non-copyproped (and not CSEd) IL and conveniently
> DOM provides both. I noticed this when working on PR56273 where
> we miss quite some VRP opportunities because of this.
> I cannot think of a good reason to have the current order, so I am
> going ahead with this after SVN is back.
>
> Bootstrap and regtest running on x86_64-unknown-linux-gnu.
>
> While I have the patch in my tree for quite a while I don't
> remember testing it, so the patch may get some additional
> testsuite fallout changes.
Not much - I had to adjust gcc.dg/tree-ssa/vrp47.c and
c-c++-common/uninit-17.c for which I also filed a bug
(reported locations are rather random, this time changing from
the not-expected to another not-expected one).
Will commit after new gcc.gnu.org has settled a bit.
Richard.
2013-03-18 Richard Biener
PR tree-optimization/56273
* passes.c (init_optimization_passes): Move second VRP after DOM.
* gcc.dg/tree-ssa/vrp47.c: Adjust.
* c-c++-common/uninit-17.c: Likewise.
Index: gcc/passes.c
===
*** gcc/passes.c.orig 2013-03-18 14:27:05.0 +0100
--- gcc/passes.c2013-03-18 14:33:08.745959939 +0100
*** init_optimization_passes (void)
*** 1488,1494
NEXT_PASS (pass_lower_vector_ssa);
NEXT_PASS (pass_cse_reciprocals);
NEXT_PASS (pass_reassoc);
- NEXT_PASS (pass_vrp);
NEXT_PASS (pass_strength_reduction);
NEXT_PASS (pass_dominator);
/* The only const/copy propagation opportunities left after
--- 1488,1493
*** init_optimization_passes (void)
*** 1497,1502
--- 1496,1502
only examines PHIs to discover const/copy propagation
opportunities. */
NEXT_PASS (pass_phi_only_cprop);
+ NEXT_PASS (pass_vrp);
NEXT_PASS (pass_cd_dce);
NEXT_PASS (pass_tracer);
Index: gcc/testsuite/gcc.dg/tree-ssa/vrp47.c
===
*** gcc/testsuite/gcc.dg/tree-ssa/vrp47.c.orig 2013-03-18 14:27:05.0
+0100
--- gcc/testsuite/gcc.dg/tree-ssa/vrp47.c 2013-03-18 14:33:08.746959950
+0100
***
*** 4,10
jumps when evaluating an && condition. VRP is not able to optimize
this. */
/* { dg-do compile { target { ! "mips*-*-* s390*-*-* avr-*-* mn10300-*-*" }
} } */
! /* { dg-options "-O2 -fdump-tree-vrp1 -fdump-tree-dom1 -fdump-tree-dom2" } */
/* { dg-additional-options "-march=i586" { target { { i?86-*-* x86_64-*-* }
&& ia32 } } } */
/* Skip on ARM Cortex-M0, where LOGICAL_OP_NON_SHORT_CIRCUIT is set to false,
leading to two conditional jumps when evaluating an && condition. VRP is
--- 4,10
jumps when evaluating an && condition. VRP is not able to optimize
this. */
/* { dg-do compile { target { ! "mips*-*-* s390*-*-* avr-*-* mn10300-*-*" }
} } */
! /* { dg-options "-O2 -fdump-tree-vrp1 -fdump-tree-dom1 -fdump-tree-vrp2" } */
/* { dg-additional-options "-march=i586" { target { { i?86-*-* x86_64-*-* }
&& ia32 } } } */
/* Skip on ARM Cortex-M0, where LOGICAL_OP_NON_SHORT_CIRCUIT is set to false,
leading to two conditional jumps when evaluating an && condition. VRP is
*** int f(int x)
*** 40,54
0 or 1. */
/* { dg-final { scan-tree-dump-times "\[xy\]\[^ \]* !=" 0 "vrp1" } } */
! /* This one needs more copy propagation that only happens in dom1. */
! /* { dg-final { scan-tree-dump-times "x\[^ \]* & y" 1 "dom1" { xfail *-*-* }
} } */
! /* { dg-final { scan-tree-dump-times "x\[^ \]* & y" 1 "dom2" } } */
! /* { dg-final { scan-tree-dump-times "x\[^ \]* & y" 1 "vrp1" { xfail *-*-* }
} } */
!
! /* These two are fully simplified by VRP. */
/* { dg-final { scan-tree-dump-times "x\[^ \]* \[|\] y" 1 "vrp1" } } */
/* { dg-final { scan-tree-dump-times "x\[^ \]* \\^ 1" 1 "vrp1" } } */
/* { dg-final { cleanup-tree-dump "vrp1" } } */
/* { dg-final { cleanup-tree-dump "dom1" } } */
! /* { dg-final { cleanup-tree-dump "dom2" } } */
--- 40,53
0 or 1. */
/* { dg-final { scan-tree-dump-times "\[xy\]\[^ \]* !=" 0 "vrp1" } } */
! /* These two are fully simplified by VRP1. */
/* { dg-final { scan-tree-dump-times "x\[^ \]* \[|\] y" 1 "vrp1" } } */
/* { dg-final { scan-tree-dump-times "x\[^ \]* \\^ 1" 1 "vrp1" } } */
+ /* VRP2 gets rid of the remaining & 1 operations, x and y are always
+either 0 or 1. */
+ /* { dg-final { scan-tree-dump-times " & 1;" 0 "vrp2" } } */
+
/* { dg-final { cleanup-tree-dump "vrp1" } } */
/* { dg-final { cleanup-tree-dump "dom1" } } */
! /* { dg-final { cleanup-tree-dump "vrp2" } } */
Index: gcc/testsuite/c-c++-common/uninit-17.c
===
*** gcc/testsuite/c-c++-common/uninit-17.c.orig 2010-09-
[PATCH, ARM] Extend uclinux LINK_GCC_C_SEQUENCE_SPEC
Hi,
libstdc++ configure will check "shl_load". If shared library is disabled in
gcc and uclibc configure, the libstdc++ configure will fail for options like
-mthumb -march=armv7-r. The fail logs like:
.../libgcc.a(unwind-arm.o): In function `unwind_phase2_forced':
unwind-arm.c:(.text+0x282): undefined reference to `memcpy'
unwind-arm.c:(.text+0x2b0): undefined reference to `memcpy'
collect2: error: ld returned 1 exit status
Logs show uclibc depends on "__aeabi_unwind_cpp_pr1" from libgcc. And
unwind_phase2_forced from libgcc depends on memcpy from uclibc. So an
additional %L is required for non-static link.
Is it OK for trunk?
Thanks!
-Zhenqiang
2013-03-19 Zhenqiang Chen
* config/arm/uclinux-elf.h: Add %L to LINK_GCC_C_SEQUENCE_SPEC for
non- static link
diff --git a/gcc/config/arm/uclinux-elf.h b/gcc/config/arm/uclinux-elf.h
index c1fe9f1..74d63df 100644
--- a/gcc/config/arm/uclinux-elf.h
+++ b/gcc/config/arm/uclinux-elf.h
@@ -65,7 +65,7 @@
#undef LINK_GCC_C_SEQUENCE_SPEC
#define LINK_GCC_C_SEQUENCE_SPEC \
- "%{static:--start-group} %G %L %{static:--end-group}%{!static:%G}"
+ "%{static:--start-group} %G %L %{static:--end-group}%{!static:%G %L}"
/* Use --as-needed -lgcc_s for eh support. */ #ifdef HAVE_LD_AS_NEEDED
Re: [PATCH 2/n, i386]: Merge TImode and DImode move patterns
On Tue, Mar 19, 2013 at 08:40:04AM +0100, Uros Bizjak wrote:
> Attached patch merges TImode and DImode move patterns using x64 and
> nox64 isa attributes.
>
> 2013-03-19 Uros Bizjak
>
> * config/i386/i386.md (*movti_internal): Merge from
> *movti_internal_rex64 and *movti_internal_sse. Use x64 isa attribute.
> (*movdi_internal): Merge with *movdi_internal_rex64. Use x64 and
> nox64 isa attributes.
>
> Tested on x86_64-pc-linux-gnu {,-m32}, committed to mainline.
Please don't commit to SVN yet, e.g. gcc-cvs doesn't seem to be working
at all this morning.
Jakub
Re: Fold VEC_COND_EXPR to abs, min, max
Hello,
new version of the patch. Note that for the simplification from
{-1,-1}?a:b to a, I removed the test that b has no side effects and call
pedantic_omit_one_operand_loc instead.
Bootstrap + testsuite on x86_64-linux-gnu.
2013-03-19 Marc Glisse
gcc/
* tree.h (VECTOR_TYPE_P): New macro.
(VECTOR_INTEGER_TYPE_P, VECTOR_FLOAT_TYPE_P, FLOAT_TYPE_P,
TYPE_MODE): Use it.
* fold-const.c (fold_cond_expr_with_comparison): Use build_zero_cst.
VEC_COND_EXPR cannot be lvalues.
(fold_ternary_loc) : Merge with the COND_EXPR case.
gcc/cp/
* call.c (build_conditional_expr_1): Fold VEC_COND_EXPR.
gcc/testsuite/
* g++.dg/ext/vector21.C: New testcase.
--
Marc GlisseIndex: gcc/testsuite/g++.dg/ext/vector21.C
===
--- gcc/testsuite/g++.dg/ext/vector21.C (revision 0)
+++ gcc/testsuite/g++.dg/ext/vector21.C (revision 0)
@@ -0,0 +1,39 @@
+/* { dg-do compile } */
+/* { dg-options "-O -fdump-tree-gimple" } */
+
+typedef int vec __attribute__ ((vector_size (4 * sizeof (int;
+
+void f1 (vec *x)
+{
+ *x = (*x >= 0) ? *x : -*x;
+}
+void f2 (vec *x)
+{
+ *x = (0 < *x) ? *x : -*x;
+}
+void g1 (vec *x)
+{
+ *x = (*x < 0) ? -*x : *x;
+}
+void g2 (vec *x)
+{
+ *x = (0 > *x) ? -*x : *x;
+}
+void h (vec *x, vec *y)
+{
+ *x = (*x < *y) ? *y : *x;
+}
+void i (vec *x, vec *y)
+{
+ *x = (*x < *y) ? *x : *y;
+}
+void j (vec *x, vec *y)
+{
+ *x = (*x < *y) ? *x : *x;
+}
+
+/* { dg-final { scan-tree-dump-times "ABS_EXPR" 4 "gimple" } } */
+/* { dg-final { scan-tree-dump "MIN_EXPR" "gimple" } } */
+/* { dg-final { scan-tree-dump "MAX_EXPR" "gimple" } } */
+/* { dg-final { scan-tree-dump-not "VEC_COND_EXPR" "gimple" } } */
+/* { dg-final { cleanup-tree-dump "gimple" } } */
Property changes on: gcc/testsuite/g++.dg/ext/vector21.C
___
Added: svn:eol-style
+ native
Added: svn:keywords
+ Author Date Id Revision URL
Index: gcc/cp/call.c
===
--- gcc/cp/call.c (revision 196748)
+++ gcc/cp/call.c (working copy)
@@ -4430,23 +4430,23 @@ build_conditional_expr_1 (tree arg1, tre
|| TYPE_SIZE (arg1_type) != TYPE_SIZE (arg2_type))
{
if (complain & tf_error)
error ("incompatible vector types in conditional expression: "
"%qT, %qT and %qT", TREE_TYPE (arg1), TREE_TYPE (orig_arg2),
TREE_TYPE (orig_arg3));
return error_mark_node;
}
if (!COMPARISON_CLASS_P (arg1))
- arg1 = build2 (NE_EXPR, signed_type_for (arg1_type), arg1,
+ arg1 = fold_build2 (NE_EXPR, signed_type_for (arg1_type), arg1,
build_zero_cst (arg1_type));
- return build3 (VEC_COND_EXPR, arg2_type, arg1, arg2, arg3);
+ return fold_build3 (VEC_COND_EXPR, arg2_type, arg1, arg2, arg3);
}
/* [expr.cond]
The first expression is implicitly converted to bool (clause
_conv_). */
arg1 = perform_implicit_conversion_flags (boolean_type_node, arg1, complain,
LOOKUP_NORMAL);
if (error_operand_p (arg1))
return error_mark_node;
Index: gcc/tree.h
===
--- gcc/tree.h (revision 196748)
+++ gcc/tree.h (working copy)
@@ -974,20 +974,24 @@ extern void omp_clause_range_check_faile
&& (TREE_TYPE (EXP)\
== TREE_TYPE (TREE_OPERAND (EXP, 0 \
(EXP) = TREE_OPERAND (EXP, 0)
/* Remove unnecessary type conversions according to
tree_ssa_useless_type_conversion. */
#define STRIP_USELESS_TYPE_CONVERSION(EXP) \
(EXP) = tree_ssa_strip_useless_type_conversions (EXP)
+/* Nonzero if TYPE represents a vector type. */
+
+#define VECTOR_TYPE_P(TYPE) (TREE_CODE (TYPE) == VECTOR_TYPE)
+
/* Nonzero if TYPE represents an integral type. Note that we do not
include COMPLEX types here. Keep these checks in ascending code
order. */
#define INTEGRAL_TYPE_P(TYPE) \
(TREE_CODE (TYPE) == ENUMERAL_TYPE \
|| TREE_CODE (TYPE) == BOOLEAN_TYPE \
|| TREE_CODE (TYPE) == INTEGER_TYPE)
/* Nonzero if TYPE represents a non-saturating fixed-point type. */
@@ -1009,39 +1013,39 @@ extern void omp_clause_range_check_faile
#define SCALAR_FLOAT_TYPE_P(TYPE) (TREE_CODE (TYPE) == REAL_TYPE)
/* Nonzero if TYPE represents a complex floating-point type. */
#define COMPLEX_FLOAT_TYPE_P(TYPE) \
(TREE_CODE (TYPE) == COMPLEX_TYPE\
&& TREE_CODE (TREE_TYPE (TYPE)) == REAL_TYPE)
/* Nonzero if TYPE represents a vector integer type. */
-#define VECTOR_INTEGER_TYPE_P(TYPE) \
- (TREE_CODE (TYPE) == VECTOR_TYPE \
- && TREE_CODE (TREE_TYPE (TYPE)) == INTEGER_TYPE)
+#define VECTOR_INTEGER_TY
[PATCH 2/n, i386]: Merge TImode and DImode move patterns
Hello!
Attached patch merges TImode and DImode move patterns using x64 and
nox64 isa attributes.
2013-03-19 Uros Bizjak
* config/i386/i386.md (*movti_internal): Merge from
*movti_internal_rex64 and *movti_internal_sse. Use x64 isa attribute.
(*movdi_internal): Merge with *movdi_internal_rex64. Use x64 and
nox64 isa attributes.
Tested on x86_64-pc-linux-gnu {,-m32}, committed to mainline.
Uros.
Index: i386.md
===
--- i386.md (revision 196757)
+++ i386.md (working copy)
@@ -1656,6 +1656,40 @@
;; Move instructions.
+;; Reload patterns to support multi-word load/store
+;; with non-offsetable address.
+(define_expand "reload_noff_store"
+ [(parallel [(match_operand 0 "memory_operand" "=m")
+ (match_operand 1 "register_operand" "r")
+ (match_operand:DI 2 "register_operand" "=&r")])]
+ "TARGET_64BIT"
+{
+ rtx mem = operands[0];
+ rtx addr = XEXP (mem, 0);
+
+ emit_move_insn (operands[2], addr);
+ mem = replace_equiv_address_nv (mem, operands[2]);
+
+ emit_insn (gen_rtx_SET (VOIDmode, mem, operands[1]));
+ DONE;
+})
+
+(define_expand "reload_noff_load"
+ [(parallel [(match_operand 0 "register_operand" "=r")
+ (match_operand 1 "memory_operand" "m")
+ (match_operand:DI 2 "register_operand" "=r")])]
+ "TARGET_64BIT"
+{
+ rtx mem = operands[1];
+ rtx addr = XEXP (mem, 0);
+
+ emit_move_insn (operands[2], addr);
+ mem = replace_equiv_address_nv (mem, operands[2]);
+
+ emit_insn (gen_rtx_SET (VOIDmode, operands[0], mem));
+ DONE;
+})
+
(define_expand "movoi"
[(set (match_operand:OI 0 "nonimmediate_operand")
(match_operand:OI 1 "general_operand"))]
@@ -1760,10 +1794,11 @@
]
(const_string "OI")))])
-(define_insn "*movti_internal_rex64"
+(define_insn "*movti_internal"
[(set (match_operand:TI 0 "nonimmediate_operand" "=!r ,o ,x,x ,m")
(match_operand:TI 1 "general_operand" "riFo,re,C,xm,x"))]
- "TARGET_64BIT && !(MEM_P (operands[0]) && MEM_P (operands[1]))"
+ "(TARGET_64BIT || TARGET_SSE)
+ && !(MEM_P (operands[0]) && MEM_P (operands[1]))"
{
switch (which_alternative)
{
@@ -1795,12 +1830,14 @@
gcc_unreachable ();
}
}
- [(set_attr "type" "*,*,sselog1,ssemov,ssemov")
+ [(set_attr "isa" "x64,x64,*,*,*")
+ (set_attr "type" "*,*,sselog1,ssemov,ssemov")
(set_attr "prefix" "*,*,maybe_vex,maybe_vex,maybe_vex")
(set (attr "mode")
(cond [(eq_attr "alternative" "0,1")
(const_string "DI")
- (match_test "TARGET_SSE_PACKED_SINGLE_INSN_OPTIMAL")
+ (ior (not (match_test "TARGET_SSE2"))
+ (match_test "TARGET_SSE_PACKED_SINGLE_INSN_OPTIMAL"))
(const_string "V4SF")
(and (eq_attr "alternative" "4")
(match_test "TARGET_SSE_TYPELESS_STORES"))
@@ -1820,82 +1857,21 @@
[(const_int 0)]
"ix86_split_long_move (operands); DONE;")
-(define_insn "*movti_internal_sse"
- [(set (match_operand:TI 0 "nonimmediate_operand" "=x,x ,m")
- (match_operand:TI 1 "vector_move_operand" "C ,xm,x"))]
- "TARGET_SSE && !TARGET_64BIT
- && !(MEM_P (operands[0]) && MEM_P (operands[1]))"
-{
- switch (which_alternative)
-{
-case 0:
- return standard_sse_constant_opcode (insn, operands[1]);
-case 1:
-case 2:
- /* TDmode values are passed as TImode on the stack. Moving them
-to stack may result in unaligned memory access. */
- if (misaligned_operand (operands[0], TImode)
- || misaligned_operand (operands[1], TImode))
- {
- if (get_attr_mode (insn) == MODE_V4SF)
- return "%vmovups\t{%1, %0|%0, %1}";
- else
- return "%vmovdqu\t{%1, %0|%0, %1}";
- }
- else
- {
- if (get_attr_mode (insn) == MODE_V4SF)
- return "%vmovaps\t{%1, %0|%0, %1}";
- else
- return "%vmovdqa\t{%1, %0|%0, %1}";
- }
-default:
- gcc_unreachable ();
-}
-}
- [(set_attr "type" "sselog1,ssemov,ssemov")
- (set_attr "prefix" "maybe_vex")
- (set (attr "mode")
- (cond [(match_test "TARGET_SSE_PACKED_SINGLE_INSN_OPTIMAL")
-(const_string "V4SF")
- (and (eq_attr "alternative" "2")
- (match_test "TARGET_SSE_TYPELESS_STORES"))
-(const_string "V4SF")
- (match_test "TARGET_AVX")
-(const_string "TI")
- (ior (not (match_test "TARGET_SSE2"))
- (match_test "optimize_function_for_size_p (cfun)"))
-(const_string "V4SF")
- ]
- (const_string "TI")))])
-
-(define_insn "*movdi_internal_rex64"
+(define_insn "*movdi_internal"
[(set (match_operand:DI 0 "nonimmediate_operand"
- "=r,r ,r,m ,*y,m*y,?*y,?r ,?*Ym,*x,m ,*x,*x,?r ,?*Yi,?*x,?*Ym")
+"=r ,o ,r,r ,r,m ,*y,m*y,*y,?*y,?r ,
Re: [PING^5] PR 54805: __gthread_tsd* in vxlib-tls.c
On 19/03/2013, at 3:38 PM, rbmj wrote: > On 16-Feb-13 23:21, Maxim Kuvyrkov wrote: >> On 14/02/2013, at 10:18 AM, rbmj wrote: >>> Here's the updated, (trivial) patch. >> >> Thanks. I'll apply this once 4.8 branches and trunk is back into >> development mode. >> > > Since GCC 4.9 has branched now are you still willing to commit (maybe after > the outage is over; I don't know the state of the svn server)? > > One of my friends has also commented that the warning that this fixes causes > the launchpad PPA system to reject the package (based on the build log), so > is it possible for this to apply in 4.8.1 also? I don't know how that > process works, I assume I'd have to wait until after 4.8.0 officially > releases. I understand that it's way too late for 4.8.0 (_trivial_ as the > fix is) :( > > Suggested ChangeLog: > > [libgcc] > Robert Mason > * config/vxlib-tls.c: Add prototypes for __gthread_tsd*() Yes, this is on my list. I tried to commit your patch earlier today, but GCC server is currently being upgraded and is down. Will commit to trunk once the server is up. Regarding 4.8, we should've really tried to work it out earlier. If you want to pursue backport to 4.8, please attach the log of PPA system rejecting the package (fwiw, I don't quite understand which launchpad you are referring to). Thanks, -- Maxim Kuvyrkov KugelWorks
Re: [PATCH 1/4] Mark all member functions with memory models always inline
On Mon, Mar 18, 2013 at 04:28:13PM +, Jonathan Wakely wrote: > On 16 March 2013 13:29, Andi Kleen wrote: > > > > With inline __attribute__((always_inline)) these functions > > get inlined even with -O0. > > > > I hardcoded the attribute in the header for now, assuming > > that all compilers that support libstdc++ have attribute > > always_inline too. If not it would need to be moved > > as a macro to c++config.h with appropiate ifdefs. > > That should be fine. I assume __always_inline was chosen rather than > _GLIBCXX_ALWAYS_INLINE for consistency with glibc? Using __always_inline as the name of the macro is a bad idea, glibc headers use that macro already. Just use something else in public headers that aren't part of glibc. Jakub
