Re: C++ PATCHes relating to c++/48834, c++/40975 (array new)

[Eric Botcazou]

> How is it used in Ada?

The front-end doesn't use it directly, it's only used through the gimplifier 
by the unsharing phase (unshare_body).  We also have statement expressions.

-- 
Eric Botcazou

Re: Ping^4 Re: Target header etc. cleanup patch

[Nick Clifton]

Hi Joseph,


I have seen no comments from the mn10300 maintainers.
I think
abbreviating const char * is actively bad.  Cstar - defined for mn10300,
whose maintainers haven't commented


Whilst I am not a maintainer for the MN10300, I am the author of that 
bit of code.  I can say that I have no objections to removing the use of 
Cstar, it was just a syntactic shorthand, and not a very nice one at that.


If you do not get a response from Jeff or Alex you might like to ping 
rth, as he has been actively reviewing my recent MN10300 patches.


Cheers
  Nick

Re: [Patch, Fortran] PR18918: Implement THIS_IMAGE(coarray) for num_images() > 1

[Daniel Kraft]

On 05/02/11 23:24, Tobias Burnus wrote:

With this patch, now all coarray index intrinsics are implemented for
num_images() >= 1 - except for bugs.

Built and regtesting on x86-64-linux. The testcase was also tested with
-fcoarray=single and with -fcoarray=lib -lcaf_mpi with mpirun -n 8.
OK for the trunk?


Ok.  Thanks for the patch!

Yours,
Daniel



Tobias

PS: I would like to place the test case under gfortran.dg/coarray/;
however, the patch is still pending:
http://gcc.gnu.org/ml/fortran/2011-04/msg00331.html



--
http://www.pro-vegan.info/
--
Done:  Arc-Bar-Cav-Kni-Ran-Rog-Sam-Tou-Val-Wiz
To go: Hea-Mon-Pri

Re: [PATCH] Fix bt[lq] related miscompilation (PR target/48774)

[Uros Bizjak]

On Mon, May 2, 2011 at 10:16 PM, Jakub Jelinek  wrote:

> As written in the PR, the testcase in the patch is miscompiled on
> x86_64-linux, because during IRA a *btdi operand is changed from
> register to CONST_INT 1 (to which that register was initialized).
> Unfortunately when both 2nd and 3rd ZERO_EXTEND operands are constant
> integers, *testqi_ext_3{,_rex64} patterns match it wrongly too,
> but of course when splitting it into andl/q (which isn't desirable on
> TARGET_USE_BT targets anyway) using CCCmode is wrong, as the jump then
> looks at the carry bit set by bt{l,q}, while after and{l,q} the interesting
> bit is the zero flag.
>
> The following patch is one of the many possibilities to fix it,
> bootstrapped/regtested on x86_64-linux and i686-linux.
>
> Other options include just doing != CCCmode tests and remove the const1_rtx
> checks from the patch, or on the other side also testing TARGET_USE_BT ||
> -Os, or for the define_insn moving *bt pattern earlier (the splitter
> would still need guarding), or perhaps representing bt{l,q} insns
> differently in RTL.  I believe this bug is latent starting with 4.4,
> when *bt insn has been added.

IMO, this problem arises due to wrong fix for PR target/37184 [1] that
added CCA, CCC, CCO, CCS mode bypasses to ix86_match_ccmode.

We should make these new modes incompatible to every other requested
mode, so perhaps something like attached (totally untested) patch
fixes these problems in more general way.

Jakub, can you please check the patch, I'm not able to test it
properly until tonight.

[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37184

Thanks,
Uros.

Index: i386.c
===
--- i386.c  (revision 173287)
+++ i386.c  (working copy)
@@ -17299,11 +17299,15 @@ ix86_match_ccmode (rtx insn, enum machin
   if (req_mode == CCZmode)
return false;
   /* FALLTHRU */
+case CCZmode:
+  break;
+
 case CCAmode:
 case CCCmode:
 case CCOmode:
 case CCSmode:
-case CCZmode:
+  if (set_mode != req_mode)
+   return false;
   break;

 default:

Re: [testsuite] Compile gfortran.dg/fmt_g0_6.f08 with -ffloat-store

[Rainer Orth]

Jerry,

>> The failure vanishes with -ffloat-store, so I propose the following
>> patch, tested on i386-pc-solaris2.11 with the appropriate runtest
>> invocation.
>>
>> Ok for mainline?
>
> This is OK.  We are working on a solution, so maybe it would be better to
> XFAIL it so that when it does get fixed it will be flagged. It also fails
> on i686-pc-gnu.

is this a solution for this particular case or for the general need to
sometimes use -ffloat-store?  In the former case, I'd agree, in the
latter it's probably better to consistently use -ffloat-store in the
testcases and review those uses once a solution is in place.

I also saw the same failure on 32-bit Linux/x86, so the XFAIL would have
to be for { i?86-*-* x86_64-*-* } && ilp32.

Let me know what you prefer.

Thanks.
Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH][C] Change array size overflow check

[Richard Guenther]

On Mon, 2 May 2011, Joseph S. Myers wrote:

> On Mon, 2 May 2011, Richard Guenther wrote:
> 
> > We do have similar testcases in gcc.dg/large-size-array*.c, but not
> > exactly testing the bound.  The above testcase also complains with
> > -pedantic about
> > 
> > t.c:3:13: error: size of array 'a' is too large
> > t.c:4:1: error: overflow in constant expression [-Woverflow]
> > t.c:5:12: error: size of array 'c' is too large
> > t.c:6:1: error: overflow in constant expression [-Woverflow]
> > 
> > with and without the patch.  I can add -Wno-overflow to the flags.
> > Ok with that?
> 
> Those overflow errors are bugs (the tests have no overflowing constant 
> expression, it must be something the compiler is generating internally), 
> and it seems they only appear for 64-bit compilation for me, not for 
> 32-bit, for some reason.  But as they are independent of the patch, OK 
> with -Wno-overflow and with a PR filed for the bogus overflow errors.
> 
> (I get the overflow errors for a char array for a size of 
> ((size_t)-1 >> 4)+1 but not for ((size_t)-1 >> 4), i.e. 1ULL<<60 bytes is 
> the point where the bogus errors start.)

Committed as rev. 173297.  I filed PR48850 for the rejects-valid.

Richard.

Re: [patch][ARM] Fix 16-bit -> 64-bit multiply and accumulate

[Bernd Schmidt]

On 04/15/2011 12:54 PM, Andrew Stubbs wrote:
> Ping.

Trying to unblock this...

I think the point is that both examples:

long long foolong (long long x, short *a, short *b)
   {
   return x + (long long)*a * (long long)*b;
   }

and


  long long foolong (long long x, short *a, short *b)
  {
  return x + *a * *b;
  }

should produce the same code using the maddhidi pattern, and for that to
happen, simplify_rtx must produce a canonical form of the 16->64 bit
widening multiply. The form that already exists in arm.md looks better
so we should pick that.

I tried to fix it with the patch below, which unfortunately doesn't work
since during combine we don't see the SIGN_EXTEND operations inside the
MULT, but two shift operations instead. Maybe you can complete it from here?


Bernd
Index: gcc/simplify-rtx.c
===
--- gcc/simplify-rtx.c  (revision 173242)
+++ gcc/simplify-rtx.c  (working copy)
@@ -1000,6 +1000,23 @@ simplify_unary_operation_1 (enum rtx_cod
  && GET_CODE (XEXP (XEXP (op, 0), 1)) == LABEL_REF)
return XEXP (op, 0);
 
+  /* Extending a widening multiplication should be canonicalized to
+a wider widening multiplication.  */
+  if (GET_CODE (op) == MULT
+ && GET_CODE (XEXP (op, 0)) == SIGN_EXTEND
+ && GET_CODE (XEXP (op, 1)) == SIGN_EXTEND)
+   {
+ rtx op0 = XEXP (XEXP (op, 0), 0);
+ rtx op1 = XEXP (XEXP (op, 1), 0);
+ enum machine_mode op0_mode = GET_MODE (op0);
+ enum machine_mode op1_mode = GET_MODE (op1);
+ return simplify_gen_binary (MULT, mode,
+ simplify_gen_unary (SIGN_EXTEND, mode,
+ op0, op0_mode),
+ simplify_gen_unary (SIGN_EXTEND, mode,
+ op1, op1_mode));
+   }
+
   /* Check for a sign extension of a subreg of a promoted
 variable, where the promotion is sign-extended, and the
 target mode is the same as the variable's promotion.  */
@@ -1071,6 +1088,23 @@ simplify_unary_operation_1 (enum rtx_cod
  && GET_MODE_SIZE (mode) <= GET_MODE_SIZE (GET_MODE (XEXP (op, 0
return rtl_hooks.gen_lowpart_no_emit (mode, op);
 
+  /* Extending a widening multiplication should be canonicalized to
+a wider widening multiplication.  */
+  if (GET_CODE (op) == MULT
+ && GET_CODE (XEXP (op, 0)) == ZERO_EXTEND
+ && GET_CODE (XEXP (op, 1)) == ZERO_EXTEND)
+   {
+ rtx op0 = XEXP (XEXP (op, 0), 0);
+ rtx op1 = XEXP (XEXP (op, 1), 0);
+ enum machine_mode op0_mode = GET_MODE (op0);
+ enum machine_mode op1_mode = GET_MODE (op1);
+ return simplify_gen_binary (MULT, mode,
+ simplify_gen_unary (ZERO_EXTEND, mode,
+ op0, op0_mode),
+ simplify_gen_unary (ZERO_EXTEND, mode,
+ op1, op1_mode));
+   }
+
   /* (zero_extend:M (zero_extend:N )) is (zero_extend:M ).  */
   if (GET_CODE (op) == ZERO_EXTEND)
return simplify_gen_unary (ZERO_EXTEND, mode, XEXP (op, 0),

Re: bf54x support

[Henderson, Stuart]

ping


The attached patch adds support for silicon revision 0.4 of the bf54x family.


2011-02-17  Mike Frysinger  

   * gcc.target/bfin/mcpu-bf542.c: Check SILICON_REVISION is 0x0004.
   * gcc.target/bfin/mcpu-bf544.c, gcc.target/bfin/mcpu-bf547.c,
   gcc.target/bfin/mcpu-bf548.c, gcc.target/bfin/mcpu-bf549.c: Likewise.


2011-02-17  Mike Frysinger  

   * config/bfin/bfin.c (bfin_cpus[]): Add 0.4 for
   bf542/bf544/bf547/bf548/bf549.


Thanks,
Stu



Index: gcc/testsuite/gcc.target/bfin/mcpu-bf542.c
===
--- gcc/testsuite/gcc.target/bfin/mcpu-bf542.c  (revision 5257)
+++ gcc/testsuite/gcc.target/bfin/mcpu-bf542.c  (revision 5258)
@@ -10,8 +10,8 @@
 #error "__ADSPBF54x__ is not defined"
 #endif

-#if __SILICON_REVISION__ != 0x0002
-#error "__SILICON_REVISION__ is not 0x0002"
+#if __SILICON_REVISION__ != 0x0004
+#error "__SILICON_REVISION__ is not 0x0004"
 #endif

 #ifndef __WORKAROUNDS_ENABLED
Index: gcc/testsuite/gcc.target/bfin/mcpu-bf544.c
===
--- gcc/testsuite/gcc.target/bfin/mcpu-bf544.c  (revision 5257)
+++ gcc/testsuite/gcc.target/bfin/mcpu-bf544.c  (revision 5258)
@@ -10,8 +10,8 @@
 #error "__ADSPBF54x__ is not defined"
 #endif

-#if __SILICON_REVISION__ != 0x0002
-#error "__SILICON_REVISION__ is not 0x0002"
+#if __SILICON_REVISION__ != 0x0004
+#error "__SILICON_REVISION__ is not 0x0004"
 #endif

 #ifndef __WORKAROUNDS_ENABLED
Index: gcc/testsuite/gcc.target/bfin/mcpu-bf547.c
===
--- gcc/testsuite/gcc.target/bfin/mcpu-bf547.c  (revision 5257)
+++ gcc/testsuite/gcc.target/bfin/mcpu-bf547.c  (revision 5258)
@@ -10,8 +10,8 @@
 #error "__ADSPBF54x__ is not defined"
 #endif

-#if __SILICON_REVISION__ != 0x0002
-#error "__SILICON_REVISION__ is not 0x0002"
+#if __SILICON_REVISION__ != 0x0004
+#error "__SILICON_REVISION__ is not 0x0004"
 #endif

 #ifndef __WORKAROUNDS_ENABLED
Index: gcc/testsuite/gcc.target/bfin/mcpu-bf548.c
===
--- gcc/testsuite/gcc.target/bfin/mcpu-bf548.c  (revision 5257)
+++ gcc/testsuite/gcc.target/bfin/mcpu-bf548.c  (revision 5258)
@@ -10,8 +10,8 @@
 #error "__ADSPBF54x__ is not defined"
 #endif

-#if __SILICON_REVISION__ != 0x0002
-#error "__SILICON_REVISION__ is not 0x0002"
+#if __SILICON_REVISION__ != 0x0004
+#error "__SILICON_REVISION__ is not 0x0004"
 #endif

 #ifndef __WORKAROUNDS_ENABLED
Index: gcc/testsuite/gcc.target/bfin/mcpu-bf549.c
===
--- gcc/testsuite/gcc.target/bfin/mcpu-bf549.c  (revision 5257)
+++ gcc/testsuite/gcc.target/bfin/mcpu-bf549.c  (revision 5258)
@@ -10,8 +10,8 @@
 #error "__ADSPBF54x__ is not defined"
 #endif

-#if __SILICON_REVISION__ != 0x0002
-#error "__SILICON_REVISION__ is not 0x0002"
+#if __SILICON_REVISION__ != 0x0004
+#error "__SILICON_REVISION__ is not 0x0004"
 #endif

 #ifndef __WORKAROUNDS_ENABLED
Index: gcc/config/bfin/bfin.c
===
--- gcc/config/bfin/bfin.c  (revision 5257)
+++ gcc/config/bfin/bfin.c  (revision 5258)
@@ -300,6 +300,8 @@
   {"bf542m", BFIN_CPU_BF542M, 0x0003,
WA_SPECULATIVE_LOADS | WA_INDIRECT_CALLS | WA_0574},

+  {"bf542", BFIN_CPU_BF542, 0x0004,
+   WA_SPECULATIVE_LOADS | WA_INDIRECT_CALLS | WA_0574},
   {"bf542", BFIN_CPU_BF542, 0x0002,
WA_SPECULATIVE_LOADS | WA_INDIRECT_CALLS | WA_0574},
   {"bf542", BFIN_CPU_BF542, 0x0001,
@@ -311,6 +313,8 @@
   {"bf544m", BFIN_CPU_BF544M, 0x0003,
WA_SPECULATIVE_LOADS | WA_INDIRECT_CALLS | WA_0574},

+  {"bf544", BFIN_CPU_BF544, 0x0004,
+   WA_SPECULATIVE_LOADS | WA_INDIRECT_CALLS | WA_0574},
   {"bf544", BFIN_CPU_BF544, 0x0002,
WA_SPECULATIVE_LOADS | WA_INDIRECT_CALLS | WA_0574},
   {"bf544", BFIN_CPU_BF544, 0x0001,
@@ -322,6 +326,8 @@
   {"bf547m", BFIN_CPU_BF547M, 0x0003,
WA_SPECULATIVE_LOADS | WA_INDIRECT_CALLS | WA_0574},

+  {"bf547", BFIN_CPU_BF547, 0x0004,
+   WA_SPECULATIVE_LOADS | WA_INDIRECT_CALLS | WA_0574},
   {"bf547", BFIN_CPU_BF547, 0x0002,
WA_SPECULATIVE_LOADS | WA_INDIRECT_CALLS | WA_0574},
   {"bf547", BFIN_CPU_BF547, 0x0001,
@@ -333,6 +339,8 @@
   {"bf548m", BFIN_CPU_BF548M, 0x0003,
WA_SPECULATIVE_LOADS | WA_INDIRECT_CALLS | WA_0574},

+  {"bf548", BFIN_CPU_BF548, 0x0004,
+   WA_SPECULATIVE_LOADS | WA_INDIRECT_CALLS | WA_0574},
   {"bf548", BFIN_CPU_BF548, 0x0002,
WA_SPECULATIVE_LOADS | WA_INDIRECT_CALLS | WA_0574},
   {"bf548", BFIN_CPU_BF548, 0x0001,
@@ -344,6 +352,8 @@
   {"bf549m", BFIN_CPU_BF549M, 0x0003,
WA_SPECULATIVE_LOADS | WA_INDIRECT_CALLS | WA_0574},

+  {"bf549", BFIN_CPU_BF549, 0x0004,
+   WA_SPECULATIVE_LOADS | WA_INDIRECT_CALLS | WA_0574},
   {"bf549", BFIN_CPU_BF549, 0x0002,
WA_SPECULATIVE_LOADS | WA_INDIRECT_CALLS | WA_0574},
   {"bf549", BFIN_CPU_BF549, 0x0001,

Re: [patch][ARM] Fix 16-bit -> 64-bit multiply and accumulate

[Andrew Stubbs]

On 03/05/11 10:07, Bernd Schmidt wrote:

I tried to fix it with the patch below, which unfortunately doesn't work
since during combine we don't see the SIGN_EXTEND operations inside the
MULT, but two shift operations instead. Maybe you can complete it from here?


I'll take a look.

Thanks for the help! :)

Andrew

PING: [debug] PR42288 emit empty .debug_aranges section

[Mark Wielaard]

On Tue, 2011-04-26 at 11:10 +0200, Mark Wielaard wrote:
> This PR was put on hold for a while since gdb didn't immediately need
> it. But the consensus seemed that it was a good idea to always output
> the address ranges (.debug_arange section) information if a CU
> (.debug_info section) was emitted. Because the consumer has no way to
> tell the difference between an empty table that we omitted and failure
> to generate a table that would have contained data. We recently
> discussed this again (see PR), and it still seems like a good thing. So
> here it a patch to just do that:
> 
> 2011-04-26  Mark Wielaard  
> 
> PR42288
> * dwarf2out.c (dwarf2out_finish): Always call output_aranges ()
> when info_section_emitted.
> 
> Tested on i686-pc-linux-gnu, no changes in test results.

Ping.

Thanks,

Mark
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index f3c4c09..520d7a2 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -23812,21 +23812,17 @@ dwarf2out_finish (const char *filename)
 	}
 }
 
-  /* Output the address range information.  We only put functions in the
- arange table, so don't write it out if we don't have any.  */
+  /* Output the address range information if a CU (.debug_info section)
+ was emitted.  We output an empty table even if we had no functions
+ to put in it.  This because the consumer has no way to tell the
+ difference between an empty table that we omitted and failure to
+ generate a table that would have contained data.  */
   if (info_section_emitted)
 {
   unsigned long aranges_length = size_of_aranges ();
 
-  /* Empty .debug_aranges would contain just header and
-	 terminating 0,0.  */
-  if (aranges_length
-	  != (unsigned long) (DWARF_ARANGES_HEADER_SIZE
-			  + 2 * DWARF2_ADDR_SIZE))
-	{
-	  switch_to_section (debug_aranges_section);
-	  output_aranges (aranges_length);
-	}
+  switch_to_section (debug_aranges_section);
+  output_aranges (aranges_length);
 }
 
   /* Output ranges section if necessary.  */

Re: bf54x support

[Bernd Schmidt]

On 05/03/2011 11:23 AM, Henderson, Stuart wrote:
> ping
> 
> 
> The attached patch adds support for silicon revision 0.4 of the bf54x family.

This is OK.

I'll also approve all the patches you posted that were originally from
either me or Jie and confined to config/bfin. Could you ping the ones
that remain after that?


Bernd

RE: bf54x support

[Henderson, Stuart]

sounds good to me.

Thanks.

Stu

-Original Message-
From: Bernd Schmidt [mailto:ber...@codesourcery.com]
Sent: 03 May 2011 10:40
To: Henderson, Stuart
Cc: gcc-patches@gcc.gnu.org
Subject: Re: bf54x support

On 05/03/2011 11:23 AM, Henderson, Stuart wrote:
> ping
>
>
> The attached patch adds support for silicon revision 0.4 of the bf54x family.

This is OK.

I'll also approve all the patches you posted that were originally from
either me or Jie and confined to config/bfin. Could you ping the ones
that remain after that?


Bernd

Re: [google] Patch to support calling multi-versioned functions via new GCC builtin. (issue4440078)

[Richard Guenther]

On Tue, May 3, 2011 at 1:07 AM, Xinliang David Li  wrote:
> On Mon, May 2, 2011 at 2:33 PM, Richard Guenther
>  wrote:
>> On Mon, May 2, 2011 at 6:41 PM, Xinliang David Li  wrote:
>>> On Mon, May 2, 2011 at 2:11 AM, Richard Guenther
>>>  wrote:
 On Fri, Apr 29, 2011 at 6:23 PM, Xinliang David Li  
 wrote:
> Here is the background for this feature:
>
> 1) People relies on function multi-version to explore hw features and
> squeeze performance, but there is no standard ways of doing so, either
> a) using indirect function calls with function pointers set at program
> initialization; b) using manual dispatch at each callsite; b) using
> features like IFUNC.  The dispatch mechanism needs to be promoted to
> the language level and becomes the first class citizen;

 You are not doing that, you are inventing a new (crude) GCC extension.
>>>
>>> To capture the high level semantics and prevent user from lowering the
>>> dispatch calls into forms compiler can not recognize, language
>>> extension is the way to go.
>>
>> I don't think so.  With your patch only two passes understand the new
>> high-level form, the rest of the gimple passes are just confused.
>
> There is no need for other passes to understand it -- just treat it as
> opaque calls. This is goodness otherwise other passes need to be
> modified. This is true (only some passes understand it) for things
> like __builtin_expect.

Certainly __builtin_dispatch has to be understood by alias analysis and
all other passes that care about calls (like all IPA passes).  You can
of course treat it conservatively (may call any function, even those
which have their address not taken, clobber and read all memory, even
that which doesn't escape the TU).

Why obfuscate things when it is not necessary?

>>>
>>> 1) the desired optimization may not happen subject to many compiler
>>> heuristic changes;
>>> 2) it has other side effects such as wrong estimation of function size
>>> which may impact inlining
>>
>> May, may ... so you say all this can't happen under any circumstance
>> with your special code and passes?
>
> No that is not my argument. What I tried to say is it will be harder
> to achieve without high level semantics -- it requires more
> handshaking between compiler passes.

Sure - that's life.

>> Which nobody will see benefit
>> from unless they rewrite their code?
>
> The target users for the builtin include compiler itself -- it can
> synthesize dispatch calls.

Hum.  I'm not at all sure the dispatch calls are the best representation
for the IL.

>> Well, I say if we can improve
>> _some_ of the existing usages that's better than never doing wrong
>> on a new language extension.
>
> This is independent.

It is not.

>> One that I'm not convinced is the way
>> to go (you didn't address at all the inability to use float arguments
>> and the ABI issues with using variadic arguments - after all you
>> did a poor-mans language extension by using GCC builtins instead
>> of inventing a true one).
>
> This is an independent issue that either needs to be addressed or
> marked as limitation. The key of the debate is whether source/IR
> annotation using construct with high level semantics helps optimizer.
> In fact this is common. Would it make any difference (in terms of
> acceptance) if the builtin is only used internally by the compiler and
> not exposed to the user?

No.  I don't see at all why having everything in a single stmt is so much
more convenient.  And I don't see why existing IL features cannot be
used to make things a little more convenient.

>>> 3) it limits the lowering into one form which may not be ideal  --
>>> with builtin_dispatch, after hoisting optimization, the lowering can
>>> use more efficient IFUNC scheme, for instance.
>>
>> I see no reason why we cannot transform a switch-indirect-call
>> pattern into an IFUNC call.
>>
>
> It is possible -- but it is like asking user to lower the dispatch and
> tell compiler to raise it again ..

There is no possibility for a high-level dispatch at the source level.
And if I'd have to design one I would use function overloading, like

float compute_sth (float) __attribute__((version("sse4")))
{
  ... sse4 code ...
}

float compute_sth (float)
{
  ... fallback ...
}

float foo (float f)
{
  return compute_sth (f);
}

and if you not only want to dispatch for target features you could
specify a selector function and value in the attribute.  You might
notice that the above eventually matches the target attribute
directly, just the frontends need to be taught to emit dispatch
code whenever overload resolution results in ambiguities involving
target attribute differences.

Now, a language extension to support multi-versioning should be
completely independent on any IL representation - with using
a builtin you are tying them together with the only convenient
mechanism we have - a mechanism that isn't optimal for either
side IMNSHO.

 My point is that such opti

Re: [google] Patch to support calling multi-versioned functions via new GCC builtin. (issue4440078)

[Richard Guenther]

On Tue, May 3, 2011 at 12:00 PM, Richard Guenther
 wrote:
 3) it limits the lowering into one form which may not be ideal  --
 with builtin_dispatch, after hoisting optimization, the lowering can
 use more efficient IFUNC scheme, for instance.
>>>
>>> I see no reason why we cannot transform a switch-indirect-call
>>> pattern into an IFUNC call.
>>>
>>
>> It is possible -- but it is like asking user to lower the dispatch and
>> tell compiler to raise it again ..
>
> There is no possibility for a high-level dispatch at the source level.
> And if I'd have to design one I would use function overloading, like
>
> float compute_sth (float) __attribute__((version("sse4")))
> {
>  ... sse4 code ...
> }
>
> float compute_sth (float)
> {
>  ... fallback ...
> }
>
> float foo (float f)
> {
>  return compute_sth (f);
> }
>
> and if you not only want to dispatch for target features you could
> specify a selector function and value in the attribute.  You might
> notice that the above eventually matches the target attribute
> directly, just the frontends need to be taught to emit dispatch
> code whenever overload resolution results in ambiguities involving
> target attribute differences.

Which also would allow the frontend to directly call the sse4 variant
if you compile with -msse4, avoiding the need for any fancy processing.

Richard.

Re: Improve DSE in the presence of calls

[Richard Guenther]

On Tue, May 3, 2011 at 5:37 AM, Jeff Law  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 04/26/11 16:06, Easwaran Raman wrote:
>
>>
>>> You're right. The patch has correctness issues. It is not possible to
>>> simply not call add_wild_read because it also resets
>>> active_local_stores and frees read_recs. During the local phase it
>>> seems better to just treat calls as wild reads and reset
>>> active_local_stores and free read_recs. I've now refactored
>>> add_wild_read so that resetting active_local_stores and free read_recs
>>> are in separate methods that can be called on non-const/non-memset
>>> calls. In addition, I have added a non_frame_wild_read field in
>>> insn_info to mark non-const and non-memset calls.
>>
>>> I've attached the revised patch.
> Looking better.  Just a few more things.
>
> Don't all locals escape if the callee has a static chain?  Is that
> handled anywhere?

Locals that escape this way get pushed into a struct variable
which then has its address taken and passed to the call.  This
makes it aliased.  So yes, that's automagically handled.

Richard.

> Don't you still have the potential for wild reads in dse_step5_nospill
> (say from an asm)?  if so, then the change can't be correct.
>
> Couldn't you just add a clause like this before the else-if?
>
> else if (insn_info->non_frame_wild_read)
>  {
>    if (dump_file)
>      fprintf (dump_file, "non-frame wild read\n");
>    scan_reads_nospill (insn_info, v, NULL);
>  }
> else if (insn_info->read_rec)
>  {
>    /* Leave this clause unchanged */
>  }
>
> Am I missing something?
>
> What's the purpose behind using unit64_t in the testcase?  Somehow I
> suspect using int64_t means the test is unlikely not going to work
> across targets with different word sizes.
>
> Jeff
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJNv3iGAAoJEBRtltQi2kC7C8oH+gPi/6DvV2JkmitT3xEeUaW8
> szOHC0GysQkot/TiVlQQy6fiz61G49ii0mz68W4cfSntvuN7iaqBqVWpRKWIzvkx
> alk4U1snj9a2t9+9ZRTX4xm3quggTv+mUDK81a+DIS2zAf6i/HRXLvQbx6fhDOYD
> sqXqSkvCKqkH2pPHHYEqnBtS/cLFtAfZJe+JSx3u2oqL+sBFGLftdoV6yJzkShLS
> LpmYHMeDbzhdCtZTf15GQm3h/cBlyrChxjQsjJxLiXk5rrcDI/X+Pqi+cll21Gwg
> mlzMBi0iYToENl+7aO8DNGvXfliCEzQ7iEUyTctJiTDt3/RgVcaxgRJgqHZNSBI=
> =VOdm
> -END PGP SIGNATURE-
>

Re: [testsuite] Compile gfortran.dg/fmt_g0_6.f08 with -ffloat-store [fwd: tobias.bur...@physik.fu-berlin.de]

[Tobias Burnus]

Rainer,

Rainer Orth wrote:
> Jerry DeLisle wrote:
> > This is OK.  We are working on a solution, so maybe it would be better to
> > XFAIL it so that when it does get fixed it will be flagged. It also fails
> > on i686-pc-gnu.
>
> is this a solution for this particular case or for the general need to
> sometimes use -ffloat-store?  In the former case, I'd agree, in the
> latter it's probably better to consistently use -ffloat-store in the
> testcases and review those uses once a solution is in place.

I think the issue is PR 48602 - wrong I/O output due to wrong rounding
and algorithm bugs. The PR has been mostly fixed, but the excess
precision of the x87 processor still causes failures. One solution
might be to compile the whole libgfortran/io/ with
-fexcess-precision=standard. Adding a single
"asm volatile ("" : "+m" (temp))" proved to be insufficient.

Tobias

PS: Especially as you are listed as testsuite maintainer, I would be
happy if you could comment on the testsuite patch at
http://gcc.gnu.org/ml/fortran/2011-04/msg00331.html

[PATCH] Fix PR48846

[Richard Guenther]

We are streaming DECL_OFFSET_ALIGN using 8 bits.  That is bogus, as
DECL_OFFSET_ALIGN is 1 << decl_common.off_align which in turn is
a 8 bit bitfield.  The solution is to stream decl_common.off_align
instead.

Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk
and the 4.6 branch.

Richard.

2011-05-03  Richard Guenther  

PR lto/48846
* lto-streamer-in.c (unpack_ts_decl_common_value_fields):
Stream decl_common.off_align instead of the derived DECL_OFFSET_ALIGN.
* lto-streamer-out.c (pack_ts_decl_common_value_fields): Likewise.

Index: gcc/lto-streamer-in.c
===
*** gcc/lto-streamer-in.c   (revision 173296)
--- gcc/lto-streamer-in.c   (working copy)
*** unpack_ts_decl_common_value_fields (stru
*** 1653,1663 
  
if (TREE_CODE (expr) == FIELD_DECL)
  {
-   unsigned HOST_WIDE_INT off_align;
DECL_PACKED (expr) = (unsigned) bp_unpack_value (bp, 1);
DECL_NONADDRESSABLE_P (expr) = (unsigned) bp_unpack_value (bp, 1);
!   off_align = (unsigned HOST_WIDE_INT) bp_unpack_value (bp, 8);
!   SET_DECL_OFFSET_ALIGN (expr, off_align);
  }
  
if (TREE_CODE (expr) == RESULT_DECL
--- 1653,1661 
  
if (TREE_CODE (expr) == FIELD_DECL)
  {
DECL_PACKED (expr) = (unsigned) bp_unpack_value (bp, 1);
DECL_NONADDRESSABLE_P (expr) = (unsigned) bp_unpack_value (bp, 1);
!   expr->decl_common.off_align = bp_unpack_value (bp, 8);
  }
  
if (TREE_CODE (expr) == RESULT_DECL
Index: gcc/lto-streamer-out.c
===
*** gcc/lto-streamer-out.c  (revision 173296)
--- gcc/lto-streamer-out.c  (working copy)
*** pack_ts_decl_common_value_fields (struct
*** 401,407 
  {
bp_pack_value (bp, DECL_PACKED (expr), 1);
bp_pack_value (bp, DECL_NONADDRESSABLE_P (expr), 1);
!   bp_pack_value (bp, DECL_OFFSET_ALIGN (expr), 8);
  }
  
if (TREE_CODE (expr) == RESULT_DECL
--- 401,407 
  {
bp_pack_value (bp, DECL_PACKED (expr), 1);
bp_pack_value (bp, DECL_NONADDRESSABLE_P (expr), 1);
!   bp_pack_value (bp, expr->decl_common.off_align, 8);
  }
  
if (TREE_CODE (expr) == RESULT_DECL
 

[debug] Remove unused debug_str_hash_forced code

[Mark Wielaard]

Hi,

While reading through the dwarf2out debug_str support I got confused by
some of the code dealing with debug_str_hash_forced. But after PR41404
was fixed nothing actually uses this anymore. So this patch just removes
the dead code and simplifies a check.

2011-05-03  Mark Wielaard  

* dwarf2out.c (debug_str_hash_forced): Removed.
(gen_label_for_indirect_string): Removed.
(get_debug_string_label): Removed.
(AT_string_form): Generate label directly.
(output_indirect_string): Test indirect_string_node for 
DW_FORM_strp instead of checking label and refcount.
(prune_indirect_string): Removed.
(prune_unused_types): Don't check debug_str_hash_forced or
call prune_indirect_string.

OK to commit and push?

Thanks,

Mark
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 83653d2..c42fdb9 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -433,10 +433,6 @@ struct GTY(()) indirect_string_node {
 
 static GTY ((param_is (struct indirect_string_node))) htab_t debug_str_hash;
 
-/* True if the compilation unit has location entries that reference
-   debug strings.  */
-static GTY(()) bool debug_str_hash_forced = false;
-
 static GTY(()) int dw2_string_counter;
 static GTY(()) unsigned long dwarf2out_cfi_label_num;
 
@@ -7676,37 +7672,6 @@ add_AT_string (dw_die_ref die, enum dwarf_attribute attr_kind, const char *str)
   add_dwarf_attr (die, &attr);
 }
 
-/* Create a label for an indirect string node, ensuring it is going to
-   be output, unless its reference count goes down to zero.  */
-
-static inline void
-gen_label_for_indirect_string (struct indirect_string_node *node)
-{
-  char label[32];
-
-  if (node->label)
-return;
-
-  ASM_GENERATE_INTERNAL_LABEL (label, "LASF", dw2_string_counter);
-  ++dw2_string_counter;
-  node->label = xstrdup (label);
-}
-
-/* Create a SYMBOL_REF rtx whose value is the initial address of a
-   debug string STR.  */
-
-static inline rtx
-get_debug_string_label (const char *str)
-{
-  struct indirect_string_node *node = find_AT_string (str);
-
-  debug_str_hash_forced = true;
-
-  gen_label_for_indirect_string (node);
-
-  return gen_rtx_SYMBOL_REF (Pmode, node->label);
-}
-
 static inline const char *
 AT_string (dw_attr_ref a)
 {
@@ -7722,6 +7687,7 @@ AT_string_form (dw_attr_ref a)
 {
   struct indirect_string_node *node;
   unsigned int len;
+  char label[32];
 
   gcc_assert (a && AT_class (a) == dw_val_class_str);
 
@@ -7744,7 +7710,9 @@ AT_string_form (dw_attr_ref a)
   && (len - DWARF_OFFSET_SIZE) * node->refcount <= len))
 return node->form = DW_FORM_string;
 
-  gen_label_for_indirect_string (node);
+  ASM_GENERATE_INTERNAL_LABEL (label, "LASF", dw2_string_counter);
+  ++dw2_string_counter;
+  node->label = xstrdup (label);
 
   return node->form = DW_FORM_strp;
 }
@@ -23069,7 +23037,7 @@ output_indirect_string (void **h, void *v ATTRIBUTE_UNUSED)
 {
   struct indirect_string_node *node = (struct indirect_string_node *) *h;
 
-  if (node->label && node->refcount)
+  if (node->form == DW_FORM_strp)
 {
   switch_to_section (debug_str_section);
   ASM_OUTPUT_LABEL (asm_out_file, node->label);
@@ -23386,21 +23354,6 @@ prune_unused_types_prune (dw_die_ref die)
   } while (c != die->die_child);
 }
 
-/* A helper function for dwarf2out_finish called through
-   htab_traverse.  Clear .debug_str strings that we haven't already
-   decided to emit.  */
-
-static int
-prune_indirect_string (void **h, void *v ATTRIBUTE_UNUSED)
-{
-  struct indirect_string_node *node = (struct indirect_string_node *) *h;
-
-  if (!node->label || !node->refcount)
-htab_clear_slot (debug_str_hash, h);
-
-  return 1;
-}
-
 /* Remove dies representing declarations that we never use.  */
 
 static void
@@ -23441,10 +23394,7 @@ prune_unused_types (void)
   for (i = 0; VEC_iterate (dw_die_ref, base_types, i, base_type); i++)
 prune_unused_types_mark (base_type, 1);
 
-  /* Get rid of nodes that aren't marked; and update the string counts.  */
-  if (debug_str_hash && debug_str_hash_forced)
-htab_traverse (debug_str_hash, prune_indirect_string, NULL);
-  else if (debug_str_hash)
+  if (debug_str_hash)
 htab_empty (debug_str_hash);
   prune_unused_types_prune (comp_unit_die ());
   for (node = limbo_die_list; node; node = node->next)

Re: [google]: initialize language field for clone function struct

[Jan Hubicka]

> Is this one ok?
Hi,
we did quite some work on removing a langhooks for LTO, where they become quite 
impossible
So I would like to know what testcase causes the problem and why.

Honza
> 
> David
> 
> On Fri, Apr 29, 2011 at 4:38 PM, Xinliang David Li  wrote:
> > During function cloning, the language field of the src func is not
> > copied. This can lead to null dereference when gcc calls into langhook
> > functions.  Unfortunately, I lost track of the test case.
> >
> > Ok for trunk ?
> >
> > Thanks,
> >
> > David
> >
> >
> > 2011-04-29  Xinliang David Li  
> >
> >        * tree-inline.c (ininitialize_cfun): Initialize
> >        language field for clone cfun.
> >

Re: [testsuite] Compile gfortran.dg/fmt_g0_6.f08 with -ffloat-store [fwd: tobias.bur...@physik.fu-berlin.de]

[Jerry DeLisle]

On 05/03/2011 03:14 AM, Tobias Burnus wrote:

Rainer,

Rainer Orth wrote:

Jerry DeLisle wrote:

This is OK.  We are working on a solution, so maybe it would be better to
XFAIL it so that when it does get fixed it will be flagged. It also fails
on i686-pc-gnu.


is this a solution for this particular case or for the general need to
sometimes use -ffloat-store?  In the former case, I'd agree, in the
latter it's probably better to consistently use -ffloat-store in the
testcases and review those uses once a solution is in place.


I think the issue is PR 48602 - wrong I/O output due to wrong rounding
and algorithm bugs. The PR has been mostly fixed, but the excess
precision of the x87 processor still causes failures. One solution
might be to compile the whole libgfortran/io/ with
-fexcess-precision=standard. Adding a single
"asm volatile ("" : "+m" (temp))" proved to be insufficient.

Tobias

PS: Especially as you are listed as testsuite maintainer, I would be
happy if you could comment on the testsuite patch at
http://gcc.gnu.org/ml/fortran/2011-04/msg00331.html



My goal is to completely not use any floating point operations for that section 
of code.  We have a concept on how to do it.  I am still working out tweaks to 
48787, then I will turn my attention to this. Feel free to quiet that test case 
any way you wish in the meantime.


Jerry

Re: [PATCH 2/6] Unique return rtx

[Bernd Schmidt]

On 03/31/2011 03:17 PM, Jeff Law wrote:
> On 03/23/11 08:47, Bernd Schmidt wrote:
>> We'll start putting "return" into JUMP_LABELS in a subsequent patch, so
>> I've decided to make it unique as a small cleanup.
> 
>> There's already another macro called "return_rtx", so the new one goes
>> by the name of "ret_rtx".
> OK.

Thanks. Now committed in this form, slightly updated. I've verified that
all ports modified in this patch still build the gcc/ directory
successfully.


Bernd
Index: gengenrtl.c
===
--- gengenrtl.c (revision 173297)
+++ gengenrtl.c (working copy)
@@ -128,6 +128,9 @@ special_rtx (int idx)
  || strcmp (defs[idx].enumname, "REG") == 0
  || strcmp (defs[idx].enumname, "SUBREG") == 0
  || strcmp (defs[idx].enumname, "MEM") == 0
+ || strcmp (defs[idx].enumname, "PC") == 0
+ || strcmp (defs[idx].enumname, "CC0") == 0
+ || strcmp (defs[idx].enumname, "RETURN") == 0
  || strcmp (defs[idx].enumname, "CONST_VECTOR") == 0);
 }
 
Index: genemit.c
===
--- genemit.c   (revision 173297)
+++ genemit.c   (working copy)
@@ -166,6 +166,9 @@ gen_exp (rtx x, enum rtx_code subroutine
 case PC:
   printf ("pc_rtx");
   return;
+case RETURN:
+  printf ("ret_rtx");
+  return;
 case CLOBBER:
   if (REG_P (XEXP (x, 0)))
{
Index: ChangeLog
===
--- ChangeLog   (revision 173297)
+++ ChangeLog   (working copy)
@@ -1,3 +1,29 @@
+2011-05-03  Bernd Schmidt  
+
+   * gengenrtl.c (special_rtx): PC, CC0 and RETURN are special.
+   * genemit.c (gen_exp): Handle RETURN.
+   * emit-rtl.c (verify_rtx_sharing): Likewise.
+   (init_emit_regs): Create pc_rtx, ret_rtx and cc0_rtx specially.
+   * rtl.c (copy_rtx): RETURN is shared.
+   * rtl.h (enum global_rtl_index): Add GR_RETURN.
+   (ret_rtx): New.
+   * jump.c (redirect_exp_1): Don't use gen_rtx_RETURN.
+   * config/s390/s390.c (s390_emit_epilogue): Likewise.
+   * config/rx/rx.c (gen_rx_rtsd_vector): Likewise.
+   * config/cris/cris.c (cris_expand_return): Likewise.
+   * config/m68k/m68k.c (m68k_expand_epilogue): Likewise.
+   * config/rs6000/rs6000.c (rs6000_make_savres_rtx,
+   rs6000_emit_epilogue, rs6000_output_mi_thunk): Likewise.
+   * config/picochip/picochip.c (picochip_expand_epilogue): Likewise.
+   * config/h8300/h8300.c (h8300_push_pop, h8300_expand_epilogue):
+   Likewise.
+   * config/v850/v850.c (expand_epilogue): Likewise.
+   * config/bfin/bfin.c (bfin_expand_call): Likewise.
+   * config/arm/arm.md (epilogue): Likewise.
+   * config/mn10300/mn10300.c (mn10300_expand_epilogue): Likewise.
+   * config/sparc/sparc.c (sparc_struct_value_rtx): Rename ret_rtx
+   variable to ret_reg.
+
 2011-05-03  Richard Guenther  
 
* c-decl.c (grokdeclarator): Instead of looking at
Index: jump.c
===
--- jump.c  (revision 173297)
+++ jump.c  (working copy)
@@ -1367,7 +1367,7 @@ redirect_exp_1 (rtx *loc, rtx olabel, rt
  if (nlabel)
n = gen_rtx_LABEL_REF (Pmode, nlabel);
  else
-   n = gen_rtx_RETURN (VOIDmode);
+   n = ret_rtx;
 
  validate_change (insn, loc, n, 1);
  return;
@@ -1378,7 +1378,7 @@ redirect_exp_1 (rtx *loc, rtx olabel, rt
   if (nlabel)
x = gen_rtx_LABEL_REF (Pmode, nlabel);
   else
-   x = gen_rtx_RETURN (VOIDmode);
+   x = ret_rtx;
   if (loc == &PATTERN (insn))
x = gen_rtx_SET (VOIDmode, pc_rtx, x);
   validate_change (insn, loc, x, 1);
@@ -1389,7 +1389,7 @@ redirect_exp_1 (rtx *loc, rtx olabel, rt
   && GET_CODE (SET_SRC (x)) == LABEL_REF
   && XEXP (SET_SRC (x), 0) == olabel)
 {
-  validate_change (insn, loc, gen_rtx_RETURN (VOIDmode), 1);
+  validate_change (insn, loc, ret_rtx, 1);
   return;
 }
 
Index: emit-rtl.c
===
--- emit-rtl.c  (revision 173297)
+++ emit-rtl.c  (working copy)
@@ -2450,6 +2450,7 @@ verify_rtx_sharing (rtx orig, rtx insn)
 case CODE_LABEL:
 case PC:
 case CC0:
+case RETURN:
 case SCRATCH:
   return;
   /* SCRATCH must be shared because they represent distinct values.  */
@@ -5416,8 +5417,9 @@ init_emit_regs (void)
   init_reg_modes_target ();
 
   /* Assign register numbers to the globally defined register rtx.  */
-  pc_rtx = gen_rtx_PC (VOIDmode);
-  cc0_rtx = gen_rtx_CC0 (VOIDmode);
+  pc_rtx = gen_rtx_fmt_ (PC, VOIDmode);
+  ret_rtx = gen_rtx_fmt_ (RETURN, VOIDmode);
+  cc0_rtx = gen_rtx_fmt_ (CC0, VOIDmode);
   stack_pointer_rtx = gen_raw_REG (Pmode, STACK_POINTER_REGNUM);
   frame_pointer_rtx = gen_raw_REG (Pmode, FRAME_POINTER_REGNUM);
   hard_frame_pointer_rtx 

Re: RFA: MN10300: Add support for SETLB and Lcc instructions

[Nick Clifton]

Hi Richard,

  Thanks for the patch review.  Sorry for not responding earlier, but 
some other work got in the way.


  I have attached a revised patch which addresses all of the points you 
raised except one:



+ else if (loop->header != loop->latch
+   reason = "it is not a simple do-while loop";


Why?  A loop with multiple blocks should be fine with Lcc.


  The problem I found here was that I did not know how to find all of 
the test-and-loop-back insns if the loop spanned multiple blocks.  The 
revised patch includes a comment saying that loops spanning multiple 
blocks could be supported, but I would like to leave that for a future 
patch rather than trying to get it all working now.


Cheers
  Nick






mn10300.setlb.patch.4
Description: Unix manual page

Re: [PATCH] Fix bt[lq] related miscompilation (PR target/48774)

[Jakub Jelinek]

On Tue, May 03, 2011 at 10:26:50AM +0200, Uros Bizjak wrote:
> On Mon, May 2, 2011 at 10:16 PM, Jakub Jelinek  wrote:
> IMO, this problem arises due to wrong fix for PR target/37184 [1] that
> added CCA, CCC, CCO, CCS mode bypasses to ix86_match_ccmode.

Yeah, ix86_match_ccmode was the first place I was looking at and
it surprised me it allowed all those modes for CCNOmode req_mode.
Thought there was a reason why it is done that way, but if there is not,
even better.  CC{A,O,S,Z}mode seem to be apparently only used for SSE
intrinsics and CCCmode just for bt and adc/sbb etc.

> Jakub, can you please check the patch, I'm not able to test it
> properly until tonight.

Yeah, following patch passed bootstrap/regtest on x86_64-linux and
i686-linux.  Ok for trunk/4.6 (and perhaps later on 4.5/4.4)?

2011-05-03  Uros Bizjak  
Jakub Jelinek  

PR target/48774
* config/i386/i386.c (ix86_match_ccmode): For CC{A,C,O,S}mode
only succeed if req_mode is the same as set_mode.

* gcc.dg/pr48774.c: New test.

--- gcc/config/i386/i386.c.jj   2011-05-03 12:11:23.0 +0200
+++ gcc/config/i386/i386.c  2011-05-03 12:24:05.320670624 +0200
@@ -17299,11 +17299,15 @@ ix86_match_ccmode (rtx insn, enum machin
   if (req_mode == CCZmode)
return false;
   /* FALLTHRU */
+case CCZmode:
+  break;
+
 case CCAmode:
 case CCCmode:
 case CCOmode:
 case CCSmode:
-case CCZmode:
+  if (set_mode != req_mode)
+   return false;
   break;
 
 default:
--- gcc/testsuite/gcc.dg/pr48774.c.jj   2011-05-02 19:12:32.0 +0200
+++ gcc/testsuite/gcc.dg/pr48774.c  2011-05-02 11:03:55.0 +0200
@@ -0,0 +1,38 @@
+/* PR target/48774 */
+/* { dg-do run } */
+/* { dg-options "-O2 -funroll-loops" } */
+
+extern void abort (void);
+unsigned long int s[24]
+  = { 12, ~1, 12, ~2, 12, ~4, 12, ~8, 12, ~16, 12, ~32,
+  12, ~64, 12, ~128, 12, ~256, 12, ~512, 12, ~1024, 12, ~2048 };
+struct { int n; unsigned long *e[12]; } g
+  = { 12, { &s[0], &s[2], &s[4], &s[6], &s[8], &s[10], &s[12], &s[14],
+   &s[16], &s[18], &s[20], &s[22] } };
+int c[12];
+
+__attribute__((noinline, noclone)) void
+foo (void)
+{
+  int i, j;
+  for (i = 0; i < g.n; i++)
+for (j = 0; j < g.n; j++)
+  {
+   if (i == j && j < g.e[0][0] && (g.e[i][1] & (1UL << j)))
+ abort ();
+   if (j < g.e[0][0] && (g.e[i][1] & (1UL << j)))
+ c[i]++;
+  }
+}
+
+int
+main ()
+{
+  int i;
+  asm volatile ("" : "+m" (s), "+m" (g), "+m" (c));
+  foo ();
+  for (i = 0; i < 12; i++)
+if (c[i] != 11)
+  abort ();
+  return 0;
+}


Jakub

Re: [PATCH] Fix bt[lq] related miscompilation (PR target/48774)

[Uros Bizjak]

On Tue, May 3, 2011 at 2:39 PM, Jakub Jelinek  wrote:
> On Tue, May 03, 2011 at 10:26:50AM +0200, Uros Bizjak wrote:
>> On Mon, May 2, 2011 at 10:16 PM, Jakub Jelinek  wrote:
>> IMO, this problem arises due to wrong fix for PR target/37184 [1] that
>> added CCA, CCC, CCO, CCS mode bypasses to ix86_match_ccmode.
>
> Yeah, ix86_match_ccmode was the first place I was looking at and
> it surprised me it allowed all those modes for CCNOmode req_mode.
> Thought there was a reason why it is done that way, but if there is not,
> even better.  CC{A,O,S,Z}mode seem to be apparently only used for SSE
> intrinsics and CCCmode just for bt and adc/sbb etc.

Heh, there was no reason that these modes were added that way... just
to bypass gcc_unreachable (), see referred PR.

>> Jakub, can you please check the patch, I'm not able to test it
>> properly until tonight.
>
> Yeah, following patch passed bootstrap/regtest on x86_64-linux and
> i686-linux.  Ok for trunk/4.6 (and perhaps later on 4.5/4.4)?
>
> 2011-05-03  Uros Bizjak  
>            Jakub Jelinek  
>
>        PR target/48774
>        * config/i386/i386.c (ix86_match_ccmode): For CC{A,C,O,S}mode
>        only succeed if req_mode is the same as set_mode.
>
>        * gcc.dg/pr48774.c: New test.

This is OK everywhere, it was a thinko after all.

Thanks,
Uros.

[PATCH, ARM] Fix NEON vset_lane for D registers

[Julian Brown]

Hi,

This patch fixes vset_lane intrinsic variants for D-register sized
variables. A typo meant that the wrong lane would be set in many
circumstances.

Tested manually only. OK to apply?

Thanks,

Julian

ChangeLog

gcc/
* config/arm/neon.md (vec_set_internal): Fix misplaced
parenthesis in D-register case.

Index: gcc/config/arm/neon.md
===
--- gcc/config/arm/neon.md	(revision 173299)
+++ gcc/config/arm/neon.md	(working copy)
@@ -426,7 +426,7 @@
   (match_operand:SI 2 "immediate_operand" "i")))]
   "TARGET_NEON"
 {
-  int elt = ffs ((int) INTVAL (operands[2]) - 1);
+  int elt = ffs ((int) INTVAL (operands[2])) - 1;
   if (BYTES_BIG_ENDIAN)
 elt = GET_MODE_NUNITS (mode) - 1 - elt;
   operands[2] = GEN_INT (elt);

Re: [PATCH, ARM] fix PR pch/45979 regression on ARM

[Richard Earnshaw]

On Mon, 2011-05-02 at 09:21 +1200, Michael Hope wrote:
> Linux 2.6.35 and later on ARM randomise the address space, breaking
> precompiled header support in GCC.  The fix is to use the support in
> GCC for mmap()ing into a fixed, likely to be free address.  The ARM
> memory map is modeled on the i386 so I used the same definition.
> 
> Tested on trunk with a Ubuntu 2.6.35 kernel.  Bootstraps OK and clears
> all of the PCH testsuite failures.  Note that this change is
> equivalent to Mikael Pettersson's patch at:
>  http://gcc.gnu.org/ml/gcc-patches/2010-10/msg02252.html
> 
> OK for trunk?
> 

OK.

R.

> -- Michael
> 
> gcc/
> 
> 2011-05-02  Michael Hope  
> 
>   PR pch/45979
>   * config/host-linux.c (TRY_EMPTY_VM_SPACE): Define for
>   __ARM_EABI__ hosts.
> 
> diff --git a/gcc/config/host-linux.c b/gcc/config/host-linux.c
> index 47ce3ea..8b41685 100644
> --- a/gcc/config/host-linux.c
> +++ b/gcc/config/host-linux.c
> @@ -84,6 +84,8 @@
>  # define TRY_EMPTY_VM_SPACE  0x6000
>  #elif defined(__mc68000__)
>  # define TRY_EMPTY_VM_SPACE  0x4000
> +#elif defined(__ARM_EABI__)
> +# define TRY_EMPTY_VM_SPACE  0x6000
>  #else
>  # define TRY_EMPTY_VM_SPACE  0
>  #endif

Re: Problem with ARM longcalls

[Bernd Schmidt]

On 04/14/2011 03:00 PM, Richard Guenther wrote:
> On Thu, Apr 14, 2011 at 2:40 PM, Bernd Schmidt  
> wrote:
>> Ping.  Contains only changes outside config/arm.
>>
>> http://gcc.gnu.org/m/gcc-patches/2011-03/msg01509.html
> 
> Ok.

Committed this version on trunk (which has different code to initialize
first_function_block_is_cold). Tested again, with a profiledbootstrap
(which I hope exercised this code). I'll wait a few days and then put
the originally posted version on the branches.


Bernd
Index: ChangeLog
===
--- ChangeLog   (revision 173301)
+++ ChangeLog   (working copy)
@@ -1,3 +1,12 @@
+2011-05-03  Bernd Schmidt  
+
+   * function.c (init_function_start): Call decide_function_section.
+   * varasm.c (decide_function_section): New function.
+   (assemble_start_function): When not using
+   flag_reorder_blocks_and_partition, don't compute in_cold_section_p
+   or first_function_block_is_cold.
+   * rtl.h (decide_function_section): Declare.
+
 2011-05-03  Uros Bizjak  
Jakub Jelinek  
 
Index: testsuite/gcc.target/arm/cold-lc.c
===
--- testsuite/gcc.target/arm/cold-lc.c  (revision 0)
+++ testsuite/gcc.target/arm/cold-lc.c  (revision 0)
@@ -0,0 +1,22 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -mlong-calls" } */
+/* { dg-final { scan-assembler-not "bl\[^\n\]*dump_stack" } } */
+
+extern void dump_stack (void) __attribute__ ((__cold__)) __attribute__ 
((noinline));
+struct thread_info {
+struct task_struct *task;
+};
+extern struct thread_info *current_thread_info (void);
+
+void dump_stack (void)
+{
+unsigned long stack;
+show_stack ((current_thread_info ()->task), &stack);
+}
+
+void die (char *str, void *fp, int nr)
+{
+dump_stack ();
+while (1);
+}
+
Index: testsuite/ChangeLog
===
--- testsuite/ChangeLog (revision 173301)
+++ testsuite/ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2011-05-03  Bernd Schmidt  
+
+   * gcc.target/arm/cold-lc.c: New test.
+
 2011-05-03  Jakub Jelinek  
 
PR target/48774
Index: function.c
===
--- function.c  (revision 173297)
+++ function.c  (working copy)
@@ -4515,6 +4515,7 @@ init_function_start (tree subr)
   else
 allocate_struct_function (subr, false);
   prepare_function_start ();
+  decide_function_section (subr);
 
   /* Warn if this value is an aggregate type,
  regardless of which calling convention we are using for it.  */
Index: varasm.c
===
--- varasm.c(revision 173297)
+++ varasm.c(working copy)
@@ -1512,6 +1512,33 @@ notice_global_symbol (tree decl)
 }
 }
 
+/* If not using flag_reorder_blocks_and_partition, decide early whether the
+   current function goes into the cold section, so that targets can use
+   current_function_section during RTL expansion.  DECL describes the
+   function.  */
+
+void
+decide_function_section (tree decl)
+{
+  first_function_block_is_cold = false;
+
+  if (flag_reorder_blocks_and_partition)
+/* We will decide in assemble_start_function.  */
+return;
+
+ if (DECL_SECTION_NAME (decl))
+{
+  struct cgraph_node *node = cgraph_get_node (current_function_decl);
+  /* Calls to function_section rely on first_function_block_is_cold
+being accurate.  */
+  first_function_block_is_cold = (node
+ && node->frequency
+ == NODE_FREQUENCY_UNLIKELY_EXECUTED);
+}
+
+  in_cold_section_p = first_function_block_is_cold;
+}
+
 /* Output assembler code for the constant pool of a function and associated
with defining the name of the function.  DECL describes the function.
NAME is the function's name.  For the constant pool, we use the current
@@ -1524,7 +1551,6 @@ assemble_start_function (tree decl, cons
   char tmp_label[100];
   bool hot_label_written = false;
 
-  first_function_block_is_cold = false;
   if (flag_reorder_blocks_and_partition)
 {
   ASM_GENERATE_INTERNAL_LABEL (tmp_label, "LHOTB", const_labelno);
@@ -1559,6 +1585,8 @@ assemble_start_function (tree decl, cons
 
   if (flag_reorder_blocks_and_partition)
 {
+  first_function_block_is_cold = false;
+
   switch_to_section (unlikely_text_section ());
   assemble_align (DECL_ALIGN (decl));
   ASM_OUTPUT_LABEL (asm_out_file, crtl->subsections.cold_section_label);
@@ -1575,18 +1603,9 @@ assemble_start_function (tree decl, cons
  hot_label_written = true;
  first_function_block_is_cold = true;
}
-}
-  else if (DECL_SECTION_NAME (decl))
-{
-  struct cgraph_node *node = cgraph_get_node (current_function_decl);
-  /* Calls to function_section rely on first_function_block_is_cold
-being accurate.  */
- 

Re: Improve jump threading 4 of N

[Jeff Law]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/02/11 15:18, Richard Guenther wrote:

> 
>> For (edge *)xmalloc (sizeof (edge) * 1) use XNEWVEC and friends.
>> I wonder if it makes sense to use a VEC instead (will the vector
>> be of variable size?).  Maybe wrap accesses to e->aux with
>> a macro or some inline functions.
> 
>> Ok with the allocation change.
Attached is the actual patch I checked in.  I found a minor goof in the
stats reporting which I fixed, in addition to the stuff Richard pointed out.

Bootstrapped and regression tested on x86_64-unknown-linux-gnu

Jeff
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNwABQAAoJEBRtltQi2kC7yUkH/3RkOHjEqrTz6C/fnapNQYKx
D/Ts9p7zlIsm66+cVpbM8z2+884QOEv0TjVqd7uDo7/vg9cKw7xRMbNI6+IZTM/H
NdFweso3rC2nZZhqNn0DBkczo7RZcdMhR0DGkpd+xGZBSE4L6gw6W9+3YJ70BZZo
KLuZ0PiYmPcuJEN00O0zmypiVX7z04tvCSSLxPbXT/sHU6odNWvUAdEZhKX6nJ2r
/FljdonBdLbdwEdVoRycZ64F6TrF66zaS2EKWgtdhe9PP6hQ/ovUoyXT5LwkRxDv
VvmLRx/6D1xyDmLus9D41016k9Iog4gn4Kfb9taaX57KkiCfBgyhaQgbOoIZNVM=
=z/nF
-END PGP SIGNATURE-
* tree-ssa-threadupdate.c (THREAD_TARGET): define.
(remove_ctrl_stmt_and_useless_edges): Clear AUX field of outgoing edges.
(craete_edge_and_update_destination_phis): Use THREAD_TARGET rather
than accessing AUX field directly.  Free the AUX field before   
clearing it.
(thread_block, thread_through_loop_header): Likewise.
(thread_single_edge, mark_threaded_blocks): Likewise.
(redirect_edges): Delay clearing the AUX field.  Free the AUX field.
(register_jump_thread): Do not attempt to thread to a NULL edge.

Index: tree-ssa-threadupdate.c
===
*** tree-ssa-threadupdate.c (revision 173302)
--- tree-ssa-threadupdate.c (working copy)
*** struct local_info
*** 149,154 
--- 149,158 
 (original_edge, target_edge).  */
  static VEC(edge,heap) *threaded_edges;
  
+ /* When we start updating the CFG for threading, data necessary for jump
+threading is attached to the AUX field for the incoming edge.  Use these
+macros to access the underlying structure attached to the AUX field.  */
+ #define THREAD_TARGET(E) ((edge *)(E)->aux)[0]
  
  /* Jump threading statistics.  */
  
*** remove_ctrl_stmt_and_useless_edges (basi
*** 200,209 
--- 204,219 
  static void
  create_block_for_threading (basic_block bb, struct redirection_data *rd)
  {
+   edge_iterator ei;
+   edge e;
+ 
/* We can use the generic block duplication code and simply remove
   the stuff we do not need.  */
rd->dup_block = duplicate_block (bb, NULL, NULL);
  
+   FOR_EACH_EDGE (e, ei, rd->dup_block->succs)
+ e->aux = NULL;
+ 
/* Zero out the profile, since the block is unreachable for now.  */
rd->dup_block->frequency = 0;
rd->dup_block->count = 0;
*** create_edge_and_update_destination_phis 
*** 314,320 
rescan_loop_exit (e, true, false);
e->probability = REG_BR_PROB_BASE;
e->count = bb->count;
!   e->aux = rd->outgoing_edge->aux;
  
/* If there are any PHI nodes at the destination of the outgoing edge
   from the duplicate block, then we will need to add a new argument
--- 324,339 
rescan_loop_exit (e, true, false);
e->probability = REG_BR_PROB_BASE;
e->count = bb->count;
! 
!   if (rd->outgoing_edge->aux)
! {
!   e->aux = (edge *) XNEWVEC (edge, 1);
!   THREAD_TARGET(e) = THREAD_TARGET (rd->outgoing_edge);
! }
!   else
! {
!   e->aux = NULL;
! }
  
/* If there are any PHI nodes at the destination of the outgoing edge
   from the duplicate block, then we will need to add a new argument
*** redirect_edges (void **slot, void *data)
*** 406,415 
next = el->next;
free (el);
  
-   /* Go ahead and clear E->aux.  It's not needed anymore and failure
-  to clear it will cause all kinds of unpleasant problems later.  */
-   e->aux = NULL;
- 
thread_stats.num_threaded_edges++;
  
if (rd->dup_block)
--- 425,430 
*** redirect_edges (void **slot, void *data)
*** 429,434 
--- 444,455 
  gcc_assert (e == e2);
  flush_pending_stmts (e2);
}
+ 
+   /* Go ahead and clear E->aux.  It's not needed anymore and failure
+  to clear it will cause all kinds of unpleasant problems later.  */
+   free (e->aux);
+   e->aux = NULL;
+ 
  }
  
/* Indicate that we actually threaded one or more jumps.  */
*** thread_block (basic_block bb, bool noloo
*** 512,518 
if (loop->header == bb)
  {
e = loop_latch_edge (loop);
!   e2 = (edge) e->aux;
  
if (e2 && loop_exit_edge_p (loop, e2))
{
--- 533,543 
if (loop->header == bb)
  {
e = loop_latch_edge

Re: [patch, ARM] Fix PR42017, LR not used in leaf functions

[Richard Sandiford]

Chung-Lin Tang  writes:
> My fix here simply adds 'reload_completed' as an additional condition
> for EPILOGUE_USES to return true for LR_REGNUM. I think this should be
> valid, as correct LR save/restoring is handled by the epilogue/prologue
> code; it should be safe for IRA to treat it as a normal call-used register.

FWIW, epilogue_completed might be a more accurate choice.

It seems a lot of other ports suffer from the same problem though.
I wonder which targets really do want to make a register live throughout
the function?  If none do, perhaps we should say that this macro is
only meaningful once the epilogue has been generated.

Richard

FW: [Patch] Update bfin parts to latest silicon revisions

[Henderson, Stuart]

Ping
---

The attached patch adds support for (and changes defaults to) the latest 
silicon revisions for Blackfin parts.

2011-05-03  Stuart Henderson  

* config/bfin/bfin.c (bfin_cpus): Update silicon revisions.



Thanks,
Stu


Index: gcc/config/bfin/bfin.c
===
--- gcc/config/bfin/bfin.c  (revision 171215)
+++ gcc/config/bfin/bfin.c  (working copy)
@@ -117,15 +117,32 @@

 struct bfin_cpu bfin_cpus[] =
 {
+
+  {"bf512", BFIN_CPU_BF512, 0x0002,
+   WA_SPECULATIVE_LOADS | WA_0574},
+  {"bf512", BFIN_CPU_BF512, 0x0001,
+   WA_SPECULATIVE_LOADS | WA_0574},
   {"bf512", BFIN_CPU_BF512, 0x,
WA_SPECULATIVE_LOADS | WA_0574},

+  {"bf514", BFIN_CPU_BF514, 0x0002,
+   WA_SPECULATIVE_LOADS | WA_0574},
+  {"bf514", BFIN_CPU_BF514, 0x0001,
+   WA_SPECULATIVE_LOADS | WA_0574},
   {"bf514", BFIN_CPU_BF514, 0x,
WA_SPECULATIVE_LOADS | WA_0574},

+  {"bf516", BFIN_CPU_BF516, 0x0002,
+   WA_SPECULATIVE_LOADS | WA_0574},
+  {"bf516", BFIN_CPU_BF516, 0x0001,
+   WA_SPECULATIVE_LOADS | WA_0574},
   {"bf516", BFIN_CPU_BF516, 0x,
WA_SPECULATIVE_LOADS | WA_0574},

+  {"bf518", BFIN_CPU_BF518, 0x0002,
+   WA_SPECULATIVE_LOADS | WA_0574},
+  {"bf518", BFIN_CPU_BF518, 0x0001,
+   WA_SPECULATIVE_LOADS | WA_0574},
   {"bf518", BFIN_CPU_BF518, 0x,
WA_SPECULATIVE_LOADS | WA_0574},

@@ -273,6 +290,8 @@
   {"bf542m", BFIN_CPU_BF542M, 0x0003,
WA_SPECULATIVE_LOADS | WA_INDIRECT_CALLS | WA_0574},

+  {"bf542", BFIN_CPU_BF542, 0x0004,
+   WA_SPECULATIVE_LOADS | WA_INDIRECT_CALLS | WA_0574},
   {"bf542", BFIN_CPU_BF542, 0x0002,
WA_SPECULATIVE_LOADS | WA_INDIRECT_CALLS | WA_0574},
   {"bf542", BFIN_CPU_BF542, 0x0001,
@@ -284,6 +303,8 @@
   {"bf544m", BFIN_CPU_BF544M, 0x0003,
WA_SPECULATIVE_LOADS | WA_INDIRECT_CALLS | WA_0574},

+  {"bf544", BFIN_CPU_BF544, 0x0004,
+   WA_SPECULATIVE_LOADS | WA_INDIRECT_CALLS | WA_0574},
   {"bf544", BFIN_CPU_BF544, 0x0002,
WA_SPECULATIVE_LOADS | WA_INDIRECT_CALLS | WA_0574},
   {"bf544", BFIN_CPU_BF544, 0x0001,
@@ -295,6 +316,8 @@
   {"bf547m", BFIN_CPU_BF547M, 0x0003,
WA_SPECULATIVE_LOADS | WA_INDIRECT_CALLS | WA_0574},

+  {"bf547", BFIN_CPU_BF547, 0x0004,
+   WA_SPECULATIVE_LOADS | WA_INDIRECT_CALLS | WA_0574},
   {"bf547", BFIN_CPU_BF547, 0x0002,
WA_SPECULATIVE_LOADS | WA_INDIRECT_CALLS | WA_0574},
   {"bf547", BFIN_CPU_BF547, 0x0001,
@@ -306,6 +329,8 @@
   {"bf548m", BFIN_CPU_BF548M, 0x0003,
WA_SPECULATIVE_LOADS | WA_INDIRECT_CALLS | WA_0574},

+  {"bf548", BFIN_CPU_BF548, 0x0004,
+   WA_SPECULATIVE_LOADS | WA_INDIRECT_CALLS | WA_0574},
   {"bf548", BFIN_CPU_BF548, 0x0002,
WA_SPECULATIVE_LOADS | WA_INDIRECT_CALLS | WA_0574},
   {"bf548", BFIN_CPU_BF548, 0x0001,
@@ -317,6 +342,8 @@
   {"bf549m", BFIN_CPU_BF549M, 0x0003,
WA_SPECULATIVE_LOADS | WA_INDIRECT_CALLS | WA_0574},

+  {"bf549", BFIN_CPU_BF549, 0x0004,
+   WA_SPECULATIVE_LOADS | WA_INDIRECT_CALLS | WA_0574},
   {"bf549", BFIN_CPU_BF549, 0x0002,
WA_SPECULATIVE_LOADS | WA_INDIRECT_CALLS | WA_0574},
   {"bf549", BFIN_CPU_BF549, 0x0001,

FW: [Patch] Update bfin part tests to latest silicon revision

[Henderson, Stuart]

Ping
---

The attached testsuite patch updates the blackfin part macro tests to expect 
the latest silicon revision, as well as fixing up some duplication in the bf51x 
parts.

2011-05-03  Stuart Henderson  

* gcc.target/bfin/mcpu-bf542.c: Update to latest silicon revision.
* gcc.target/bfin/mcpu-bf544.c: Likewise.
* gcc.target/bfin/mcpu-bf547.c: Likewise.
* gcc.target/bfin/mcpu-bf548.c: Likewise.
* gcc.target/bfin/mcpu-bf549.c: Likewise.
* gcc.target/bfin/mcpu-bf512.c: Update to latest silicon revision and
remove duplication.
* gcc.target/bfin/mcpu-bf514.c: Likewise.
* gcc.target/bfin/mcpu-bf516.c: Likewise.
* gcc.target/bfin/mcpu-bf518.c: Likewise.


Thanks,
Stu


Index: gcc/testsuite/gcc.target/bfin/mcpu-bf542.c
===
--- gcc/testsuite/gcc.target/bfin/mcpu-bf542.c  (revision 171215)
+++ gcc/testsuite/gcc.target/bfin/mcpu-bf542.c  (working copy)
@@ -10,8 +10,8 @@
 #error "__ADSPBF54x__ is not defined"
 #endif

-#if __SILICON_REVISION__ != 0x0002
-#error "__SILICON_REVISION__ is not 0x0002"
+#if __SILICON_REVISION__ != 0x0004
+#error "__SILICON_REVISION__ is not 0x0004"
 #endif

 #ifndef __WORKAROUNDS_ENABLED
Index: gcc/testsuite/gcc.target/bfin/mcpu-bf544.c
===
--- gcc/testsuite/gcc.target/bfin/mcpu-bf544.c  (revision 171215)
+++ gcc/testsuite/gcc.target/bfin/mcpu-bf544.c  (working copy)
@@ -10,8 +10,8 @@
 #error "__ADSPBF54x__ is not defined"
 #endif

-#if __SILICON_REVISION__ != 0x0002
-#error "__SILICON_REVISION__ is not 0x0002"
+#if __SILICON_REVISION__ != 0x0004
+#error "__SILICON_REVISION__ is not 0x0004"
 #endif

 #ifndef __WORKAROUNDS_ENABLED
Index: gcc/testsuite/gcc.target/bfin/mcpu-bf547.c
===
--- gcc/testsuite/gcc.target/bfin/mcpu-bf547.c  (revision 171215)
+++ gcc/testsuite/gcc.target/bfin/mcpu-bf547.c  (working copy)
@@ -10,8 +10,8 @@
 #error "__ADSPBF54x__ is not defined"
 #endif

-#if __SILICON_REVISION__ != 0x0002
-#error "__SILICON_REVISION__ is not 0x0002"
+#if __SILICON_REVISION__ != 0x0004
+#error "__SILICON_REVISION__ is not 0x0004"
 #endif

 #ifndef __WORKAROUNDS_ENABLED
Index: gcc/testsuite/gcc.target/bfin/mcpu-bf548.c
===
--- gcc/testsuite/gcc.target/bfin/mcpu-bf548.c  (revision 171215)
+++ gcc/testsuite/gcc.target/bfin/mcpu-bf548.c  (working copy)
@@ -10,8 +10,8 @@
 #error "__ADSPBF54x__ is not defined"
 #endif

-#if __SILICON_REVISION__ != 0x0002
-#error "__SILICON_REVISION__ is not 0x0002"
+#if __SILICON_REVISION__ != 0x0004
+#error "__SILICON_REVISION__ is not 0x0004"
 #endif

 #ifndef __WORKAROUNDS_ENABLED
Index: gcc/testsuite/gcc.target/bfin/mcpu-bf549.c
===
--- gcc/testsuite/gcc.target/bfin/mcpu-bf549.c  (revision 171215)
+++ gcc/testsuite/gcc.target/bfin/mcpu-bf549.c  (working copy)
@@ -10,8 +10,8 @@
 #error "__ADSPBF54x__ is not defined"
 #endif

-#if __SILICON_REVISION__ != 0x0002
-#error "__SILICON_REVISION__ is not 0x0002"
+#if __SILICON_REVISION__ != 0x0004
+#error "__SILICON_REVISION__ is not 0x0004"
 #endif

 #ifndef __WORKAROUNDS_ENABLED
Index: gcc/testsuite/gcc.target/bfin/mcpu-bf512.c
===
--- gcc/testsuite/gcc.target/bfin/mcpu-bf512.c  (revision 171215)
+++ gcc/testsuite/gcc.target/bfin/mcpu-bf512.c  (working copy)
@@ -10,8 +10,8 @@
 #error "__ADSPBF51x__ is not defined"
 #endif

-#if __SILICON_REVISION__ != 0x
-#error "__SILICON_REVISION__ is not 0x"
+#if __SILICON_REVISION__ != 0x0002
+#error "__SILICON_REVISION__ is not 0x0002"
 #endif

 #ifndef __WORKAROUNDS_ENABLED
@@ -29,34 +29,3 @@
 #ifdef __WORKAROUND_SPECULATIVE_SYNCS
 #error "__WORKAROUND_SPECULATIVE_SYNCS is defined"
 #endif
-/* Test for -mcpu=.  */
-/* { dg-do preprocess } */
-/* { dg-bfin-options "-mcpu=bf512" } */
-
-#ifndef __ADSPBF512__
-#error "__ADSPBF512__ is not defined"
-#endif
-
-#ifndef __ADSPBF51x__
-#error "__ADSPBF51x__ is not defined"
-#endif
-
-#if __SILICON_REVISION__ != 0x
-#error "__SILICON_REVISION__ is not 0x"
-#endif
-
-#ifndef __WORKAROUNDS_ENABLED
-#error "__WORKAROUNDS_ENABLED is not defined"
-#endif
-
-#ifdef __WORKAROUND_RETS
-#error "__WORKAROUND_RETS is defined"
-#endif
-
-#ifndef __WORKAROUND_SPECULATIVE_LOADS
-#error "__WORKAROUND_SPECULATIVE_LOADS is not defined"
-#endif
-
-#ifdef __WORKAROUND_SPECULATIVE_SYNCS
-#error "__WORKAROUND_SPECULATIVE_SYNCS is defined"
-#endif
Index: gcc/testsuite/gcc.target/bfin/mcpu-bf514.c
===
--- gcc/testsuite/gcc.target/bfin/mcpu-bf514.c  (revision 171215)
+++ gcc/testsuite/gcc.target/bfin/mcpu-bf514.c  (working copy)
@@ -10,8 +10,8 @@
 #error "__ADSPBF51x__ is not defined"
 #endif

-#if __SILICON_REVISION__ != 0x
-#error "__SILICON_REVISION

FW: [Patch] New bfin divsi/udivsi implementations

[Henderson, Stuart]

Ping
---

The attached patch updates the blackfin ___divsi3 and ___udivsi3 
implementations (and updates ___umodsi3 to match), as well as adding .size 
directives to all functions in the file.


2011-03-24  Stuart Henderson  

* gcc/config/bfin/lib1funcs.asm (___divsi3): New implementation,
add .size directive and unguard .text directive.
(___udivsi3): New implementation and add .size directive.
(___umodsi3): Update to match new ___divsi3/___udivsi3 implementations
and add .size directive.
(___modsi3): Add .size directive.
(___umulsi3_highpart): Likewise.
(___smulsi3_highpart): Likewise.



Thanks,
Stu




Index: gcc/config/bfin/lib1funcs.asm
===
--- gcc/config/bfin/lib1funcs.asm   (revision 171215)
+++ gcc/config/bfin/lib1funcs.asm   (working copy)
@@ -23,36 +23,101 @@
 see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 .  */

+#if defined(__ELF__) && defined(__linux__)
+.section .note.GNU-stack,"",%progbits
+#endif
+
+.text
+
 #ifdef L_divsi3
-.text
 .align 2
 .global ___divsi3;
 .type ___divsi3, STT_FUNC;

 ___divsi3:
-[--SP]= RETS;
-   [--SP] = R7;

-   R2 = -R0;
-CC = R0 < 0;
-   IF CC R0 = R2;
-   R7 = CC;
-
+.Ls_main_branch:
+   R3 = R0 ^ R1;
+   R2 = - R0;
+   R0 = MAX(R0,R2);
R2 = -R1;
-CC = R1 < 0;
-   IF CC R1 = R2;
-   R2 = CC;
-   R7 = R7 ^ R2;
+   R1 = MAX(R1,R2);
+   R2 = R0 >> 1;
+   CC = R2 < R1 (IU);
+   IF CC JUMP .Ls_Q_has_only_one_bit;

-CALL ___udivsi3;
+   P1 = R3;
+   R3 = R1>>1;
+   R3.L = SIGNBITS R3;
+   R1 = LSHIFT R1 BY R3.L;
+   R2 = R1 << 15;
+   CC = R2 == 0;
+   IF !CC JUMP .Ls_use_sfw_D_has_16bit_or_more;

-   CC = R7;
+   R2.L = SIGNBITS R0;
+   R0 = LSHIFT R0 BY R2.L;
+   R2.L = R3.L - R2.L (NS);
+   P2 = R2;
+   CC = R0 == R1;
+   IF CC JUMP .Ls_N_is_MIN_D_is_1_bit_set;
+
+   R1 >>= 17;
+
+.Ls_use_divq_main_branch:
+   AQ = CC;
+
+   LOOP(s_lp_use_divq) LC0 = P2;
+   LOOP_BEGIN s_lp_use_divq;
+   DIVQ(R0, R1);
+   LOOP_END s_lp_use_divq;
+
+   R0 = EXTRACT(R0, R2.L) (Z);
R1 = -R0;
+   CC = P1<0;
IF CC R0 = R1;
+   RTS;

-   R7 = [SP++];
-RETS = [SP++];
-RTS;
+.Ls_N_is_MIN_D_is_1_bit_set:
+   R0 = 1;
+   R0 = LSHIFT R0 BY R2.L;
+   R1 = -R0;
+   CC = P1 < 0;
+   IF CC R0 = R1;
+   RTS;
+
+.Ls_use_sfw_D_has_16bit_or_more:
+   R2 = R0 >> 1;
+   R2.L = SIGNBITS R2;
+   R3.H = R3.L - R2.L (NS);
+   R3 = R3 >>16;
+   P2 = R3;
+   R0 = LSHIFT R0 BY R2.L;
+   R0 = R0 - R1;
+   CC = !BITTST(R0, 31);
+   R1 >>>= 1;
+
+   LOOP(s__use_sfw_loop) LC0 = P2;
+   LOOP_BEGIN s__use_sfw_loop;
+   R0 = R0 + R1, R2 = R0 - R1;
+   IF CC R0 = R2;
+   R0 = ROT R0 BY 1;
+   LOOP_END s__use_sfw_loop;
+
+   R0 = EXTRACT(R0, R3.L)(Z);
+   R0 = ROT R0 BY 1;
+   R1 = -R0;
+   CC = P1<0;
+   IF CC R0 = R1;
+   RTS;
+
+.Ls_Q_has_only_one_bit:
+   CC = R1 <= R0 (IU);
+   R0 = CC;
+   R1 = -R0;
+   CC = R3<0;
+   IF CC R0 = R1;
+   RTS;
+   .size ___divsi3, .-___divsi3;
 #endif

 #ifdef L_modsi3
@@ -71,6 +136,8 @@
R0 = R1 - R2;
RETS = [SP++];
RTS;
+
+.size ___modsi3, .-___modsi3
 #endif

 #ifdef L_udivsi3
@@ -79,26 +146,87 @@
 .type ___udivsi3, STT_FUNC;

 ___udivsi3:
-P0 = 32;
-LSETUP (0f, 1f) LC0 = P0;
-   /* upper half of dividend */
-R3 = 0;
-0:
-   /* The first time round in the loop we shift in garbage, but since we
-  perform 33 shifts, it doesn't matter.  */
+.Lu_main_branch:
+   R2 = R0 >> 1;
+   CC = R2 < R1 (IU);
+   IF CC JUMP .Lu_Q_has_only_one_bit;
+
+   R3 = R1 >> 1;
+   R3.L = SIGNBITS R3;
+   R1 = LSHIFT R1 BY R3.L;
+   R2 = R1 << 15;
+   CC = R2 == 0;
+   IF !CC JUMP .Lu_use_sfw_D_has_16bit_or_more;
+
+   CC = R0 < 0;
+   IF CC JUMP .Lu_MSB_of_N_is_1;
+
+   R1.L = SIGNBITS R0;
+   R2.L = R3.L - R1.L (NS);
+   P2 = R2;
+   R0 = LSHIFT R0 BY R1.L;
+   R1 >>= 17;
+
+.Lu_use_divq_main_branch:
+   AQ = CC;
+
+   LOOP(u_lp_use_divq_when_MSB_of_N_is_0) LC0 = P2;
+   LOOP_BEGIN u_lp_use_divq_when_MSB_of_N_is_0;
+   DIVQ(R0, R1);
+   LOOP_END u_lp_use_divq_when_MSB_of_N_is_0;
+
+   R0 = EXTRACT(R0, R2.L) (Z);
+   RTS;
+
+.Lu_MSB_of_N_is_1:
+   R3 = R3.L (Z);
+   P2 = R3;
+   R0 = R0 - R1;
+   R1 >>= 17;
+
+.Lu_use_divq_when_MSB_of_N_is_1:
+   R2 = ~R0;
+   R2 = R2 >> 31;
+   CC = BITTST(R0, 31);
+   AQ = CC;
+
+   LOOP(u_lp_use_divq_MSB_of_N_is_1) LC0 = P2;
+   LOOP_BEGIN u_lp_use_divq_MSB_of_N_is_1;
+   DIVQ(R0, R1);
+   LOOP_END u_lp_use_divq_MSB_of_N_is_1;
+
+   R2 = LSHIFT R2 BY R3.

Re: [PATCH] Typed DWARF stack

[H.J. Lu]

On Sat, Apr 16, 2011 at 1:11 AM, Jakub Jelinek  wrote:
> On Fri, Mar 25, 2011 at 12:32:37PM +0100, Jakub Jelinek wrote:
>> As I said in my GCC Summit talk, currently we just give up on
>> any floating point/_Decimal*/__int128 and for 32-bit targets even
>> long long expressions, as those can't be represented in DWARF4,
>> while var-tracking has all that often available.
>
> ...
>
> This is an updated patch for the typed DWARF stack support,
> against current trunk.  I've changed DW_OP_GNU_reinterpret
> from 0xf8 to 0xf9, because 0xf8 is taken by PGI and e.g. binutils prefers no
> clashes between extension opcodes, otherwise readers would need to switch
> based on producer.  When we are close to running out of extension opcodes,
> we may reconsider (especially as the HP block is quite large).
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2011-04-16  Jakub Jelinek  
>
>        * dwarf2.h (DW_OP_GNU_const_type, DW_OP_GNU_regval_type,
>        DW_OP_GNU_deref_type, DW_OP_GNU_convert, DW_OP_GNU_reinterpret): New.
>
>        * dwarf2out.c (get_address_mode): New inline.
>        (mem_loc_descriptor): Add MEM_MODE parameter, adjust recursive calls,
>        if not dwarf_strict emit
>        DW_OP_GNU_{{const,regval,deref}_type,convert,reinterpret} when
>        desirable.  Handle FLOAT_EXTEND, FLOAT_TRUNCATE, FLOAT,
>        UNSIGNED_FLOAT, FIX and UNSIGNED_FIX.  Just return NULL for
>        FMA, STRICT_LOW_PART, CONST_VECTOR and CONST_FIXED.
>        (dwarf2out_frame_debug_cfa_expression, reg_loc_descriptor,
>        dw_loc_list_1, cst_pool_loc_descr, loc_list_from_tree): Adjust
>        mem_loc_descriptor callers.
>        (dwarf_stack_op_name, size_of_loc_descr, output_loc_operands,
>        output_loc_operands_raw, hash_loc_operands, compare_loc_operands):
>        Handle DW_OP_GNU_const_type, DW_OP_GNU_regval_type,
>        DW_OP_GNU_deref_type, DW_OP_GNU_convert and DW_OP_GNU_reinterpret.
>        (base_types): New variable.
>        (get_base_type_offset, calc_base_type_die_sizes,
>        base_type_for_mode, mark_base_types, base_type_cmp,
>        move_marked_base_types): New functions.
>        (calc_die_sizes): Assert that die_offset is 0 or equal to
>        next_die_offset.
>        (loc_descriptor): Only handle here lowpart SUBREGs of REG, for
>        others defer to mem_loc_descriptor.  Adjust mem_loc_descriptor
>        callers.  If not dwarf_strict, call mem_loc_descriptor even for
>        non-MODE_INT modes or MODE_INT modes larger than DWARF2_ADDR_SIZE.
>        (gen_subprogram_die): Don't give up on call site parameters
>        with non-integral or large integral modes.  Adjust
>        mem_loc_descriptor callers.
>        (prune_unused_types): Call prune_unused_types_mark on base_types
>        vector entries.
>        (resolve_addr): Call mark_base_types.
>        (dwarf2out_finish): Call move_marked_base_types.

This caused:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48853


H.J.

Re: FW: [Patch] Update bfin part tests to latest silicon revision

[Bernd Schmidt]

On 05/03/2011 03:26 PM, Henderson, Stuart wrote:
> Ping
> ---
> 
> The attached testsuite patch updates the blackfin part macro tests to expect 
> the latest silicon revision, as well as fixing up some duplication in the 
> bf51x parts.
> 
> 2011-05-03  Stuart Henderson  
> 
> * gcc.target/bfin/mcpu-bf542.c: Update to latest silicon revision.
> * gcc.target/bfin/mcpu-bf544.c: Likewise.
> * gcc.target/bfin/mcpu-bf547.c: Likewise.
> * gcc.target/bfin/mcpu-bf548.c: Likewise.
> * gcc.target/bfin/mcpu-bf549.c: Likewise.
> * gcc.target/bfin/mcpu-bf512.c: Update to latest silicon revision and
> remove duplication.
> * gcc.target/bfin/mcpu-bf514.c: Likewise.
> * gcc.target/bfin/mcpu-bf516.c: Likewise.
> * gcc.target/bfin/mcpu-bf518.c: Likewise.

Ok.


Bernd

Re: FW: [Patch] Update bfin parts to latest silicon revisions

[Bernd Schmidt]

On 05/03/2011 03:25 PM, Henderson, Stuart wrote:
> Ping
> ---
> 
> The attached patch adds support for (and changes defaults to) the latest 
> silicon revisions for Blackfin parts.
> 
> 2011-05-03  Stuart Henderson  
> 
> * config/bfin/bfin.c (bfin_cpus): Update silicon revisions.

Ok.

Re: [PATCH, ARM] Fix NEON vset_lane for D registers

[Ramana Radhakrishnan]

On 03/05/11 13:49, Julian Brown wrote:

Hi,

This patch fixes vset_lane intrinsic variants for D-register sized
variables. A typo meant that the wrong lane would be set in many
circumstances.

Tested manually only. OK to apply?


Ok - yes this looks almost obvious but please do a sanity regression run.

Thanks,
Ramana

[PATCH] Finish int_const_binop partial transition

[Richard Guenther]

There are two callers left that call int_const_binop with a 1 notrunc
argument causing non-canonicalized INTEGER_CSTs to be built.  One
is group_case_labels_stmt in tree-cfg.c which can simply use
double_ints (which is what all code using 1 notrunc should do,
similar to old code building INTEGER_CSTs with a NULL type).  The
other one is quite convoluted in our special friend extract_muldiv_1.
I attacked that by simply expanding the int_const_binop call
inline and massaging it until it didn't look gross anymore.  I
left intact most of the structure (which also shows some inconsitency
in sizetype handling).  The goal was no functional change here - so
I hope I succeeded in a 1:1 transformation at this place - 2nd
eyes welcome.

A bootstrap and test with an assertion that we call int_const_binop
with zero notrunc and the two cases transformed nearly finished, a
bootstrap and regtest with the full patch changing all callers is
still running on x86_64-unknown-linux-gnu.

In a followup the extract_muldiv_1 case could be made consistent
with respect to TYPE_IS_SIZETYPE which would allow quite some
simplification in the overflow conditionals ...

Thanks,
Richard.

2011-05-03  Richard Guenther  

* tree.h (int_const_binop): Remove notrunc argument.
* fold-const.c (int_const_binop): Remove notrunc argument.  Always
create integer constants that are properly truncated.
(extract_muldiv_1): Expand one notrunc int_const_binop caller.
(const_binop): Remove zero notrunc argument to int_const_binop.
(size_binop_loc): Likewise.
(fold_div_compare): Likewise.
(maybe_canonicalize_comparison_1): Likewise.
(fold_comparison): Likewise.
(fold_binary_loc): Likewise.
(multiple_of_p): Likewise.
* expr.c (store_constructor): Likewise.
* gimple-fold.c (maybe_fold_offset_to_array_ref): Likewise.
(maybe_fold_stmt_addition): Likewise.
* ipa-prop.c (ipa_modify_call_arguments): Likewise.
* stor-layout.c (layout_type): Likewise.
* tree-data-ref.c (tree_fold_divides_p): Likewise.
* tree-sra.c (build_ref_for_offset): Likewise.
(build_user_friendly_ref_for_offset): Likewise.
* tree-ssa-address.c (maybe_fold_tmr): Likewise.
* tree-ssa-forwprop.c (forward_propagate_addr_expr_1): Likewise.
* tree-ssa-loop-niter.c (inverse): Likewise.
* tree-ssa-pre.c (create_component_ref_by_pieces_1): Likewise.
* tree-ssa.c (maybe_rewrite_mem_ref_base): Likewise.
* tree-switch-conversion.c (check_range): Likewise.
(build_constructors): Likewise.
* tree-vect-generic.c (expand_vector_piecewise): Likewise.
* tree-vrp.c (set_and_canonicalize_value_range): Likewise.
(extract_range_from_assert): Likewise.
(vrp_int_const_binop): Likewise.
(extract_range_from_binary_expr): Likewise.
(extract_range_from_unary_expr): Likewise.
(check_array_ref): Likewise.
(find_case_label_range): Likewise.
(simplify_div_or_mod_using_ranges): Likewise.
* tree-cfg.c (group_case_labels_stmt): Use double-ints for
comparing case labels for merging.


ada/gcc-interface/
* trans.c (gnat_to_gnu): Remove zero notrunc argument to
int_const_binop.
(pos_to_constructor): Likewise.

gfortran/
* trans-types.c (gfc_get_array_type_bounds): Remove zero notrunc
argument to int_const_binop.

Index: gcc/fold-const.c
===
*** gcc/fold-const.c.orig   2011-05-03 15:10:43.0 +0200
--- gcc/fold-const.c2011-05-03 15:31:49.0 +0200
*** int_binop_types_match_p (enum tree_code
*** 936,947 
  
  /* Combine two integer constants ARG1 and ARG2 under operation CODE
 to produce a new constant.  Return NULL_TREE if we don't know how
!to evaluate CODE at compile-time.
! 
!If NOTRUNC is nonzero, do not truncate the result to fit the data type.  */
  
  tree
! int_const_binop (enum tree_code code, const_tree arg1, const_tree arg2, int 
notrunc)
  {
double_int op1, op2, res, tmp;
tree t;
--- 936,945 
  
  /* Combine two integer constants ARG1 and ARG2 under operation CODE
 to produce a new constant.  Return NULL_TREE if we don't know how
!to evaluate CODE at compile-time.  */
  
  tree
! int_const_binop (enum tree_code code, const_tree arg1, const_tree arg2)
  {
double_int op1, op2, res, tmp;
tree t;
*** int_const_binop (enum tree_code code, co
*** 1083,1104 
return NULL_TREE;
  }
  
!   if (notrunc)
! {
!   t = build_int_cst_wide (TREE_TYPE (arg1), res.low, res.high);
! 
!   /* Propagate overflow flags ourselves.  */
!   if (((!uns || is_sizetype) && overflow)
! | TREE_OVERFLOW (arg1) | TREE_OVERFLOW (arg2))
!   {
! t = copy_node (t);
! TREE_OVERFLOW (t) = 1;
!   }
!  

[v3] libstdc++/48750

[Paolo Carlini]

Hi,

the below is what I ended up committing for this PR, very close to the 
preliminary draft I recently attached to Bugzilla. All in all, in my 
opinion the situation wrt the destructors was broken enough that we want 
the patch in the release branch too, if we want to encourage people to 
experiment with this special mode at all.


Tested x86_64-linux, normal, debug, and parallel-mode. Committed to 
mainline for now.


Thanks,
Paolo.

//
2011-05-03  Paolo Carlini  

PR libstdc++/48750
* include/parallel/multiway_merge.h: Run _ValueType destructors.
* include/parallel/multiway_mergesort.h: Likewise.
* include/parallel/quicksort.h: Likewise.
* include/parallel/random_shuffle.h: Likewise.
* include/parallel/partial_sum.h: Likewise.
* include/parallel/losertree.h: Run destructors; minor tweaks.
* include/parallel/par_loop.h: Run destructors, fix memory
allocations and deallocations.
* testsuite/26_numerics/accumulate/48750.cc: New.

* testsuite/ext/profile/mutex_extensions_neg.cc: Do not run in
parallel-mode to avoid spurious multiple errors.

Index: include/parallel/multiway_merge.h
===
--- include/parallel/multiway_merge.h   (revision 173297)
+++ include/parallel/multiway_merge.h   (working copy)
@@ -1045,11 +1045,12 @@
_ValueType;
 
   // __k sequences.
-  _SeqNumber __k = static_cast<_SeqNumber>(__seqs_end - __seqs_begin);
+  const _SeqNumber __k
+   = static_cast<_SeqNumber>(__seqs_end - __seqs_begin);
 
-  _ThreadIndex __num_threads = omp_get_num_threads();
+  const _ThreadIndex __num_threads = omp_get_num_threads();
 
-  _DifferenceType __num_samples =
+  const _DifferenceType __num_samples =
__gnu_parallel::_Settings::get().merge_oversampling * __num_threads;
 
   _ValueType* __samples = static_cast<_ValueType*>
@@ -1096,6 +1097,10 @@
  __pieces[__slab][__seq].second =
_GLIBCXX_PARALLEL_LENGTH(__seqs_begin[__seq]);
  }
+
+  for (_SeqNumber __s = 0; __s < __k; ++__s)
+   for (_DifferenceType __i = 0; __i < __num_samples; ++__i)
+ __samples[__s * __num_samples + __i].~_ValueType();
   ::operator delete(__samples);
 }
 
@@ -1258,10 +1263,10 @@
__length = std::min<_DifferenceTp>(__length, __total_length);
 
if (__total_length == 0 || __k == 0)
-   {
-  delete[] __ne_seqs;
-  return __target;
-   }
+ {
+   delete[] __ne_seqs;
+   return __target;
+ }
 
std::vector >* __pieces;
 
Index: include/parallel/losertree.h
===
--- include/parallel/losertree.h(revision 173297)
+++ include/parallel/losertree.h(working copy)
@@ -1,6 +1,6 @@
 // -*- C++ -*-
 
-// Copyright (C) 2007, 2008, 2009 Free Software Foundation, Inc.
+// Copyright (C) 2007, 2008, 2009, 2010, 2011 Free Software Foundation, Inc.
 //
 // This file is part of the GNU ISO C++ Library.  This library is free
 // software; you can redistribute it and/or modify it under the terms
@@ -116,7 +116,11 @@
* @brief The destructor.
*/
   ~_LoserTreeBase()
-  { ::operator delete(_M_losers); }
+  {
+   for (unsigned int __i = 0; __i < (2 * _M_k); ++__i)
+ _M_losers[__i].~_Loser();
+   ::operator delete(_M_losers);
+  }
 
   /**
* @brief Initializes the sequence "_M_source" with the element "__key".
@@ -131,15 +135,15 @@
   {
unsigned int __pos = _M_k + __source;
 
-   if(_M_first_insert)
+   if (_M_first_insert)
  {
-   // Construct all keys, so we can easily deconstruct them.
+   // Construct all keys, so we can easily destruct them.
for (unsigned int __i = 0; __i < (2 * _M_k); ++__i)
- new(&(_M_losers[__i]._M_key)) _Tp(__key);
+ ::new(&(_M_losers[__i]._M_key)) _Tp(__key);
_M_first_insert = false;
  }
else
- new(&(_M_losers[__pos]._M_key)) _Tp(__key);
+ _M_losers[__pos]._M_key = __key;
 
_M_losers[__pos]._M_sup = __sup;
_M_losers[__pos]._M_source = __source;
@@ -379,7 +383,7 @@
   }
 
   ~_LoserTreePointerBase()
-  { ::operator delete[](_M_losers); }
+  { delete[] _M_losers; }
 
   int __get_min_source()
   { return _M_losers[0]._M_source; }
@@ -577,7 +581,7 @@
   _Compare _M_comp;
 
 public:
-  _LoserTreeUnguardedBase(unsigned int __k, const _Tp __sentinel,
+  _LoserTreeUnguardedBase(unsigned int __k, const _Tp& __sentinel,
  _Compare __comp = std::less<_Tp>())
   : _M_comp(__comp)
   {
@@ -590,15 +594,24 @@
_M_losers = static_cast<_Loser*>(::operator new(2 * _M_k
* sizeof(_Los

Re: [PATCH] Finish int_const_binop partial transition

[Michael Matz]

Hi,

On Tue, 3 May 2011, Richard Guenther wrote:

> --- 5858,5890 
>   
> /* If these are the same operation types, we can associate them
>assuming no overflow.  */
> !   if (tcode == code)
> ! {
> !   double_int mul;
> !   int overflow_p;
> !   mul = double_int_mul_with_sign
> !   (double_int_ext
> !  (tree_to_double_int (op1),
> !   TYPE_PRECISION (ctype), TYPE_UNSIGNED (ctype)),
> !double_int_ext
> !  (tree_to_double_int (c),
> !   TYPE_PRECISION (ctype), TYPE_UNSIGNED (ctype)),
> !false, &overflow_p);
> !   overflow_p = (((!TYPE_UNSIGNED (ctype)
> !   || (TREE_CODE (ctype) == INTEGER_TYPE
> !   && TYPE_IS_SIZETYPE (ctype))) && overflow_p)
> ! | TREE_OVERFLOW (c) | TREE_OVERFLOW (op1));
> !   if (!double_int_fits_to_tree_p (ctype, mul)
> !   && ((TYPE_UNSIGNED (ctype) && tcode != MULT_EXPR)
> !   || (!(TYPE_UNSIGNED (ctype) && tcode != MULT_EXPR)
> !   && (!TYPE_UNSIGNED (ctype)
> !   || (TREE_CODE (ctype) == INTEGER_TYPE
> !   && TYPE_IS_SIZETYPE (ctype))

Doubled "(TYPE_UNSIGNED (ctype) && tcode != MULT_EXPR)".  Clearer is:

if (!double_int_fits_to_tree_p (ctype, mul)
&& ((TYPE_UNSIGNED (ctype) && tcode != MULT_EXPR)
|| !TYPE_UNSIGNED (ctype)
|| (TREE_CODE (ctype) == INTEGER_TYPE
&& TYPE_IS_SIZETYPE (ctype

I've tried to determine if it's otherwise an equivalent transformation but 
became confused with your intermediate updating of the overflow_p flag.
The new code sort of makes sense but I can't say if it's exactly what the 
old code did :)


Ciao,
Michael.

[PATCH] Cleanup expand_shift

[Richard Guenther]

This is the promised followup to the expand_shift reorg.  The following
patch makes the worker take an RTL expanded shift amount and avoids
re-creating adjusted trees if it recurses for expanding rotates.  Most
of the scary code (involving the conversions) originated from the
fix for PR27861 - but I'm not sure if that bug was actually a side-effect
of using make_tree here.  I'm also not sure how much testing coverage
we have for this particular piece of code.

Anway, I'll bootstrap and test this on x86_64-unknown-linux-gnu
and I have verified PR27861 doesn't re-occur with a cross to
mipsel-linux-gnu.

Ok for trunk if it succeeds?

Thanks,
Richard.

2011-05-03  Richard Guenther  

* expmed.c (expand_variable_shift): Rename to ...
(expand_shift_1): ... this.  Take an expanded shift amount.
For rotates recurse directly not building trees for the shift amount.
(expand_variable_shift): Wrap around expand_shift_1.
(expand_shift): Adjust.

Index: gcc/expmed.c
===
*** gcc/expmed.c(revision 173299)
--- gcc/expmed.c(working copy)
*** expand_dec (rtx target, rtx dec)
*** 2034,2047 
  
  /* Output a shift instruction for expression code CODE,
 with SHIFTED being the rtx for the value to shift,
!and AMOUNT the tree for the amount to shift by.
 Store the result in the rtx TARGET, if that is convenient.
 If UNSIGNEDP is nonzero, do a logical shift; otherwise, arithmetic.
 Return the rtx for where the value is.  */
  
! rtx
! expand_variable_shift (enum tree_code code, enum machine_mode mode, rtx 
shifted,
!  tree amount, rtx target, int unsignedp)
  {
rtx op1, temp = 0;
int left = (code == LSHIFT_EXPR || code == LROTATE_EXPR);
--- 2034,2047 
  
  /* Output a shift instruction for expression code CODE,
 with SHIFTED being the rtx for the value to shift,
!and AMOUNT the rtx for the amount to shift by.
 Store the result in the rtx TARGET, if that is convenient.
 If UNSIGNEDP is nonzero, do a logical shift; otherwise, arithmetic.
 Return the rtx for where the value is.  */
  
! static rtx
! expand_shift_1 (enum tree_code code, enum machine_mode mode, rtx shifted,
!   rtx amount, rtx target, int unsignedp)
  {
rtx op1, temp = 0;
int left = (code == LSHIFT_EXPR || code == LROTATE_EXPR);
*** expand_variable_shift (enum tree_code co
*** 2055,2061 
int attempt;
bool speed = optimize_insn_for_speed_p ();
  
!   op1 = expand_normal (amount);
op1_mode = GET_MODE (op1);
  
/* Determine whether the shift/rotate amount is a vector, or scalar.  If the
--- 2055,2061 
int attempt;
bool speed = optimize_insn_for_speed_p ();
  
!   op1 = amount;
op1_mode = GET_MODE (op1);
  
/* Determine whether the shift/rotate amount is a vector, or scalar.  If the
*** expand_variable_shift (enum tree_code co
*** 2140,2164 
 code below.  */
  
  rtx subtarget = target == shifted ? 0 : target;
! tree new_amount, other_amount;
  rtx temp1;
! tree type = TREE_TYPE (amount);
! if (GET_MODE (op1) != TYPE_MODE (type)
! && GET_MODE (op1) != VOIDmode)
!   op1 = convert_to_mode (TYPE_MODE (type), op1, 1);
! new_amount = make_tree (type, op1);
  other_amount
!   = fold_build2 (MINUS_EXPR, type,
!  build_int_cst (type, GET_MODE_BITSIZE (mode)),
!  new_amount);
  
  shifted = force_reg (mode, shifted);
  
! temp = expand_variable_shift (left ? LSHIFT_EXPR : RSHIFT_EXPR,
!   mode, shifted, new_amount, 0, 1);
! temp1 = expand_variable_shift (left ? RSHIFT_EXPR : LSHIFT_EXPR,
!mode, shifted, other_amount,
!subtarget, 1);
  return expand_binop (mode, ior_optab, temp, temp1, target,
   unsignedp, methods);
}
--- 2140,2161 
 code below.  */
  
  rtx subtarget = target == shifted ? 0 : target;
! rtx new_amount, other_amount;
  rtx temp1;
! 
! new_amount = amount;
  other_amount
!   = simplify_gen_binary (MINUS, GET_MODE (amount),
!  GEN_INT (GET_MODE_BITSIZE (mode)),
!  amount);
  
  shifted = force_reg (mode, shifted);
  
! temp = expand_shift_1 (left ? LSHIFT_EXPR : RSHIFT_EXPR,
!mode, shifted, new_amount, 0, 1);
! temp1 = expand_shift_1 (left ? RSHIFT_EXPR : LSHIFT_EXPR,
! mode, shifted, other_amount,
!

Re: [PATCH] Finish int_const_binop partial transition

[Richard Guenther]

On Tue, 3 May 2011, Michael Matz wrote:

> Hi,
> 
> On Tue, 3 May 2011, Richard Guenther wrote:
> 
> > --- 5858,5890 
> >   
> > /* If these are the same operation types, we can associate them
> >  assuming no overflow.  */
> > !   if (tcode == code)
> > !   {
> > ! double_int mul;
> > ! int overflow_p;
> > ! mul = double_int_mul_with_sign
> > ! (double_int_ext
> > !(tree_to_double_int (op1),
> > ! TYPE_PRECISION (ctype), TYPE_UNSIGNED (ctype)),
> > !  double_int_ext
> > !(tree_to_double_int (c),
> > ! TYPE_PRECISION (ctype), TYPE_UNSIGNED (ctype)),
> > !  false, &overflow_p);
> > ! overflow_p = (((!TYPE_UNSIGNED (ctype)
> > ! || (TREE_CODE (ctype) == INTEGER_TYPE
> > ! && TYPE_IS_SIZETYPE (ctype))) && overflow_p)
> > !   | TREE_OVERFLOW (c) | TREE_OVERFLOW (op1));
> > ! if (!double_int_fits_to_tree_p (ctype, mul)
> > ! && ((TYPE_UNSIGNED (ctype) && tcode != MULT_EXPR)
> > ! || (!(TYPE_UNSIGNED (ctype) && tcode != MULT_EXPR)
> > ! && (!TYPE_UNSIGNED (ctype)
> > ! || (TREE_CODE (ctype) == INTEGER_TYPE
> > ! && TYPE_IS_SIZETYPE (ctype))
> 
> Doubled "(TYPE_UNSIGNED (ctype) && tcode != MULT_EXPR)".  Clearer is:
> 
> if (!double_int_fits_to_tree_p (ctype, mul)
> && ((TYPE_UNSIGNED (ctype) && tcode != MULT_EXPR)
> || !TYPE_UNSIGNED (ctype)
> || (TREE_CODE (ctype) == INTEGER_TYPE
> && TYPE_IS_SIZETYPE (ctype

Indeed, fixed.

> I've tried to determine if it's otherwise an equivalent transformation but 
> became confused with your intermediate updating of the overflow_p flag.
> The new code sort of makes sense but I can't say if it's exactly what the 
> old code did :)

:)  Another question is why exactly the old code did what it did.

Richard.

Re: [PATCH, ARM] Fix NEON vset_lane for D registers

[Richard Earnshaw]

On Tue, 2011-05-03 at 13:49 +0100, Julian Brown wrote:
> Hi,
> 
> This patch fixes vset_lane intrinsic variants for D-register sized
> variables. A typo meant that the wrong lane would be set in many
> circumstances.
> 
> Tested manually only. OK to apply?
> 
> Thanks,
> 
> Julian
> 
> ChangeLog
> 
> gcc/
> * config/arm/neon.md (vec_set_internal): Fix misplaced
> parenthesis in D-register case.

Presumably this is a silent 'wrong-code' bug.  If so, what about
released compilers?

R.

Re: [patch, ARM] Fix PR target/48252

[Ramana Radhakrishnan]

I have no objections to this going into 4.5 and 4.6 since it corrects
the implementation of the neon intrinsics but please check with the
release managers.


OK to backport to 4.5 and 4.6 - both tested on arm-linux-gnueabi?



Ok. Please allow 24 hours for an RM (cc'd) to comment since this is 
technically not a regression but is a long term bug that needs fixing.


cheers
Ramana



Thanks,
Ira

4.5 and 4.6 ChangeLog:

Backport from mainline:
2011-04-18  Ulrich Weigand
   Ira Rosen

PR target/48252
* config/arm/arm.c (neon_emit_pair_result_insn): Swap arguments
to match neon_vzip/vuzp/vtrn_internal.
* config/arm/neon.md (neon_vtrn_internal): Make both
outputs explicitly dependent on both inputs.
(neon_vzip_internal, neon_vuzp_internal): Likewise.

testsuite/Changelog:

Backport from mainline:
2011-04-18  Ulrich Weigand
   Ira Rosen

PR target/48252
* gcc.target/arm/pr48252.c: New test.


4.5 patch:

Index: config/arm/arm.c
===
--- config/arm/arm.c(revision 172714)
+++ config/arm/arm.c(working copy)
@@ -18237,7 +18237,7 @@ neon_emit_pair_result_insn (enum machine_mode mode
rtx tmp1 = gen_reg_rtx (mode);
rtx tmp2 = gen_reg_rtx (mode);

-  emit_insn (intfn (tmp1, op1, tmp2, op2));
+  emit_insn (intfn (tmp1, op1, op2, tmp2));

emit_move_insn (mem, tmp1);
mem = adjust_address (mem, mode, GET_MODE_SIZE (mode));
Index: config/arm/neon.md
===
--- config/arm/neon.md  (revision 172714)
+++ config/arm/neon.md  (working copy)
@@ -3895,13 +3895,14 @@

  (define_insn "neon_vtrn_internal"
[(set (match_operand:VDQW 0 "s_register_operand" "=w")
-   (unspec:VDQW [(match_operand:VDQW 1 "s_register_operand" "0")]
-UNSPEC_VTRN1))
-   (set (match_operand:VDQW 2 "s_register_operand" "=w")
-(unspec:VDQW [(match_operand:VDQW 3 "s_register_operand" "2")]
-UNSPEC_VTRN2))]
+(unspec:VDQW [(match_operand:VDQW 1 "s_register_operand" "0")
+  (match_operand:VDQW 2 "s_register_operand" "w")]
+ UNSPEC_VTRN1))
+   (set (match_operand:VDQW 3 "s_register_operand" "=2")
+ (unspec:VDQW [(match_dup 1) (match_dup 2)]
+ UNSPEC_VTRN2))]
"TARGET_NEON"
-  "vtrn.\t%0, %2"
+  "vtrn.\t%0, %3"
[(set (attr "neon_type")
(if_then_else (ne (symbol_ref "") (const_int 0))
  (const_string "neon_bp_simple")
@@ -3921,13 +3922,14 @@

  (define_insn "neon_vzip_internal"
[(set (match_operand:VDQW 0 "s_register_operand" "=w")
-   (unspec:VDQW [(match_operand:VDQW 1 "s_register_operand" "0")]
-UNSPEC_VZIP1))
-   (set (match_operand:VDQW 2 "s_register_operand" "=w")
-(unspec:VDQW [(match_operand:VDQW 3 "s_register_operand" "2")]
-UNSPEC_VZIP2))]
+(unspec:VDQW [(match_operand:VDQW 1 "s_register_operand" "0")
+  (match_operand:VDQW 2 "s_register_operand" "w")]
+ UNSPEC_VZIP1))
+   (set (match_operand:VDQW 3 "s_register_operand" "=2")
+(unspec:VDQW [(match_dup 1) (match_dup 2)]
+ UNSPEC_VZIP2))]
"TARGET_NEON"
-  "vzip.\t%0, %2"
+  "vzip.\t%0, %3"
[(set (attr "neon_type")
(if_then_else (ne (symbol_ref "") (const_int 0))
  (const_string "neon_bp_simple")
@@ -3947,13 +3949,14 @@

  (define_insn "neon_vuzp_internal"
[(set (match_operand:VDQW 0 "s_register_operand" "=w")
-   (unspec:VDQW [(match_operand:VDQW 1 "s_register_operand" "0")]
+(unspec:VDQW [(match_operand:VDQW 1 "s_register_operand" "0")
+  (match_operand:VDQW 2 "s_register_operand" "w")]
   UNSPEC_VUZP1))
-   (set (match_operand:VDQW 2 "s_register_operand" "=w")
-(unspec:VDQW [(match_operand:VDQW 3 "s_register_operand" "2")]
-UNSPEC_VUZP2))]
+   (set (match_operand:VDQW 3 "s_register_operand" "=2")
+(unspec:VDQW [(match_dup 1) (match_dup 2)]
+ UNSPEC_VUZP2))]
"TARGET_NEON"
-  "vuzp.\t%0, %2"
+  "vuzp.\t%0, %3"
[(set (attr "neon_type")
(if_then_else (ne (symbol_ref "") (const_int 0))
  (const_string "neon_bp_simple")
Index: testsuite/gcc.target/arm/pr48252.c
===
--- testsuite/gcc.target/arm/pr48252.c  (revision 0)
+++ testsuite/gcc.target/arm/pr48252.c  (revision 0)
@@ -0,0 +1,32 @@
+/* { dg-do run } */
+/* { dg-require-effective-target arm_neon_hw } */
+/* { dg-options "-O2" } */
+/* { dg-add-options arm_neon } */
+
+#include "arm_neon.h"
+#include
+
+int main(void)
+{
+uint8x8_t v1 = {1, 1, 1, 1, 1, 1, 1, 1};
+uint8x8_t v2 = {2, 2, 2, 2, 2, 2, 2, 2};
+uint8x8x2_t vd1, vd2;
+union {uin

Re: [patch, ARM] Fix PR target/48252

[Richard Guenther]

On Tue, 3 May 2011, Ramana Radhakrishnan wrote:

> 
> > > I have no objections to this going into 4.5 and 4.6 since it corrects
> > > the implementation of the neon intrinsics but please check with the
> > > release managers.
> > 
> > OK to backport to 4.5 and 4.6 - both tested on arm-linux-gnueabi?
> 
> 
> Ok. Please allow 24 hours for an RM (cc'd) to comment since this is
> technically not a regression but is a long term bug that needs fixing.

As it's purely target local we defer to the target maintainers.

Richard.

> cheers
> Ramana
> 
> > 
> > Thanks,
> > Ira
> > 
> > 4.5 and 4.6 ChangeLog:
> > 
> > Backport from mainline:
> > 2011-04-18  Ulrich Weigand
> >Ira Rosen
> > 
> > PR target/48252
> > * config/arm/arm.c (neon_emit_pair_result_insn): Swap arguments
> > to match neon_vzip/vuzp/vtrn_internal.
> > * config/arm/neon.md (neon_vtrn_internal): Make both
> > outputs explicitly dependent on both inputs.
> > (neon_vzip_internal, neon_vuzp_internal): Likewise.
> > 
> > testsuite/Changelog:
> > 
> > Backport from mainline:
> > 2011-04-18  Ulrich Weigand
> >Ira Rosen
> > 
> > PR target/48252
> > * gcc.target/arm/pr48252.c: New test.
> > 
> > 
> > 4.5 patch:
> > 
> > Index: config/arm/arm.c
> > ===
> > --- config/arm/arm.c(revision 172714)
> > +++ config/arm/arm.c(working copy)
> > @@ -18237,7 +18237,7 @@ neon_emit_pair_result_insn (enum machine_mode mode
> > rtx tmp1 = gen_reg_rtx (mode);
> > rtx tmp2 = gen_reg_rtx (mode);
> > 
> > -  emit_insn (intfn (tmp1, op1, tmp2, op2));
> > +  emit_insn (intfn (tmp1, op1, op2, tmp2));
> > 
> > emit_move_insn (mem, tmp1);
> > mem = adjust_address (mem, mode, GET_MODE_SIZE (mode));
> > Index: config/arm/neon.md
> > ===
> > --- config/arm/neon.md  (revision 172714)
> > +++ config/arm/neon.md  (working copy)
> > @@ -3895,13 +3895,14 @@
> > 
> >   (define_insn "neon_vtrn_internal"
> > [(set (match_operand:VDQW 0 "s_register_operand" "=w")
> > -   (unspec:VDQW [(match_operand:VDQW 1 "s_register_operand" "0")]
> > -UNSPEC_VTRN1))
> > -   (set (match_operand:VDQW 2 "s_register_operand" "=w")
> > -(unspec:VDQW [(match_operand:VDQW 3 "s_register_operand" "2")]
> > -UNSPEC_VTRN2))]
> > +(unspec:VDQW [(match_operand:VDQW 1 "s_register_operand" "0")
> > +  (match_operand:VDQW 2 "s_register_operand" "w")]
> > + UNSPEC_VTRN1))
> > +   (set (match_operand:VDQW 3 "s_register_operand" "=2")
> > + (unspec:VDQW [(match_dup 1) (match_dup 2)]
> > + UNSPEC_VTRN2))]
> > "TARGET_NEON"
> > -  "vtrn.\t%0, %2"
> > +  "vtrn.\t%0, %3"
> > [(set (attr "neon_type")
> > (if_then_else (ne (symbol_ref "") (const_int 0))
> >   (const_string "neon_bp_simple")
> > @@ -3921,13 +3922,14 @@
> > 
> >   (define_insn "neon_vzip_internal"
> > [(set (match_operand:VDQW 0 "s_register_operand" "=w")
> > -   (unspec:VDQW [(match_operand:VDQW 1 "s_register_operand" "0")]
> > -UNSPEC_VZIP1))
> > -   (set (match_operand:VDQW 2 "s_register_operand" "=w")
> > -(unspec:VDQW [(match_operand:VDQW 3 "s_register_operand" "2")]
> > -UNSPEC_VZIP2))]
> > +(unspec:VDQW [(match_operand:VDQW 1 "s_register_operand" "0")
> > +  (match_operand:VDQW 2 "s_register_operand" "w")]
> > + UNSPEC_VZIP1))
> > +   (set (match_operand:VDQW 3 "s_register_operand" "=2")
> > +(unspec:VDQW [(match_dup 1) (match_dup 2)]
> > + UNSPEC_VZIP2))]
> > "TARGET_NEON"
> > -  "vzip.\t%0, %2"
> > +  "vzip.\t%0, %3"
> > [(set (attr "neon_type")
> > (if_then_else (ne (symbol_ref "") (const_int 0))
> >   (const_string "neon_bp_simple")
> > @@ -3947,13 +3949,14 @@
> > 
> >   (define_insn "neon_vuzp_internal"
> > [(set (match_operand:VDQW 0 "s_register_operand" "=w")
> > -   (unspec:VDQW [(match_operand:VDQW 1 "s_register_operand" "0")]
> > +(unspec:VDQW [(match_operand:VDQW 1 "s_register_operand" "0")
> > +  (match_operand:VDQW 2 "s_register_operand" "w")]
> >UNSPEC_VUZP1))
> > -   (set (match_operand:VDQW 2 "s_register_operand" "=w")
> > -(unspec:VDQW [(match_operand:VDQW 3 "s_register_operand" "2")]
> > -UNSPEC_VUZP2))]
> > +   (set (match_operand:VDQW 3 "s_register_operand" "=2")
> > +(unspec:VDQW [(match_dup 1) (match_dup 2)]
> > + UNSPEC_VUZP2))]
> > "TARGET_NEON"
> > -  "vuzp.\t%0, %2"
> > +  "vuzp.\t%0, %3"
> > [(set (attr "neon_type")
> > (if_then_else (ne (symbol_ref "") (const_int 0))
> >   (const_string "neon_bp_simple")
> > Index: test

Re: [google] Use R_ARM_GOT_PREL to simplify global address loading from GOT (issue4433079)

[Richard Earnshaw]

On Fri, 2011-04-29 at 11:18 +0800, Carrot Wei wrote:
> Yes, after porting it to google/main.
> 
> Carrot
> 
> On Thu, Apr 28, 2011 at 10:26 PM, Diego Novillo  wrote:
> > Will you be proposing this patch for trunk as well?
> >
> >
> > Diego.
> >

At the very least a trunk version of this patch will need to deal with
assembly formats that do not support this relocation (I think pe-coff is
one such format).  


R.

mips_handle_option global state avoidance, part 1

[Joseph S. Myers]

This patch implements the simpler parts of stopping mips_handle_option
from using global state.  Three options are made to use the Enum
machinery instead of custom option handler code, while a fourth is
adjusted to set a field through the opts pointer.  The remaining (and
rather more complicated) part will be converting -march=, -mtune= and
-mips to use the Enum .opt machinery, which I'll do in a separate
patch.

Tested building cc1 and xgcc for cross to mips-elf.  Will commit to
trunk in the absence of target maintainer objections.

2011-05-03  Joseph Myers  

* config/mips/mips-opts.h: New.
* config/mips/mips.c (enum mips_r10k_cache_barrier_setting): Move
to mips-opts.h.
(mips_abi, mips_code_readable, mips_r10k_cache_barriee): Remove.
(mips_handle_option): Don't handle OPT_mabi_, OPT_mcode_readable_
or OPT_mr10k_cache_barrier_ here.  Access mips_cache_flush_func
via opts pointer.
* config/mips/mips.h (enum mips_code_readable_setting): Move to
mips-opts.h.
(mips_abi, mips_code_readable): Don't declare.
* config/mips/mips.opt (config/mips/mips-opts.h): New
HeaderInclude.
(mabi=): Use Enum and Var.
(mips_abi): New Enum and EnumValue entries.
(mcode-readable=): Use Enum and Var.
(mips_code_readable_setting): New Enum and EnumValue entries.
(mr10k-cache-barrier=): Use Enum and Var.
(mips_r10k_cache_barrier_setting): New Enum and EnumValue entries.

Index: gcc/config/mips/mips.opt
===
--- gcc/config/mips/mips.opt(revision 173296)
+++ gcc/config/mips/mips.opt(working copy)
@@ -18,6 +18,9 @@
 ; along with GCC; see the file COPYING3.  If not see
 ; .
 
+HeaderInclude
+config/mips/mips-opts.h
+
 EB
 Driver
 
@@ -25,9 +28,28 @@ EL
 Driver
 
 mabi=
-Target RejectNegative Joined
+Target RejectNegative Joined Enum(mips_abi) Var(mips_abi) 
Init(MIPS_ABI_DEFAULT)
 -mabi=ABI  Generate code that conforms to the given ABI
 
+Enum
+Name(mips_abi) Type(int)
+Known MIPS ABIs (for use with the -mabi= option):
+
+EnumValue
+Enum(mips_abi) String(32) Value(ABI_32)
+
+EnumValue
+Enum(mips_abi) String(o64) Value(ABI_O64)
+
+EnumValue
+Enum(mips_abi) String(n32) Value(ABI_N32)
+
+EnumValue
+Enum(mips_abi) String(64) Value(ABI_64)
+
+EnumValue
+Enum(mips_abi) String(eabi) Value(ABI_EABI)
+
 mabicalls
 Target Report Mask(ABICALLS)
 Generate code that can be used in SVR4-style dynamic objects
@@ -57,9 +79,22 @@ Target Report Mask(CHECK_ZERO_DIV)
 Trap on integer divide by zero
 
 mcode-readable=
-Target RejectNegative Joined
+Target RejectNegative Joined Enum(mips_code_readable_setting) 
Var(mips_code_readable) Init(CODE_READABLE_YES)
 -mcode-readable=SETTINGSpecify when instructions are allowed to access 
code
 
+Enum
+Name(mips_code_readable_setting) Type(enum mips_code_readable_setting)
+Valid arguments to -mcode-readable=:
+
+EnumValue
+Enum(mips_code_readable_setting) String(yes) Value(CODE_READABLE_YES)
+
+EnumValue
+Enum(mips_code_readable_setting) String(pcrel) Value(CODE_READABLE_PCREL)
+
+EnumValue
+Enum(mips_code_readable_setting) String(no) Value(CODE_READABLE_NO)
+
 mdivide-breaks
 Target Report RejectNegative Mask(DIVIDE_BREAKS)
 Use branch-and-break sequences to check for integer divide by zero
@@ -255,9 +290,22 @@ Target Report Mask(PAIRED_SINGLE_FLOAT)
 Use paired-single floating-point instructions
 
 mr10k-cache-barrier=
-Target Joined RejectNegative
+Target Joined RejectNegative Enum(mips_r10k_cache_barrier_setting) 
Var(mips_r10k_cache_barrier) Init(R10K_CACHE_BARRIER_NONE)
 -mr10k-cache-barrier=SETTING   Specify when r10k cache barriers should be 
inserted
 
+Enum
+Name(mips_r10k_cache_barrier_setting) Type(enum 
mips_r10k_cache_barrier_setting)
+Valid arguments to -mr10k-cache-barrier=:
+
+EnumValue
+Enum(mips_r10k_cache_barrier_setting) String(load-store) 
Value(R10K_CACHE_BARRIER_LOAD_STORE)
+
+EnumValue
+Enum(mips_r10k_cache_barrier_setting) String(store) 
Value(R10K_CACHE_BARRIER_STORE)
+
+EnumValue
+Enum(mips_r10k_cache_barrier_setting) String(none) 
Value(R10K_CACHE_BARRIER_NONE)
+
 mrelax-pic-calls
 Target Report Mask(RELAX_PIC_CALLS)
 Try to allow the linker to turn PIC calls into direct calls
Index: gcc/config/mips/mips-opts.h
===
--- gcc/config/mips/mips-opts.h (revision 0)
+++ gcc/config/mips/mips-opts.h (revision 0)
@@ -0,0 +1,39 @@
+/* Definitions for option handling for MIPS.
+   Copyright (C) 1989, 1990, 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998
+   1999, 2000, 2001, 2002, 2003, 2004, 2005, 2007, 2008, 2009, 2010, 2011
+   Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your optio

Re: Toplevel cleanup: disable Java when libffi not supported

[Tom Tromey]

> "Joseph" == Joseph S Myers  writes:

Joseph> arm*-elf are targets where libffi's configure thinks it is supported.

Thanks.

Joseph> So Java (and Go) should be disabled by default when libffi isn't
Joseph> supported, because they'd try by default to build libffi and so
Joseph> a default build will fail.

In the past, libffi could be disabled independently.  This in itself
would not cause libjava to fail, because libjava accounts for this
possibility.

Since the only existing case where there was a libjava port without a
corresponding libffi port has gone away, I think it isn't very important
to try to support this.  In the unlikely event that someone needs this,
they can come up with a new plan to handle it.

Tom

Re: [PATCH, ARM] Fix NEON vset_lane for D registers

[Joseph S. Myers]

On Tue, 3 May 2011, Richard Earnshaw wrote:

> > gcc/
> > * config/arm/neon.md (vec_set_internal): Fix misplaced
> > parenthesis in D-register case.
> 
> Presumably this is a silent 'wrong-code' bug.  If so, what about
> released compilers?

And what about an execution testcase that fails before and passes after 
the patch?  Is it hard to add one for some reason?

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [google] Patch to support calling multi-versioned functions via new GCC builtin. (issue4440078)

[Mike Stump]

On May 3, 2011, at 3:07 AM, Richard Guenther  wrote:
>> 
>> There is no possibility for a high-level dispatch at the source level.
>> And if I'd have to design one I would use function overloading, like
>> 
>> float compute_sth (float) __attribute__((version("sse4")))
>> {
>>  ... sse4 code ...
>> }
>> 
>> float compute_sth (float)
>> {
>>  ... fallback ...
>> }
>> 
>> float foo (float f)
>> {
>>  return compute_sth (f);
>> }
>> 
>> and if you not only want to dispatch for target features you could
>> specify a selector function and value in the attribute.  You might
>> notice that the above eventually matches the target attribute
>> directly, just the frontends need to be taught to emit dispatch
>> code whenever overload resolution results in ambiguities involving
>> target attribute differences.
> 
> Which also would allow the frontend to directly call the sse4 variant
> if you compile with -msse4, avoiding the need for any fancy processing.

And to go one step further, if we had this, we could use this to define all 
data manipulation machine built-ins as generic functions, available to all 
compiles as normal c code, so portable code could use them everywhere, and on 
platforms that had instructions for any of them, they could define them as 
normal built-ins.
> 

Re: C++ PATCHes relating to c++/48834, c++/40975 (array new)

[Jason Merrill]

On 05/03/2011 03:00 AM, Eric Botcazou wrote:

How is it used in Ada?


The front-end doesn't use it directly, it's only used through the gimplifier
by the unsharing phase (unshare_body).  We also have statement expressions.


In that case you wouldn't be affected by this patch; unshare_body uses 
mostly_copy_tree_r, which has its own special case for STATEMENT_LIST.


Jason

Re: [testsuite] Compile gfortran.dg/fmt_g0_6.f08 with -ffloat-store [fwd: tobias.bur...@physik.fu-berlin.de]

[Mike Stump]

On May 3, 2011, at 3:14 AM, Tobias Burnus  
wrote:
> PS: Especially as you are listed as testsuite maintainer, I would be
> happy if you could comment on the testsuite patch at
> http://gcc.gnu.org/ml/fortran/2011-04/msg00331.html

Ok.

Move cgraph_node_set and varpool_node_set out of GGC and make them use pointer_map

[Jan Hubicka]

Hi,
I always considered the cgrpah_node_set/varpool_node_set to be overengineered
but they also turned out to be quite ineffective since we do quite a lot of
queries into them during stremaing out.

This patch moves them to pointer_map, like I did for streamer cache.  While
doing so I needed to get the structure out of GGC memory since pointer_map is
not ggc firendly. This is not a deal at all, because the sets can only point to
live cgraph/varpool entries anyway. Pointing to removed ones would lead to
spectacular failures in any case.

Bootstrapped/regtested x86_64-linux, OK?

Honza

* cgraph.h (cgraph_node_set_def, varpool_node_set_def): Move out of GTY;
replace hash by pointer map.
(cgraph_node_set_element_def, cgraph_node_set_element,
const_cgraph_node_set_element, varpool_node_set_element_def,
varpool_node_set_element, const_varpool_node_set_element): Remove.
(free_cgraph_node_set, free_varpool_node_set): New function.
(cgraph_node_set_size, varpool_node_set_size): Use vector size.
* tree-emutls.c: Free varpool node set.
* ipa-utils.c (cgraph_node_set_new, cgraph_node_set_add,
cgraph_node_set_remove, cgraph_node_set_find, dump_cgraph_node_set,
debug_cgraph_node_set, free_cgraph_node_set, varpool_node_set_new,
varpool_node_set_add, varpool_node_set_remove, varpool_node_set_find,
dump_varpool_node_set, free_varpool_node_set, debug_varpool_node_set):
Move here from ipa.c; implement using pointer_map
* ipa.c (cgraph_node_set_new, cgraph_node_set_add,
cgraph_node_set_remove, cgraph_node_set_find, dump_cgraph_node_set,
debug_cgraph_node_set, varpool_node_set_new,
varpool_node_set_add, varpool_node_set_remove, varpool_node_set_find,
dump_varpool_node_set, debug_varpool_node_set):
Move to ipa-uitls.c.
* lto/lto.c (ltrans_partition_def): Remove GTY annotations.
(ltrans_partitions): Move to heap.
(new_partition): Update.
(free_ltrans_partitions): New function.
(lto_wpa_write_files): Use it.
* passes.c (ipa_write_summaries): Update.
Index: cgraph.h
===
*** cgraph.h(revision 173301)
--- cgraph.h(working copy)
*** DEF_VEC_ALLOC_P(cgraph_node_ptr,gc);
*** 256,265 
  
  /* A cgraph node set is a collection of cgraph nodes.  A cgraph node
 can appear in multiple sets.  */
! struct GTY(()) cgraph_node_set_def
  {
!   htab_t GTY((param_is (struct cgraph_node_set_element_def))) hashtab;
!   VEC(cgraph_node_ptr, gc) *nodes;
  };
  
  typedef struct varpool_node *varpool_node_ptr;
--- 256,265 
  
  /* A cgraph node set is a collection of cgraph nodes.  A cgraph node
 can appear in multiple sets.  */
! struct cgraph_node_set_def
  {
!   struct pointer_map_t *map;
!   VEC(cgraph_node_ptr, heap) *nodes;
  };
  
  typedef struct varpool_node *varpool_node_ptr;
*** DEF_VEC_ALLOC_P(varpool_node_ptr,gc);
*** 270,279 
  
  /* A varpool node set is a collection of varpool nodes.  A varpool node
 can appear in multiple sets.  */
! struct GTY(()) varpool_node_set_def
  {
!   htab_t GTY((param_is (struct varpool_node_set_element_def))) hashtab;
!   VEC(varpool_node_ptr, gc) *nodes;
  };
  
  typedef struct cgraph_node_set_def *cgraph_node_set;
--- 270,279 
  
  /* A varpool node set is a collection of varpool nodes.  A varpool node
 can appear in multiple sets.  */
! struct varpool_node_set_def
  {
!   struct pointer_map_t * map;
!   VEC(varpool_node_ptr, heap) *nodes;
  };
  
  typedef struct cgraph_node_set_def *cgraph_node_set;
*** DEF_VEC_P(varpool_node_set);
*** 288,304 
  DEF_VEC_ALLOC_P(varpool_node_set,gc);
  DEF_VEC_ALLOC_P(varpool_node_set,heap);
  
- /* A cgraph node set element contains an index in the vector of nodes in
-the set.  */
- struct GTY(()) cgraph_node_set_element_def
- {
-   struct cgraph_node *node;
-   HOST_WIDE_INT index;
- };
- 
- typedef struct cgraph_node_set_element_def *cgraph_node_set_element;
- typedef const struct cgraph_node_set_element_def 
*const_cgraph_node_set_element;
- 
  /* Iterator structure for cgraph node sets.  */
  typedef struct
  {
--- 288,293 
*** typedef struct
*** 306,322 
unsigned index;
  } cgraph_node_set_iterator;
  
- /* A varpool node set element contains an index in the vector of nodes in
-the set.  */
- struct GTY(()) varpool_node_set_element_def
- {
-   struct varpool_node *node;
-   HOST_WIDE_INT index;
- };
- 
- typedef struct varpool_node_set_element_def *varpool_node_set_element;
- typedef const struct varpool_node_set_element_def 
*const_varpool_node_set_element;
- 
  /* Iterator structure for varpool node sets.  */
  typedef struct
  {
--- 295,300 
*** void cgraph_node_set_add (cgraph_node_se
*** 632,637 
--- 610,616 
  void cgraph_node_set_remove (cgraph_node_set, s

Re: [google] Patch to support calling multi-versioned functions via new GCC builtin. (issue4440078)

[Joseph S. Myers]

On Tue, 3 May 2011, Mike Stump wrote:

> And to go one step further, if we had this, we could use this to define 
> all data manipulation machine built-ins as generic functions, available 
> to all compiles as normal c code, so portable code could use them 
> everywhere, and on platforms that had instructions for any of them, they 
> could define them as normal built-ins.

I don't think the forms in which some of the machine-specific built-in 
functions exist are particularly good for being available everywhere - 
they are typically defined to correspond exactly to the defined semantics 
of a particular instruction, complete with e.g. the peculiarities of how 
overflow works for that instruction.  But:

* I think it does make sense to make a range of vector operations, 
saturating operations (see the discussion in PR 48580) etc. available as 
generic GNU C on all platforms, with generically defined semantics 
(consistent with how C generally handles things such as overflow), where 
instruction sets commonly have relevant instructions but it isn't readily 
possible to represent the operations with generic C and pattern-match 
them.  (Just as we provide operations such as __builtin_popcount and 
__builtin_clz, for example - and note that __builtin_clz has undefined 
value at 0 rather than being defined to match a machine instruction.)

* Once the operations have generic GNU C, GIMPLE and RTL descriptions, 
intrinsic headers should best use the GNU C representations if possible 
instead of calling built-in functions, and any built-in functions should 
expand to the generic GIMPLE and RTL instead of using UNSPECs.

* It may also make sense for a target architecture to define its 
intrinsics in such a way that they are available on that architecture even 
when the relevant instructions aren't available in a particular 
subarchitecture.  This may be defining the intrinsics in a header if those 
are the public interface, instead of the built-in functions.  See 
a thread starting at  for 
some discussion of doing this for SSE, for example.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: C++ PATCHes relating to c++/48834, c++/40975 (array new)

[Eric Botcazou]

> In that case you wouldn't be affected by this patch; unshare_body uses
> mostly_copy_tree_r, which has its own special case for STATEMENT_LIST.

Right, I added it precisely to support statement expressions in Ada (instead 
of changing copy_tree_r) since we never want to copy them in the unsharing 
phase.  That's why I find the change to copy_tree_r questionable.

-- 
Eric Botcazou

Re: Move cgraph_node_set and varpool_node_set out of GGC and make them use pointer_map

[Richard Guenther]

On Tue, 3 May 2011, Jan Hubicka wrote:

> Hi,
> I always considered the cgrpah_node_set/varpool_node_set to be overengineered
> but they also turned out to be quite ineffective since we do quite a lot of
> queries into them during stremaing out.
> 
> This patch moves them to pointer_map, like I did for streamer cache.  While
> doing so I needed to get the structure out of GGC memory since pointer_map is
> not ggc firendly. This is not a deal at all, because the sets can only point 
> to
> live cgraph/varpool entries anyway. Pointing to removed ones would lead to
> spectacular failures in any case.
> 
> Bootstrapped/regtested x86_64-linux, OK?

Umm, I wonder why ...

> + cgraph_node_set_add (cgraph_node_set set, struct cgraph_node *node)
> + {
> +   void **slot;
> + 
> +   slot = pointer_map_insert (set->map, node);
> + 
> +   if (*slot)
> + {
> +   int index = (size_t) *slot - 1;
> +   gcc_checking_assert ((VEC_index (cgraph_node_ptr, set->nodes, index)
> +== node));
> +   return;
> + }
> + 
> +   *slot = (void *)(size_t) (VEC_length (cgraph_node_ptr, set->nodes) + 1);
> + 
> +   /* Insert into node vector.  */
> +   VEC_safe_push (cgraph_node_ptr, heap, set->nodes, node);

We have both a vector and a pointer-map.  Why not simply use a
pointer-map only?!  I see this may need more re-structuring, eventually
adding an iterator interface to pointer-sets/maps (which would be
nice anyway).

It also makes me think again that why do we have both a cgraph
and a varpool set ... at least when you now deal with a non-GC
data structure you could as well use a vector of void * and
provide macros doing the casting for you, unifying the implementation
itself.

Well, I suppose most of that can be done as a followup (when
eventually the symtab arrives and varpool and cgraph nodes merge anyway).

Thus, ok for now.

Thanks,
Richard.

Re: [google]: initialize language field for clone function struct

[Xinliang David Li]

On Tue, May 3, 2011 at 3:55 AM, Jan Hubicka  wrote:
>> Is this one ok?
> Hi,
> we did quite some work on removing a langhooks for LTO, where they become 
> quite impossible
> So I would like to know what testcase causes the problem and why.

In fold-const.c, there are many of calls to
lang_hooks.decls.global_bindings_p, and the implementation of this in
name-lookup.h will look at the the cfun->language


#define cp_function_chain (cfun->language)

#define current_binding_level   \
  (*(cfun && cp_function_chain && cp_function_chain->bindings \
   ? &cp_function_chain->bindings   \

int
global_bindings_p (void)
{
  return global_scope_p (current_binding_level);
}


In gcc 4.4.3, current_binding_level is defined in a way that
cp_function_chain->bindings is not guarded, resulting in segfault for
clones. In trunk, this is guarded -- but not setting language field
for clone probably just hide the problem.


Thanks,

David


>
> Honza
>>
>> David
>>
>> On Fri, Apr 29, 2011 at 4:38 PM, Xinliang David Li  
>> wrote:
>> > During function cloning, the language field of the src func is not
>> > copied. This can lead to null dereference when gcc calls into langhook
>> > functions.  Unfortunately, I lost track of the test case.
>> >
>> > Ok for trunk ?
>> >
>> > Thanks,
>> >
>> > David
>> >
>> >
>> > 2011-04-29  Xinliang David Li  
>> >
>> >        * tree-inline.c (ininitialize_cfun): Initialize
>> >        language field for clone cfun.
>> >
>

Re: [PATCH] make Ada runtime function building use build_function_type_list

[Eric Botcazou]

> Ping.  http://gcc.gnu.org/ml/gcc-patches/2011-04/msg01675.html

Sorry for the delay.  Moreover, I installed a patch in the meantime that badly 
conflicts with yours, so I've adjusted it.  There was an oversight related to 
the number of integer_type_node in the first case of build_raise_check, but 
unfortunately we don't seem to have a testcase that exercices it.

Tested on x86_64-suse-linux, applied on the mainline.


2011-05-03  Nathan Froyd  
Eric Botcazou  

* gcc-interface/trans.c (gigi): Call build_function_type_list instead
of build_function_type.  Adjust calls to...
(build_raise_check): ...this.  Do not take a void_tree parameter.
Call build_function_type_list instead of build_function_type.
Fix head comment and swap couple of conditional blocks.


-- 
Eric Botcazou
Index: gcc-interface/trans.c
===
--- gcc-interface/trans.c	(revision 173209)
+++ gcc-interface/trans.c	(working copy)
@@ -214,7 +214,7 @@ static void set_expr_location_from_node
 static bool set_end_locus_from_node (tree, Node_Id);
 static void set_gnu_expr_location_from_node (tree, Node_Id);
 static int lvalue_required_p (Node_Id, tree, bool, bool, bool);
-static tree build_raise_check (int, tree, enum exception_info_kind);
+static tree build_raise_check (int, enum exception_info_kind);
 
 /* Hooks for debug info back-ends, only supported and used in a restricted set
of configurations.  */
@@ -236,7 +236,7 @@ gigi (Node_Id gnat_root, int max_gnat_no
   Entity_Id standard_exception_type, Int gigi_operating_mode)
 {
   Entity_Id gnat_literal;
-  tree long_long_float_type, exception_type, t;
+  tree long_long_float_type, exception_type, t, ftype;
   tree int64_type = gnat_type_for_size (64, 0);
   struct elab_info *info;
   int i;
@@ -344,39 +344,34 @@ gigi (Node_Id gnat_root, int max_gnat_no
   DECL_IGNORED_P (t) = 1;
   save_gnu_tree (gnat_literal, t, false);
 
-  void_ftype = build_function_type (void_type_node, NULL_TREE);
+  void_ftype = build_function_type_list (void_type_node, NULL_TREE);
   ptr_void_ftype = build_pointer_type (void_ftype);
 
   /* Now declare run-time functions.  */
-  t = tree_cons (NULL_TREE, void_type_node, NULL_TREE);
+  ftype = build_function_type_list (ptr_void_type_node, sizetype, NULL_TREE);
 
   /* malloc is a function declaration tree for a function to allocate
  memory.  */
   malloc_decl
 = create_subprog_decl (get_identifier ("__gnat_malloc"), NULL_TREE,
-			   build_function_type (ptr_void_type_node,
-		tree_cons (NULL_TREE,
-			   sizetype, t)),
-			   NULL_TREE, false, true, true, true, NULL, Empty);
+			   ftype, NULL_TREE, false, true, true, true, NULL,
+			   Empty);
   DECL_IS_MALLOC (malloc_decl) = 1;
 
   /* malloc32 is a function declaration tree for a function to allocate
  32-bit memory on a 64-bit system.  Needed only on 64-bit VMS.  */
   malloc32_decl
 = create_subprog_decl (get_identifier ("__gnat_malloc32"), NULL_TREE,
-			   build_function_type (ptr_void_type_node,
-		tree_cons (NULL_TREE,
-			   sizetype, t)),
-			   NULL_TREE, false, true, true, true, NULL, Empty);
+			   ftype, NULL_TREE, false, true, true, true, NULL,
+			   Empty);
   DECL_IS_MALLOC (malloc32_decl) = 1;
 
   /* free is a function declaration tree for a function to free memory.  */
   free_decl
 = create_subprog_decl (get_identifier ("__gnat_free"), NULL_TREE,
-			   build_function_type (void_type_node,
-		tree_cons (NULL_TREE,
-			   ptr_void_type_node,
-			   t)),
+			   build_function_type_list (void_type_node,
+		 ptr_void_type_node,
+		 NULL_TREE),
 			   NULL_TREE, false, true, true, true, NULL, Empty);
 
   /* This is used for 64-bit multiplication with overflow checking.  */
@@ -403,18 +398,17 @@ gigi (Node_Id gnat_root, int max_gnat_no
   /* Functions to get and set the jumpbuf pointer for the current thread.  */
   get_jmpbuf_decl
 = create_subprog_decl
-(get_identifier ("system__soft_links__get_jmpbuf_address_soft"),
- NULL_TREE, build_function_type (jmpbuf_ptr_type, NULL_TREE),
- NULL_TREE, false, true, true, true, NULL, Empty);
+  (get_identifier ("system__soft_links__get_jmpbuf_address_soft"),
+   NULL_TREE, build_function_type_list (jmpbuf_ptr_type, NULL_TREE),
+   NULL_TREE, false, true, true, true, NULL, Empty);
   DECL_IGNORED_P (get_jmpbuf_decl) = 1;
 
   set_jmpbuf_decl
 = create_subprog_decl
-(get_identifier ("system__soft_links__set_jmpbuf_address_soft"),
- NULL_TREE,
- build_function_type (void_type_node,
-			  tree_cons (NULL_TREE, jmpbuf_ptr_type, t)),
- NULL_TREE, false, true, true, true, NULL, Empty);
+  (get_identifier ("system__soft_links__set_jmpbuf_address_soft"),
+   NULL_TREE, build_function_type_list (void_type_node, jmpbuf_ptr_type,
+	NULL_TREE),
+   NULL_TREE, false, true, true, true, NULL, Empty);
   DECL_IGNORED_P (set_jmp

Re: Improve DSE in the presence of calls

[Easwaran Raman]

On Mon, May 2, 2011 at 8:37 PM, Jeff Law  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 04/26/11 16:06, Easwaran Raman wrote:
>
>>
>>> You're right. The patch has correctness issues. It is not possible to
>>> simply not call add_wild_read because it also resets
>>> active_local_stores and frees read_recs. During the local phase it
>>> seems better to just treat calls as wild reads and reset
>>> active_local_stores and free read_recs. I've now refactored
>>> add_wild_read so that resetting active_local_stores and free read_recs
>>> are in separate methods that can be called on non-const/non-memset
>>> calls. In addition, I have added a non_frame_wild_read field in
>>> insn_info to mark non-const and non-memset calls.
>>
>>> I've attached the revised patch.
> Looking better.  Just a few more things.
>
> Don't all locals escape if the callee has a static chain?  Is that
> handled anywhere?
>
> Don't you still have the potential for wild reads in dse_step5_nospill
> (say from an asm)?  if so, then the change can't be correct.
>
> Couldn't you just add a clause like this before the else-if?
>
> else if (insn_info->non_frame_wild_read)
>  {
>    if (dump_file)
>      fprintf (dump_file, "non-frame wild read\n");
>    scan_reads_nospill (insn_info, v, NULL);
>  }
> else if (insn_info->read_rec)
>  {
>    /* Leave this clause unchanged */
>  }
>
> Am I missing something?

I am not sure I understand the problem here.  If there is a wild read
from asm, the instruction has the wild_read flag set. The if statement
checks if that flag is set and if so it clears the bitmap - which was
the original behavior. Originally, only if read_rec is non NULL you
need to recompute the kill set. Now, even if read_rec is NULL,
non_frame_wild_read could be set requiring the kill set to be
modified, which is what this patch does.  In fact, isn't what you have
written above the equivalent to what is in the patch as '/* Leave this
clause unchanged */' is the same as

  if (dump_file)
fprintf (dump_file, "regular read\n");
  scan_reads_nospill (insn_info, v, NULL);


-Easwaran

> What's the purpose behind using unit64_t in the testcase?  Somehow I
> suspect using int64_t means the test is unlikely not going to work
> across targets with different word sizes.
>
> Jeff
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJNv3iGAAoJEBRtltQi2kC7C8oH+gPi/6DvV2JkmitT3xEeUaW8
> szOHC0GysQkot/TiVlQQy6fiz61G49ii0mz68W4cfSntvuN7iaqBqVWpRKWIzvkx
> alk4U1snj9a2t9+9ZRTX4xm3quggTv+mUDK81a+DIS2zAf6i/HRXLvQbx6fhDOYD
> sqXqSkvCKqkH2pPHHYEqnBtS/cLFtAfZJe+JSx3u2oqL+sBFGLftdoV6yJzkShLS
> LpmYHMeDbzhdCtZTf15GQm3h/cBlyrChxjQsjJxLiXk5rrcDI/X+Pqi+cll21Gwg
> mlzMBi0iYToENl+7aO8DNGvXfliCEzQ7iEUyTctJiTDt3/RgVcaxgRJgqHZNSBI=
> =VOdm
> -END PGP SIGNATURE-
>

Re: [google]: initialize language field for clone function struct

[Jan Hubicka]

> In fold-const.c, there are many of calls to
> lang_hooks.decls.global_bindings_p, and the implementation of this in
> name-lookup.h will look at the the cfun->language
> 
> 
> #define cp_function_chain (cfun->language)
> 
> #define current_binding_level \
>   (*(cfun && cp_function_chain && cp_function_chain->bindings \
>? &cp_function_chain->bindings \
> 
> int
> global_bindings_p (void)
> {
>   return global_scope_p (current_binding_level);
> }
> 
> 
> In gcc 4.4.3, current_binding_level is defined in a way that
> cp_function_chain->bindings is not guarded, resulting in segfault for
> clones. In trunk, this is guarded -- but not setting language field
> for clone probably just hide the problem.

Indeed, it seems to me that global_bindings_p should go, clearly the LTO does
not preserve its behaviour in any sane way.
I am however completely missing the point of this langhook and doc is not 
exactly
informative either:

  /* Returns nonzero if we are in the global binding level.  Ada
 returns -1 for an undocumented reason used in stor-layout.c.  */

What is the purpose of this hook?

Honza

Re: [google] Patch to support calling multi-versioned functions via new GCC builtin. (issue4440078)

[Mike Stump]

On May 3, 2011, at 8:34 AM, "Joseph S. Myers"  wrote:.
> I don't think the forms in which some of the machine-specific built-in 
> functions exist are particularly good for being available everywhere

I take it you've never just wanted something to compile, and hit one of these 
yet.  Let me know if you change your opinion after you do.  I have.  For anyone 
that wants it to just compile, trust me, they just want it to compile.

Re: Move cgraph_node_set and varpool_node_set out of GGC and make them use pointer_map

[Jan Hubicka]

> 
> We have both a vector and a pointer-map.  Why not simply use a
> pointer-map only?!  I see this may need more re-structuring, eventually

Well, pointer-maps would be randomly ordered (sensitive to pointer values)
and thus we would give different .o files depending on memory layout.
But yes, combination of hashtable and array is bit funny. I was considering
using simple bitmaps but given that the sets might be large and we do
quite many queries, I concluded that it might lead to problems with O(n)
lookup times in our bitmap structure.

The problem of frequent lookups is actually problem with fact that
ipa-reference output routines are quadratic in computing the boundary.
Something I will fix later, too.

Still replacing htab here seems like obvious improvement. pointer-map looks
even prettier and it should be good enough for any future use we can come up in
WHOPR.  Unlike the type merging and streamer cache, those sets are relatively
small.

> adding an iterator interface to pointer-sets/maps (which would be
> nice anyway).
> 
> It also makes me think again that why do we have both a cgraph
> and a varpool set ... at least when you now deal with a non-GC
> data structure you could as well use a vector of void * and
> provide macros doing the casting for you, unifying the implementation
> itself.

I would deffer this to symtab patches that will unify both sets into single
structure.
> 
> Well, I suppose most of that can be done as a followup (when
> eventually the symtab arrives and varpool and cgraph nodes merge anyway).
> 
> Thus, ok for now.

Thanks!
Honza
> 
> Thanks,
> Richard.

[PATCH, trivial]: Remove write only variable from expmed.c

[Uros Bizjak]

Hello!

2011-05-03  Uros Bizjak  

* expmed.c (extract_bit_field_1): Remove write-only variable "icode".

Bootstrapped and regression tested on x86_64-pc-linux-gnu AVX target.
Committed to mainline SVN.

Uros.
Index: expmed.c
===
--- expmed.c(revision 173309)
+++ expmed.c(working copy)
@@ -1127,7 +1127,6 @@ extract_bit_field_1 (rtx str_rtx, unsign
   enum machine_mode int_mode;
   enum machine_mode ext_mode;
   enum machine_mode mode1;
-  enum insn_code icode;
   int byte_offset;
 
   if (tmode == VOIDmode)
@@ -1431,7 +1430,6 @@ extract_bit_field_1 (rtx str_rtx, unsign
 
   /* Now OFFSET is nonzero only for memory operands.  */
   ext_mode = mode_for_extraction (unsignedp ? EP_extzv : EP_extv, 0);
-  icode = unsignedp ? CODE_FOR_extzv : CODE_FOR_extv;
   if (ext_mode != MAX_MACHINE_MODE
   && bitsize > 0
   && GET_MODE_BITSIZE (ext_mode) >= bitsize

Some backports from mainline to gcc 4.5 branch

[Jakub Jelinek]

Hi!

I've backported 5 patches from the trunk to 4.5 branch after
bootstrapping/regtesting them on x86_64-linux and i686-linux.

Jakub
2011-05-03  Uros Bizjak  
Jakub Jelinek  

PR target/48774
* config/i386/i386.c (ix86_match_ccmode): For CC{A,C,O,S}mode
only succeed if req_mode is the same as set_mode.

* gcc.dg/pr48774.c: New test.

--- gcc/config/i386/i386.c  (revision 173300)
+++ gcc/config/i386/i386.c  (revision 173301)
@@ -17299,11 +17299,15 @@ ix86_match_ccmode (rtx insn, enum machin
   if (req_mode == CCZmode)
return 0;
   /* FALLTHRU */
+case CCZmode:
+  break;
+
 case CCAmode:
 case CCCmode:
 case CCOmode:
 case CCSmode:
-case CCZmode:
+  if (set_mode != req_mode)
+   return 0;
   break;
 
 default:
--- gcc/testsuite/gcc.dg/pr48774.c  (revision 0)
+++ gcc/testsuite/gcc.dg/pr48774.c  (revision 173301)
@@ -0,0 +1,38 @@
+/* PR target/48774 */
+/* { dg-do run } */
+/* { dg-options "-O2 -funroll-loops" } */
+
+extern void abort (void);
+unsigned long int s[24]
+  = { 12, ~1, 12, ~2, 12, ~4, 12, ~8, 12, ~16, 12, ~32,
+  12, ~64, 12, ~128, 12, ~256, 12, ~512, 12, ~1024, 12, ~2048 };
+struct { int n; unsigned long *e[12]; } g
+  = { 12, { &s[0], &s[2], &s[4], &s[6], &s[8], &s[10], &s[12], &s[14],
+   &s[16], &s[18], &s[20], &s[22] } };
+int c[12];
+
+__attribute__((noinline, noclone)) void
+foo (void)
+{
+  int i, j;
+  for (i = 0; i < g.n; i++)
+for (j = 0; j < g.n; j++)
+  {
+   if (i == j && j < g.e[0][0] && (g.e[i][1] & (1UL << j)))
+ abort ();
+   if (j < g.e[0][0] && (g.e[i][1] & (1UL << j)))
+ c[i]++;
+  }
+}
+
+int
+main ()
+{
+  int i;
+  asm volatile ("" : "+m" (s), "+m" (g), "+m" (c));
+  foo ();
+  for (i = 0; i < 12; i++)
+if (c[i] != 11)
+  abort ();
+  return 0;
+}
2011-05-03  Jakub Jelinek  

Backport from mainline
2011-04-30  Jakub Jelinek  

PR tree-optimization/48809
* tree-switch-conversion.c (build_arrays): Compute tidx in unsigned
type.
(gen_inbound_check): Don't compute index_expr - range_min in utype
again, instead reuse SSA_NAME initialized in build_arrays.
Remove two useless gsi_for_stmt calls.

* gcc.c-torture/execute/pr48809.c: New test.

--- gcc/tree-switch-conversion.c(revision 173206)
+++ gcc/tree-switch-conversion.c(revision 173207)
@@ -656,7 +656,7 @@ static void
 build_arrays (gimple swtch)
 {
   tree arr_index_type;
-  tree tidx, sub, tmp;
+  tree tidx, sub, tmp, utype;
   gimple stmt;
   gimple_stmt_iterator gsi;
   int i;
@@ -664,14 +664,20 @@ build_arrays (gimple swtch)
 
   gsi = gsi_for_stmt (swtch);
 
+  /* Make sure we do not generate arithmetics in a subrange.  */
+  utype = TREE_TYPE (info.index_expr);
+  if (TREE_TYPE (utype))
+utype = lang_hooks.types.type_for_mode (TYPE_MODE (TREE_TYPE (utype)), 1);
+  else
+utype = lang_hooks.types.type_for_mode (TYPE_MODE (utype), 1);
+
   arr_index_type = build_index_type (info.range_size);
-  tmp = create_tmp_var (TREE_TYPE (info.index_expr), "csti");
+  tmp = create_tmp_var (utype, "csui");
   add_referenced_var (tmp);
   tidx = make_ssa_name (tmp, NULL);
-  sub = fold_build2_loc (loc, MINUS_EXPR,
-TREE_TYPE (info.index_expr), info.index_expr,
-fold_convert_loc (loc, TREE_TYPE (info.index_expr),
-  info.range_min));
+  sub = fold_build2_loc (loc, MINUS_EXPR, utype,
+fold_convert_loc (loc, utype, info.index_expr),
+fold_convert_loc (loc, utype, info.range_min));
   sub = force_gimple_operand_gsi (&gsi, sub,
  false, NULL, true, GSI_SAME_STMT);
   stmt = gimple_build_assign (tidx, sub);
@@ -780,12 +786,7 @@ gen_inbound_check (gimple swtch)
   tree label_decl2 = create_artificial_label (UNKNOWN_LOCATION);
   tree label_decl3 = create_artificial_label (UNKNOWN_LOCATION);
   gimple label1, label2, label3;
-
-  tree utype;
-  tree tmp_u_1, tmp_u_2, tmp_u_var;
-  tree cast;
-  gimple cast_assign, minus_assign;
-  tree ulb, minus;
+  tree utype, tidx;
   tree bound;
 
   gimple cond_stmt;
@@ -799,49 +800,24 @@ gen_inbound_check (gimple swtch)
   gcc_assert (info.default_values);
   bb0 = gimple_bb (swtch);
 
-  /* Make sure we do not generate arithmetics in a subrange.  */
-  if (TREE_TYPE (TREE_TYPE (info.index_expr)))
-utype = lang_hooks.types.type_for_mode
-  (TYPE_MODE (TREE_TYPE (TREE_TYPE (info.index_expr))), 1);
-  else
-utype = lang_hooks.types.type_for_mode
-  (TYPE_MODE (TREE_TYPE (info.index_expr)), 1);
+  tidx = gimple_assign_lhs (info.arr_ref_first);
+  utype = TREE_TYPE (tidx);
 
   /* (end of) block 0 */
   gsi = gsi_for_stmt (info.arr_ref_first);
-  tmp_u_var = create_tmp_var (utype, "csui");
-  add_referenced_var (tmp_u_var);
-  tmp_u_1 = make_ssa_name (tmp_u_var, NU

Re: C++ PATCHes relating to c++/48834, c++/40975 (array new)

[Jason Merrill]

On 05/03/2011 11:52 AM, Eric Botcazou wrote:

In that case you wouldn't be affected by this patch; unshare_body uses
mostly_copy_tree_r, which has its own special case for STATEMENT_LIST.


Right, I added it precisely to support statement expressions in Ada (instead
of changing copy_tree_r) since we never want to copy them in the unsharing
phase.  That's why I find the change to copy_tree_r questionable.


Well, let's look at the users of copy_tree_r.

cp/tree.c (bot_manip): The case I want to fix.

gimplify.c (mostly_copy_tree_r): Handles STATEMENT_LIST itself.

stor-layout.c (copy_self_referential_tree_r): Affected by the change. 
Would you like me to add a gcc_unreachable() here?


tree-inline.c (copy_tree_body_r): already copies STATEMENT_LIST itself 
(with a copy_statement_list function which I should use instead of 
open-coding it again).

(copy_bind_expr): subroutine of copy_tree_body_r.
(unsave_r, remap_gimple_op_r): Handle STATEMENT_LIST themselves.

So, looks like one place that could have an undesired change in 
behavior.  I'll go ahead and add that assert.


Jason

Re: [debug] PR42288 emit empty .debug_aranges section

[Jason Merrill]

OK.

Jason

Re: mips_handle_option global state avoidance, part 1

[Richard Sandiford]

"Joseph S. Myers"  writes:
>   * config/mips/mips-opts.h: New.
>   * config/mips/mips.c (enum mips_r10k_cache_barrier_setting): Move
>   to mips-opts.h.
>   (mips_abi, mips_code_readable, mips_r10k_cache_barriee): Remove.
>   (mips_handle_option): Don't handle OPT_mabi_, OPT_mcode_readable_
>   or OPT_mr10k_cache_barrier_ here.  Access mips_cache_flush_func
>   via opts pointer.
>   * config/mips/mips.h (enum mips_code_readable_setting): Move to
>   mips-opts.h.
>   (mips_abi, mips_code_readable): Don't declare.
>   * config/mips/mips.opt (config/mips/mips-opts.h): New
>   HeaderInclude.
>   (mabi=): Use Enum and Var.
>   (mips_abi): New Enum and EnumValue entries.
>   (mcode-readable=): Use Enum and Var.
>   (mips_code_readable_setting): New Enum and EnumValue entries.
>   (mr10k-cache-barrier=): Use Enum and Var.
>   (mips_r10k_cache_barrier_setting): New Enum and EnumValue entries.

OK, thanks.

Richard

Re: [PATCH, PR43920, 1/9] ARM specific part.

[Rainer Orth]

Tom,

>>> That also sounds reasonable.  Is nm -S more portable than size?
>> 
>> Neither Solaris nor IRIX nm have it.  size isn't particularly portable,
>> either: there are many variations in output format.
[...]
> In case we ever need it, here's a patch to access nm -S.

sorry for the very late response, but a couple of comments.

> +# Call pass if symbol size is ok, otherwise fail.
> +# example: /* { dg-final { object-symbol-size main <= 54 } } */
> +proc object-symbol-size { args } {

This needs to be documented in doc/sourcebuild.texi (Final Actions).  We
made a concerted effort to document the testsuite and should keep it
that way.

> +# Find nm like we find g++ in g++.exp.
> +if ![info exists nm]  {
> + set nm [findfile $base_dir/../../../binutils/nm \
> + $base_dir/../../../binutils/nm \
> + [findfile $base_dir/../../nm $base_dir/../../nm \
> +  [findfile $base_dir/nm $base_dir/nm \
> +   [transform nm
> + verbose -log "nm is $nm"
> +}

Please move this to a separate proc like gnat.exp (find_gnatclean).

> +upvar 2 name testcase
> +set testcase [lindex $testcase 0]
> +set output_file "[file rootname [file tail $testcase]].o"
> +set output [remote_exec host "$nm" "-S $output_file"]
> +set status [lindex $output 0]
> +if { $status != 0 } {
> +error "object-symbol-size: $nm failed"
> +return
> +}

As I said, nm -S is completely unportable.  I'd rather at least try if
we can cope with the differences in size output format instead, or
use a hook here that allows to use different implementations.

Thanks for doing this.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

RFA Re: C++ PATCHes relating to c++/48834, c++/40975 (array new)

[Jason Merrill]

On 05/03/2011 01:28 PM, Jason Merrill wrote:

stor-layout.c (copy_self_referential_tree_r): Affected by the change.
Would you like me to add a gcc_unreachable() here?

tree-inline.c (copy_tree_body_r): already copies STATEMENT_LIST itself
(with a copy_statement_list function which I should use instead of
open-coding it again).


Thus.  Tested x86_64-pc-linux-gnu with c,ada,c++,fortran,java,lto,objc. 
OK?  I also removed the recursion from copy_statement_list because it 
would just extra garbage STATEMENT_LISTs since they're already copied by 
the normal walk_tree.


Jason
commit 85aad99f6848bfaebbe5c794bf0a95c80e0f49cd
Author: Jason Merrill 
Date:   Tue May 3 13:19:10 2011 -0400

PR c++/40975
* tree-inline.c (copy_tree_r): Use copy_statement_list.
(copy_statement_list): Don't recurse.
* stor-layout.c (copy_self_referential_tree_r): Don't allow
STATEMENT_LIST.

diff --git a/gcc/stor-layout.c b/gcc/stor-layout.c
index ea0d44d..ecd1450 100644
--- a/gcc/stor-layout.c
+++ b/gcc/stor-layout.c
@@ -245,6 +245,8 @@ copy_self_referential_tree_r (tree *tp, int *walk_subtrees, 
void *data)
  cannot always guarantee in practice.  So punt in this case.  */
   else if (code == SAVE_EXPR)
 return error_mark_node;
+  else if (code == STATEMENT_LIST)
+gcc_unreachable ();
 
   return copy_tree_r (tp, walk_subtrees, data);
 }
diff --git a/gcc/tree-inline.c b/gcc/tree-inline.c
index 3777675..ea7b7ab 100644
--- a/gcc/tree-inline.c
+++ b/gcc/tree-inline.c
@@ -662,8 +662,6 @@ copy_statement_list (tree *tp)
   for (; !tsi_end_p (oi); tsi_next (&oi))
 {
   tree stmt = tsi_stmt (oi);
-  if (TREE_CODE (stmt) == STATEMENT_LIST)
-   copy_statement_list (&stmt);
   tsi_link_after (&ni, stmt, TSI_CONTINUE_LINKING);
 }
 }
@@ -4272,19 +4270,9 @@ copy_tree_r (tree *tp, int *walk_subtrees, void *data 
ATTRIBUTE_UNUSED)
   *tp = new_tree;
 }
   else if (code == STATEMENT_LIST)
-{
-  /* We used to just abort on STATEMENT_LIST, but we can run into them
- with statement-expressions (c++/40975).  */
-  tree new_list = alloc_stmt_list ();
-  tree_stmt_iterator i = tsi_start (*tp);
-  tree_stmt_iterator j = tsi_last (new_list);
-  for (; !tsi_end_p (i); tsi_next (&i))
-   {
- tree stmt = tsi_stmt (i);
- tsi_link_after (&j, stmt, TSI_CONTINUE_LINKING);
-   }
-  *tp = new_list;
-}
+/* We used to just abort on STATEMENT_LIST, but we can run into them
+   with statement-expressions (c++/40975).  */
+copy_statement_list (tp);
   else if (TREE_CODE_CLASS (code) == tcc_type)
 *walk_subtrees = 0;
   else if (TREE_CODE_CLASS (code) == tcc_declaration)

[C++ Patch, committed] PR 28501

[Paolo Carlini]

Hi,

tested x86_64-linux, approved by Jason on the audit trail, committed to 
mainline.


Thanks!
Paolo.

///
/cp
2011-05-03  Paolo Carlini  

PR c++/28501
* call.c (add_builtin_candidate): Handle REALPART_EXPR and
IMAGPART_EXPR.

/testsuite
2011-05-03  Paolo Carlini  

PR c++/28501
* g++.dg/ext/complex9.C: New.
Index: testsuite/g++.dg/ext/complex9.C
===
--- testsuite/g++.dg/ext/complex9.C (revision 0)
+++ testsuite/g++.dg/ext/complex9.C (revision 0)
@@ -0,0 +1,8 @@
+// PR c++/28501
+
+struct A
+{
+  operator int();
+};
+
+int i = __real__ A();
Index: cp/call.c
===
--- cp/call.c   (revision 173336)
+++ cp/call.c   (working copy)
@@ -1,6 +1,7 @@
 /* Functions related to invoking methods and overloaded functions.
Copyright (C) 1987, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
-   1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010
+   1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009,
+   2010, 2011
Free Software Foundation, Inc.
Contributed by Michael Tiemann (tiem...@cygnus.com) and
modified by Brendan Kehoe (bren...@cygnus.com).
@@ -2586,6 +2587,12 @@ add_builtin_candidate (struct z_candidate **candid
 types are TYPE2.  */
   break;
 
+case REALPART_EXPR:
+case IMAGPART_EXPR:
+  if (ARITHMETIC_TYPE_P (type1))
+   break;
+  return;
+ 
 default:
   gcc_unreachable ();
 }

Re: [google] Add -fstrict-enum-precision flag (issue4433083)

[Jason Merrill]

On 04/28/2011 03:50 PM, Diego Novillo wrote:

This patch from Silvius Rus adds a new flag (-fstrict-enum-precision).
While porting the patch to 4.6, I noticed that the C++ FE now has a
similar flag that seems to have similar semantics (-fstrict-enums).

Silvius's patch is used to disable some switch() optimizations that
assume enum types can *only* take values within that enum (Silvius,
please correct me if I got this wrong).

Jason, your -fstrict-enums only applies to the C++ front end.
Silvius's variant affects VRP and gimplification of switches.  Would
it be better if we simply moved -fstrict-enums to common options and
used that to decide whether to optimize switches in VRP and the
gimplifier?

We use it internally to disable this optimization for code that
generates values outside of enum ranges.


It seems that to me that this patch changes optimizations to not believe 
the lies of the C++ front end, whereas my patch changes the front end to 
not lie in the first place, making this patch unnecessary.


Jason

Re: [google]: initialize language field for clone function struct

[Eric Botcazou]

> I am however completely missing the point of this langhook and doc is not
> exactly informative either:
>
>   /* Returns nonzero if we are in the global binding level.  Ada
>  returns -1 for an undocumented reason used in stor-layout.c.  */
>
> What is the purpose of this hook?

I've seen things far more undocumented in GCC than this one ;-)


tree
variable_size (tree size)
{

[...]

  /* If the language-processor is to take responsibility for variable-sized
 items (e.g., languages which have elaboration procedures like Ada),
 just return SIZE unchanged.  */
  if (lang_hooks.decls.global_bindings_p () < 0)
return size;

[...]

  if (lang_hooks.decls.global_bindings_p ())
{
  if (TREE_CONSTANT (size))
error ("type size can%'t be explicitly evaluated");
  else
error ("variable-size type declared outside of any function");

  return size_one_node;
}

[...]

}


In Ada there are variable-sized types at global level so it isn't an error to 
call variable_size when lang_hooks.decls.global_bindings_p returns non-zero.

-- 
Eric Botcazou

Re: [SPARC] Hookize PRINT_OPERAND, PRINT_OPERAND_ADDRESS and PRINT_OPERAND_PUNCT_VALID_P

[Rainer Orth]

Richard Henderson  writes:

> On 04/27/2011 11:13 AM, Anatoly Sokolov wrote:
>> * config/sparc/sparc.h (PRINT_OPERAND, PRINT_OPERAND_ADDRESS,
>> PRINT_OPERAND_PUNCT_VALID_P): Remove.
>> * config/sparc/sparc-protos.h (print_operand): Remove declaration.
>> * config/sparc/sparc.c (TARGET_PRINT_OPERAND_PUNCT_VALID_P,
>> TARGET_PRINT_OPERAND, TARGET_PRINT_OPERAND_ADDRESS): Define.
>> (print_operand): Rename to...
>> (sparc_print_operand): ...this. Make static. Adjust
>> sparc_print_operand function call.
>> (sparc_print_operand_punct_valid_p, sparc_print_operand_address): New
>> functions.
>
> Ok, except, 
>
>> +  if(code == '#'
>
> Space before (, re-indenting the rest of the condition to match.

This patch broke Solaris 2/SPARC bootstrap which still uses
print_operand in sparc/sol2.h (ASM_OUTPUT_CALL).  A bootstrap with the
obvious fix is currently running.

What is so hard about running grep when removing/renaming symbols???

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [google]: initialize language field for clone function struct

[Joseph S. Myers]

On Tue, 3 May 2011, Eric Botcazou wrote:

> > I am however completely missing the point of this langhook and doc is not
> > exactly informative either:
> >
> >   /* Returns nonzero if we are in the global binding level.  Ada
> >  returns -1 for an undocumented reason used in stor-layout.c.  */
> >
> > What is the purpose of this hook?
> 
> I've seen things far more undocumented in GCC than this one ;-)
> 
> 
> tree
> variable_size (tree size)
> {
> 
> [...]
> 
>   /* If the language-processor is to take responsibility for variable-sized
>  items (e.g., languages which have elaboration procedures like Ada),
>  just return SIZE unchanged.  */
>   if (lang_hooks.decls.global_bindings_p () < 0)
> return size;

In my view we should require front ends to take responsibility for 
variable-size types, and get rid of this language-independent function 
(copying such parts as are needed into the front ends that need them).  C 
for example uses its own version as the language-independent one isn't 
right for C.  Similarly, the pending_size code should be local to front 
ends.

-- 
Joseph S. Myers
jos...@codesourcery.com

[PATCH] less build_function_type usage in the Fortran FE

[Nathan Froyd]

The patch below eliminates almost all cases of build_function_type in
the Fortran FE.  (The last case uses TYPE_ARG_TYPES directly and will
need to be dealt with separately.)  This is accomplished by introducing
two new functions, build_{,varargs_}function_type_array, which do what
you think, and two small macro wrappers around them,
build_{,varargs_}function_type_vec.  The macro wrappers are used so that
one can use heap-, gc-, or stack-allocated vectors, as necessary.

Comments on the middle-end bits welcome; some sort of FUNCTION_TYPE
builder with a dynamically determined number of argument types is needed
for working towards the elimination of TYPE_ARG_TYPES.

As a happy side-effect, the patch eliminates uses of gfc_chainon_list
and makes the specific instances below of building function types
linear, instead of quadratic.  If the patch is approved, I will delete
gfc_chainon_list as an obvious followon patch.

Testing in progress on x86_64-unknown-linux-gnu.  OK to commit if
testing successful?

-Nathan

gcc/
* tree.h (build_function_type_array): Declare.
(build_varargs_function_type_array): Declare.
(build_function_type_vec, build_varargs_function_type_vec): Define.
* tree.c (build_function_type_array_1): New function.
(build_function_type_array): New function.
(build_varargs_function_type_array): New function.

gcc/fortran/
* trans-decl.c (build_library_function_decl_1): Call
build_function_type_vec.  Adjust argument list building accordingly.
* trans-intrinsic.c (gfc_get_intrinsic_lib_fndecl): Likewise.
* trans-types.c (gfc_get_function_type): Likewise.

diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index f80c9db..dc381f9 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -2478,8 +2478,7 @@ static tree
 build_library_function_decl_1 (tree name, const char *spec,
   tree rettype, int nargs, va_list p)
 {
-  tree arglist;
-  tree argtype;
+  VEC(tree,gc) *arglist;
   tree fntype;
   tree fndecl;
   int n;
@@ -2488,20 +2487,18 @@ build_library_function_decl_1 (tree name, const char 
*spec,
   gcc_assert (current_function_decl == NULL_TREE);
 
   /* Create a list of the argument types.  */
-  for (arglist = NULL_TREE, n = abs (nargs); n > 0; n--)
+  arglist = VEC_alloc (tree, gc, abs (nargs));
+  for (n = abs (nargs); n > 0; n--)
 {
-  argtype = va_arg (p, tree);
-  arglist = gfc_chainon_list (arglist, argtype);
-}
-
-  if (nargs >= 0)
-{
-  /* Terminate the list.  */
-  arglist = chainon (arglist, void_list_node);
+  tree argtype = va_arg (p, tree);
+  VEC_quick_push (tree, arglist, argtype);
 }
 
   /* Build the function type and decl.  */
-  fntype = build_function_type (rettype, arglist);
+  if (nargs >= 0)
+fntype = build_function_type_vec (rettype, arglist);
+  else
+fntype = build_varargs_function_type_vec (rettype, arglist);
   if (spec)
 {
   tree attr_args = build_tree_list (NULL_TREE,
diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index 180aba1..360723c 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -722,7 +722,7 @@ static tree
 gfc_get_intrinsic_lib_fndecl (gfc_intrinsic_map_t * m, gfc_expr * expr)
 {
   tree type;
-  tree argtypes;
+  VEC(tree,gc) *argtypes;
   tree fndecl;
   gfc_actual_arglist *actual;
   tree *pdecl;
@@ -803,14 +803,13 @@ gfc_get_intrinsic_lib_fndecl (gfc_intrinsic_map_t * m, 
gfc_expr * expr)
ts->kind);
 }
 
-  argtypes = NULL_TREE;
+  argtypes = NULL;
   for (actual = expr->value.function.actual; actual; actual = actual->next)
 {
   type = gfc_typenode_for_spec (&actual->expr->ts);
-  argtypes = gfc_chainon_list (argtypes, type);
+  VEC_safe_push (tree, gc, argtypes, type);
 }
-  argtypes = chainon (argtypes, void_list_node);
-  type = build_function_type (gfc_typenode_for_spec (ts), argtypes);
+  type = build_function_type_vec (gfc_typenode_for_spec (ts), argtypes);
   fndecl = build_decl (input_location,
   FUNCTION_DECL, get_identifier (name), type);
 
diff --git a/gcc/fortran/trans-types.c b/gcc/fortran/trans-types.c
index ebc8c23..4606f68 100644
--- a/gcc/fortran/trans-types.c
+++ b/gcc/fortran/trans-types.c
@@ -2534,10 +2534,11 @@ tree
 gfc_get_function_type (gfc_symbol * sym)
 {
   tree type;
-  tree typelist;
+  VEC(tree,gc) *typelist;
   gfc_formal_arglist *f;
   gfc_symbol *arg;
   int alternate_return;
+  bool is_varargs = true;
 
   /* Make sure this symbol is a function, a subroutine or the main
  program.  */
@@ -2548,13 +2549,11 @@ gfc_get_function_type (gfc_symbol * sym)
 return TREE_TYPE (sym->backend_decl);
 
   alternate_return = 0;
-  typelist = NULL_TREE;
+  typelist = NULL;
 
   if (sym->attr.entry_master)
-{
-  /* Additional parameter for selecting an entry point.  */
-  typelist = gfc_chainon_list (typeli

Re: [google]: initialize language field for clone function struct

[Nathan Froyd]

On Tue, May 03, 2011 at 07:06:58PM +, Joseph S. Myers wrote:
> In my view we should require front ends to take responsibility for 
> variable-size types, and get rid of this language-independent function 
> (copying such parts as are needed into the front ends that need them).  C 
> for example uses its own version as the language-independent one isn't 
> right for C.  Similarly, the pending_size code should be local to front 
> ends.

The raft of changes/improvements enabled by this change would be most
welcome.  *_SIZE becoming double_ints or HOST_WIDE_INT instead of trees
is the first thing that comes to mind; perhaps there are others.

-Nathan

Re: [SPARC] Hookize PRINT_OPERAND, PRINT_OPERAND_ADDRESS and PRINT_OPERAND_PUNCT_VALID_P

[Joseph S. Myers]

On Tue, 3 May 2011, Rainer Orth wrote:

> This patch broke Solaris 2/SPARC bootstrap which still uses
> print_operand in sparc/sol2.h (ASM_OUTPUT_CALL).  A bootstrap with the
> obvious fix is currently running.
> 
> What is so hard about running grep when removing/renaming symbols???

Generically, the presence of lots of nonobvious places that may turn out 
to use a symbol - ada/gcc-interface/, go/gofrontend, config/ for what one 
thinks of as front-end symbols, libgcc/ and other places outside of gcc/ 
(being outside gcc/ is probably how the remaining use of ROUND_TYPE_SIZE 
in libobjc was missed when that macro was removed from GCC in 2003), C 
symbols used directly in Ada source code,   The ongoing work on 
narrowing interfaces (so that it's well-defined whether particular headers 
are used for the host or the target, tm.h isn't included in so many 
places, etc.) may help - though another thing to watch out for there is 
random declarations in .c files or inappropriate headers that mean that 
something uses a symbol from some part of the compiler despite not 
including the normal header that declares it (I found plenty of such cases 
when making options variables into macros).  Help in cleaning up 
interfaces is always welcome - there's a lot to do 
( has notes dealing 
with the very narrow area of target macros in code built for the target).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: RFA: MN10300: Add support for SETLB and Lcc instructions

[Richard Henderson]

On 05/03/2011 05:13 AM, Nick Clifton wrote:
> The problem I found here was that I did not know how to find all of
> the test-and-loop-back insns if the loop spanned multiple blocks.
> The revised patch includes a comment saying that loops spanning
> multiple blocks could be supported, but I would like to leave that
> for a future patch rather than trying to get it all working now.

The patch is ok.

As for the finding the branches, I'm pretty sure that 

  /* Head of the cyclic list of the exits of the loop.  */
  struct loop_exit *exits;

means what it says and contains all of the edges that exit
the block.  But doing that in a separate patch is fine.


r~

Re: [google]: initialize language field for clone function struct

[Joseph S. Myers]

On Tue, 3 May 2011, Nathan Froyd wrote:

> On Tue, May 03, 2011 at 07:06:58PM +, Joseph S. Myers wrote:
> > In my view we should require front ends to take responsibility for 
> > variable-size types, and get rid of this language-independent function 
> > (copying such parts as are needed into the front ends that need them).  C 
> > for example uses its own version as the language-independent one isn't 
> > right for C.  Similarly, the pending_size code should be local to front 
> > ends.
> 
> The raft of changes/improvements enabled by this change would be most
> welcome.  *_SIZE becoming double_ints or HOST_WIDE_INT instead of trees
> is the first thing that comes to mind; perhaps there are others.

I don't see how you can do that; you'll still have variable-sized types 
and objects, it would just be entirely the front end's responsibility to 
ensure that the size expression is evaluated exactly once (whenever 
required by the language).  At most, the size would either be a constant 
or an internal DECL created by the front end if you move that to the front 
end instead of using SAVE_EXPR.

However, I think the fields storing type and decl sizes (and alignment) in 
*bits* are suspect.  Values in bits are needed when dealing with bit-field 
layout, but I think types should otherwise be defined to be made up of 
whole bytes (bytes of BITS_PER_UNIT bits, at this level) with code dealing 
with bit-fields looking at TYPE_PRECISION as needed.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [google]: initialize language field for clone function struct

[Eric Botcazou]

> In my view we should require front ends to take responsibility for
> variable-size types, and get rid of this language-independent function
> (copying such parts as are needed into the front ends that need them).

I don't really see the point here.  GCC supports variable-sized types in the 
middle-end (stor-layout.c, gimplifier) so why special-casing this function?

> C for example uses its own version as the language-independent one isn't
> right for C.

The C version looks an almost exact duplicate of the generic one though.  We 
should probably try to reconciliate the different versions.

> Similarly, the pending_size code should be local to front ends.

Yes, I agree here.  gigi already does the full management and doesn't use it.

-- 
Eric Botcazou

Re: [google]: initialize language field for clone function struct

[Nathan Froyd]

On Tue, May 03, 2011 at 07:27:24PM +, Joseph S. Myers wrote:
> On Tue, 3 May 2011, Nathan Froyd wrote:
> > The raft of changes/improvements enabled by this change would be most
> > welcome.  *_SIZE becoming double_ints or HOST_WIDE_INT instead of trees
> > is the first thing that comes to mind; perhaps there are others.
> 
> I don't see how you can do that; you'll still have variable-sized types 
> and objects, it would just be entirely the front end's responsibility to 
> ensure that the size expression is evaluated exactly once (whenever 
> required by the language).

Ah, you're right.  I got carried away about thinking about FE-specific
data structures for things.

-Nathan

Re: [google]: initialize language field for clone function struct

[Joseph S. Myers]

On Tue, 3 May 2011, Eric Botcazou wrote:

> > In my view we should require front ends to take responsibility for
> > variable-size types, and get rid of this language-independent function
> > (copying such parts as are needed into the front ends that need them).
> 
> I don't really see the point here.  GCC supports variable-sized types in the 
> middle-end (stor-layout.c, gimplifier) so why special-casing this function?

In general errors from outside the front end, but relating to problems 
with the user's source code, are suspicious; the front end should detect 
invalid code, diagnose it and not pass it to the language-independent 
compiler.  And the exact language semantics regarding where variable-size 
types are permitted and when the sizes should be evaluated are inherently 
front-end-specific and not easily represented in a generic function.

convert.c is another place with errors that I think ought to go in the 
front ends; having some generic conversion logic is fine, but the front 
ends should deal with diagnosing invalid cases and convert.c should ICE if 
asked to do a conversion it doesn't know how to do.

> > C for example uses its own version as the language-independent one isn't
> > right for C.
> 
> The C version looks an almost exact duplicate of the generic one though.  We 
> should probably try to reconciliate the different versions.

C doesn't want the language-independent errors (see above); they don't 
reflect the right logic for C.  It needs to override parts of the generic 
function when called from generic code, and so to replace it when called 
from the front end.

C returns -1 from global_bindings_p, as does Ada.  That the languages that 
probably care most about variable-size types find aspects of the generic 
function need overriding like that should be a good indication that it 
isn't really that generic - as I said above, semantics for variable sizes 
are very front-end-specific.

-- 
Joseph S. Myers
jos...@codesourcery.com

[PATCH] Fix PR c++/48838

[Dodji Seketeli]

Hello,

This is another fallout of the fix for PR c++/47172, where we started
to make finish_call_expr make member function call expressions that
have a dependent "this" pointer be recognized by
type_dependent_expression_p as being type dependent.

The problem is that a node being a BASELINK is not enough to mean that
it represents a non-static member function, as it can also represent a
static member function.  In this patch I try to look at the actual
function wrapped by the BASELINK to make sure it's a non-static
member.

Tested and bootstrapped on x86_64-unknown-linux-gnu against trunk.
Another bootstrap is on it way on the 4.6 branch.

OK to commit to trunk and 4.6 if it passes?

gcc/cp

PR c++/48838
* cp-tree.h (non_static_member_function_p): Declare new function.
* tree.c (non_static_member_function_p): Define it.
* semantics.c (finish_call_expr): Use it.

gcc/testsuite

PR c++/48838
* g++.dg/template/member9.C: New test case.
---
 gcc/cp/cp-tree.h|1 +
 gcc/cp/semantics.c  |3 +--
 gcc/cp/tree.c   |   28 
 gcc/testsuite/g++.dg/template/member9.C |   21 +
 4 files changed, 51 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/template/member9.C

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 961581e..d694e25 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -5430,6 +5430,7 @@ extern tree get_fns   (tree);
 extern tree get_first_fn   (tree);
 extern tree ovl_cons   (tree, tree);
 extern tree build_overload (tree, tree);
+extern bool non_static_member_function_p(tree);
 extern const char *cxx_printable_name  (tree, int);
 extern const char *cxx_printable_name_translate(tree, int);
 extern tree build_exception_variant(tree, tree);
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 815824a..baa8fd4 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -2039,8 +2039,7 @@ finish_call_expr (tree fn, VEC(tree,gc) **args, bool 
disallow_virtual,
 is not included in *ARGS even though it is considered to
 be part of the list of arguments.  Note that this is
 related to CWG issues 515 and 1005.  */
- || (((TREE_CODE (TREE_TYPE (fn)) == METHOD_TYPE)
-  || BASELINK_P (fn))
+ || (non_static_member_function_p (fn)
  && current_class_ref
  && type_dependent_expression_p (current_class_ref)))
{
diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index 0f2f86c..039f795 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -1482,6 +1482,34 @@ build_overload (tree decl, tree chain)
   return ovl_cons (decl, chain);
 }
 
+/* Return TRUE if FN is a non-static member function, FALSE otherwise.
+   This function looks into BASELINK and OVERLOAD nodes.  */
+
+bool
+non_static_member_function_p (tree fn)
+{
+  if (fn == NULL_TREE)
+return false;
+
+  if (BASELINK_P (fn))
+{
+  tree type = TREE_TYPE (fn);
+
+  if (type && TREE_CODE (type) == METHOD_TYPE)
+   return true;
+  else if (type && TREE_CODE (type) == FUNCTION_TYPE)
+   return false;
+  /* This is an overload.  Lets look into its current value.  */
+  fn = get_fns (BASELINK_FUNCTIONS (fn));
+}
+
+  if (TREE_CODE (fn) == OVERLOAD)
+fn = OVL_CURRENT (fn);
+
+  return (DECL_P (fn)
+ && DECL_NONSTATIC_MEMBER_FUNCTION_P (fn));
+}
+
 
 #define PRINT_RING_SIZE 4
 
diff --git a/gcc/testsuite/g++.dg/template/member9.C 
b/gcc/testsuite/g++.dg/template/member9.C
new file mode 100644
index 000..f15272d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/member9.C
@@ -0,0 +1,21 @@
+// Origin PR c++/48838
+// { dg-do compile }
+
+class DUChainItemSystem
+{
+public:
+
+template
+void registerTypeClass();
+
+static DUChainItemSystem& self();
+};
+
+template
+struct DUChainItemRegistrator
+{
+DUChainItemRegistrator()
+{
+DUChainItemSystem::self().registerTypeClass();
+}
+};
-- 
1.7.3.4


-- 
Dodji

Re: [patch, fortran] Eliminate duplicate function calls with rank>0 and unknown shape

[Thomas Koenig]

Am 01.05.2011 11:49, schrieb Thomas Koenig:

Hello world,

after Paul's fix for allocate on assignment (thanks Paul!), here is a
patch for the original test case from PR 22572, where the bounds of
the function are unknown at compile time. This uses an allocatable
temporary.


Ping?

Thomas

Re: [google] Add new warning -Wreal-conversion (issue4436068)

[Jason Merrill]

On 04/29/2011 10:59 AM, Diego Novillo wrote:

This patch from Le-Chun Wu adds a new warning flag "-Wreal-conversion"
that warns about implicit type conversions from real (double or float)
values to integral values.


Why do you want to use this flag rather than just use -Wconversion?

Jason

Re: [patch] Add new -gmlt option for min. debug info with line tables (issue4440072)

[Jason Merrill]

On 04/26/2011 06:57 PM, Cary Coutant wrote:

I considered just changing -g1 to do this, with the argument that
"enough for making backtraces" ought to include line numbers and
inlined function calls, but I wasn't familiar enough with existing
uses of -g1 to go with that alternative. I'm certainly willing to go
that route, though, if that's preferable.


That makes sense to me; it seems appropriate for -g1 to have information 
that makes a backtrace more informative, but not information for 
interactive debugging.  Jim, do you have an opinion?


Jason

Re: [PATCH] Fix PR c++/48838

[Jason Merrill]

I think using get_first_fn could make non_static_member_function_p a lot 
shorter.


Jason

Re: [google]: initialize language field for clone function struct

[Eric Botcazou]

> C returns -1 from global_bindings_p, as does Ada.  That the languages that
> probably care most about variable-size types find aspects of the generic
> function need overriding like that should be a good indication that it
> isn't really that generic - as I said above, semantics for variable sizes
> are very front-end-specific.

I think that a large chunk of the non-generic code can be removed because it 
is either useless (the error) or obsolete (pending_size) in the 4.x series.
After that, if you prefer to make this particular function FE-specific, fine 
with me, but they will all essentially look alike.

-- 
Eric Botcazou

[PING] [PATCH] PR debug/28767 (Support pointer-to-member-function)

[Dodji Seketeli]

FWIW, this was posted to http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00949.html

--- Begin Message ---
Hello,

This PR is an enhancement request to emit a DW_TAG_ptr_to_member_type
DIE for pointer-to-member-function types.

The patch below does add a new language hook to support this and
adapts the existing code that emits DW_TAG_ptr_to_member_type for
ponter-to-data-member types to handle pointer-to-member-function types
as well.

Tested on x86_64-unknown-linux-gnu against trunk.

I am proposing this for 4.7.

-- 
Dodji

>From 36d971de3a01c83f8e23c4016262ea73357f6bd6 Mon Sep 17 00:00:00 2001
From: Dodji Seketeli 
Date: Tue, 15 Mar 2011 16:50:30 +0100
Subject: [PATCH] PR debug/28767 (Support pointer-to-member-function)

gcc/
* langhooks.h (struct lag_hooks_for_type):
Declare New language hook.
* hooks.h (hook_bool_const_tree_treeptr_false): Declare ...
hooks.c (hook_bool_const_tree_treeptr_false): ... new default
hook.
* langhooks-def.h (LANG_HOOKS_IS_PTR_TO_MEMBER): Define new hook
initializer.
(LANG_HOOKS_FOR_TYPES_INITIALIZER): Initialize the
is_ptr_to_member field to LANG_HOOKS_IS_PTR_TO_MEMBER.
* dwarf2out.c (gen_ptr_to_mbr_type_die): Handle
pointer-to-member-function in addition to pointer-to-data-member.
Both using the new language hook.
(gen_type_die_with_usage): Handle pointer-to-member-function and
pointer-to-data-member types with gen_ptr_to_mbr_type_die.

gcc/cp/

* cp-lang.c (is_ptr_to_member): New language hook implementation
for C++.
(LANG_HOOKS_IS_PTR_TO_MEMBER): Initialize this language hook for
C++.

gcc/testsuite/

* g++.dg/debug/dwarf2/ptrmem-1.C: New test.
---
 gcc/cp/cp-lang.c |   39 +-
 gcc/dwarf2out.c  |   58 --
 gcc/hooks.c  |7 +++
 gcc/hooks.h  |1 +
 gcc/langhooks-def.h  |2 +
 gcc/langhooks.h  |8 
 gcc/testsuite/g++.dg/debug/dwarf2/ptrmem-1.C |   20 +
 7 files changed, 112 insertions(+), 23 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/debug/dwarf2/ptrmem-1.C

diff --git a/gcc/cp/cp-lang.c b/gcc/cp/cp-lang.c
index e5c1c09..62faa1c 100644
--- a/gcc/cp/cp-lang.c
+++ b/gcc/cp/cp-lang.c
@@ -40,7 +40,7 @@ static enum classify_record cp_classify_record (tree type);
 static tree cp_eh_personality (void);
 static tree get_template_innermost_arguments_folded (const_tree);
 static tree get_template_argument_pack_elems_folded (const_tree);
-
+static bool is_ptr_to_member (const_tree, tree*);
 /* Lang hooks common to C++ and ObjC++ are declared in cp/cp-objcp-common.h;
consequently, there should be very few hooks below.  */
 
@@ -65,6 +65,9 @@ static tree get_template_argument_pack_elems_folded 
(const_tree);
 #undef LANG_HOOKS_GET_ARGUMENT_PACK_ELEMS
 #define LANG_HOOKS_GET_ARGUMENT_PACK_ELEMS \
get_template_argument_pack_elems_folded
+#undef LANG_HOOKS_IS_PTR_TO_MEMBER
+#define LANG_HOOKS_IS_PTR_TO_MEMBER \
+is_ptr_to_member
 #undef LANG_HOOKS_GENERIC_GENERIC_PARAMETER_DECL_P
 #define LANG_HOOKS_GENERIC_GENERIC_PARAMETER_DECL_P \
template_template_parameter_p
@@ -238,5 +241,39 @@ get_template_argument_pack_elems_folded (const_tree t)
   return fold_cplus_constants (get_template_argument_pack_elems (t));
 }
 
+/* The C++ implementation of LANG_HOOKS_GET_PTRMEM_TYPES.
+
+   Returns TRUE if T is a pointer-to-data-member or
+   a pointer-to-member-function.
+
+   If PTRMEM_INFO is non-null and if T is a
+   pointer-to-member-function, *PTRMEM_INFO is set to a TREE_LIST
+   which TREE_PURPOSE is the METHOD_TYPE of member-function pointed
+   to.  The TREE_VALUE is the class/struct type containing the member
+   function.  If T is a pointer-to-member, *PTRMEM_INFO is set to a
+   TREE_LIST which TREE_PURPOSE is the type of the member, and which
+   TREE_VALUE is the class/strunct type containing the data member.
+   The TREE_TYPE is set to T.  */
+
+static bool
+is_ptr_to_member (const_tree t,
+ tree *ptrmem_info)
+{
+  if (!t || !TYPE_PTR_TO_MEMBER_P (t))
+return false;
+
+  if (ptrmem_info != NULL)
+{
+  if (TYPE_PTRMEMFUNC_P (t))
+   *ptrmem_info = build_tree_list (TYPE_PTRMEMFUNC_FN_TYPE (t),
+TYPE_PTRMEMFUNC_OBJECT_TYPE (t));
+  else
+   *ptrmem_info = build_tree_list (TYPE_PTRMEM_POINTED_TO_TYPE (t),
+TYPE_PTRMEM_CLASS_TYPE (t));
+  TREE_TYPE (*ptrmem_info) = CONST_CAST_TREE (t);
+}
+  return true;
+}
+
 #include "gt-cp-cp-lang.h"
 #include "gtype-cp.h"
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 733c849..949c099 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -6520,7 +6520,7 @@ static void gen_label_die (tree, dw

Re: [debug] Remove unused debug_str_hash_forced code

[Jason Merrill]

OK.

Jason

Re: [PING] [PATCH] PR debug/28767 (Support pointer-to-member-function)

[Jason Merrill]

Instead of this, let's use a more general hook, something like 
"type_for_debug" that returns an OFFSET_TYPE for pointers to member 
functions.


Jason

Re: [PATCH 2/4] Docs: extend.texi: Remove trailing blanks from lines

[Gerald Pfeifer]

 sed -i "s/[ $(printf '\t')]\{1,\}\$//" trunk/gcc/doc/extend.texi

I believe we usually don't do whitespace changes just for the sake
of cleaning up things.

Unless someone else indicates otherwise, I believe this patch is
rejected.

Gerald

Re: [google]: initialize language field for clone function struct

[Joseph S. Myers]

On Tue, 3 May 2011, Eric Botcazou wrote:

> > C returns -1 from global_bindings_p, as does Ada.  That the languages that
> > probably care most about variable-size types find aspects of the generic
> > function need overriding like that should be a good indication that it
> > isn't really that generic - as I said above, semantics for variable sizes
> > are very front-end-specific.
> 
> I think that a large chunk of the non-generic code can be removed because it 
> is either useless (the error) or obsolete (pending_size) in the 4.x series.

Well - the errors in variable_size aren't used by C any more (since 4.5), 
but I don't know whether any other languages use them.  And pending sizes 
are used to a limited extent for C (to handle side effects in sizes of 
array parameters, as described in the comment

  /* ??? Insert the contents of the pending sizes list into the function
 to be evaluated.  The only reason left to have this is
void foo(int n, int array[n++])
 because we throw away the array type in favor of a pointer type, and
 thus won't naturally see the SAVE_EXPR containing the increment.  All
 other pending sizes would be handled by gimplify_parameters.  */

) although it would now be better to make use of the "expr" parameter to 
grokdeclarator to replace this residual use of the pending sizes global 
list.

The most suspect case for using generic variable-size code would be C++, 
which has some limited, poorly-defined VLA support as a GNU extension.  I 
don't know if Fortran, Java or Go use variable-size types at all.

> After that, if you prefer to make this particular function FE-specific, fine 
> with me, but they will all essentially look alike.

Actually, it will probably be possible the eliminate the function 
completely for C; there's no good reason to do more than calling save_expr 
directly.

  if (TREE_CONSTANT (size))
return size;

Redundant, save_expr checks for constants.

  size = save_expr (size);

The only necessary bit of c_variable_size once pending sizes are replaced 
by a better scheme.

  save = skip_simple_arithmetic (size);

Premature optimization.

  if (cfun && cfun->dont_save_pending_sizes_p)
return size;

  if (!global_bindings_p ())
put_pending_size (save);

No longer needed once pending sizes are replaced.

  return size;

So this just becomes equivalent to save_expr.

-- 
Joseph S. Myers
jos...@codesourcery.com

[PATCH, powerpc], Fix PR48857, pass/return V2DI as other vector types

[Michael Meissner]

When I added VSX support to the powerpc, I overlooked passing and return
V2DImode arguments, since the only machine operation that supports V2DI is
vector floating point conversion.  Consequentally, V2DI types were passed and
returned in GPRs instead of the vector registers on power7.

This patch fixes that so that V2DImode values are passed and returned like
other vector types.

I did a bootstrap and make check with no regressions, comparing it to a build
without the patch.  I also wrote a program that passed and returned every
single type, and I compared the assembly ouptut.  With the exception of
functions that return or are passed V2DI arguments, the code is identical.  I
tested:

-m64(implies -mabi=altivec)
-m32 -mabi=altivec
-m32 -mabi=no-altivec   (no difference here)

Is this patch ok to install?  I will also want to install it in the 4.6 and
possibly 4.5 trees as well.

[gcc]
2011-05-03  Michael Meissner  

PR target/48857
* config/rs6000/rs6000.h (VSX_SCALAR_MODE): Delete.
(VSX_MODE): Ditto.
(VSX_MOVE_MODE): Ditto.
(ALTIVEC_OR_VSX_VECTOR_MODE): New macro, combine all Altivec and
VSX vector types.  Add V2DImode.
(HARD_REGNO_CALLER_SAVE_MODE): Use it instead of
ALTIVEC_VECTOR_MODE and VSX_VECTOR_MODE calls.
(MODES_TIEABLE_P): Ditto.

* config/rs6000/rs6000.c (rs6000_emit_move): Use
ALTIVEC_OR_VSX_MODE instead of ALTIVEC_VECTOR_MODE and
VSX_VECTOR_MODE.
(init_cumulative_args): Ditto.
(rs6000_function_arg_boundary): Ditto.
(rs6000_function_arg_advance_1): Ditto.
(rs6000_function_arg): Ditto.
(rs6000_function_ok_for_sibcall): Ditto.
(emit_frame_save): Ditto.
(rs6000_function_value): Ditto.
(rs6000_libcall_value): Ditto.

[gcc/testsuite]
2011-05-03  Michael Meissner  

PR target/48857
* gcc.target/powerpc/pr48857.c: New file, make sure V2DI arguments
are passed and returned in vector registers.

-- 
Michael Meissner, IBM
5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA
meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899
[gcc]
2011-05-03  Michael Meissner  

PR target/48857
* config/rs6000/rs6000.h (VSX_SCALAR_MODE): Delete.
(VSX_MODE): Ditto.
(VSX_MOVE_MODE): Ditto.
(ALTIVEC_OR_VSX_VECTOR_MODE): New macro, combine all Altivec and
VSX vector types.  Add V2DImode.
(HARD_REGNO_CALLER_SAVE_MODE): Use it instead of
ALTIVEC_VECTOR_MODE and VSX_VECTOR_MODE calls.
(MODES_TIEABLE_P): Ditto.

* config/rs6000/rs6000.c (rs6000_emit_move): Use
ALTIVEC_OR_VSX_MODE instead of ALTIVEC_VECTOR_MODE and
VSX_VECTOR_MODE.
(init_cumulative_args): Ditto.
(rs6000_function_arg_boundary): Ditto.
(rs6000_function_arg_advance_1): Ditto.
(rs6000_function_arg): Ditto.
(rs6000_function_ok_for_sibcall): Ditto.
(emit_frame_save): Ditto.
(rs6000_function_value): Ditto.
(rs6000_libcall_value): Ditto.

[gcc/testsuite]
2011-05-03  Michael Meissner  

PR target/48857
* gcc.target/powerpc/pr48857.c: New file, make sure V2DI arguments
are passed and returned in vector registers.


Index: gcc/config/rs6000/rs6000.h
===
--- gcc/config/rs6000/rs6000.h  (revision 173266)
+++ gcc/config/rs6000/rs6000.h  (working copy)
@@ -1007,10 +1007,9 @@ extern unsigned rs6000_pointer_size;
 
 /* When setting up caller-save slots (MODE == VOIDmode) ensure we allocate
enough space to account for vectors in FP regs. */
-#define HARD_REGNO_CALLER_SAVE_MODE(REGNO, NREGS, MODE)\
-  (TARGET_VSX  \
-   && ((MODE) == VOIDmode || VSX_VECTOR_MODE (MODE)\
-   || ALTIVEC_VECTOR_MODE (MODE))  \
+#define HARD_REGNO_CALLER_SAVE_MODE(REGNO, NREGS, MODE)
\
+  (TARGET_VSX  \
+   && ((MODE) == VOIDmode || ALTIVEC_OR_VSX_VECTOR_MODE (MODE))
\
&& FP_REGNO_P (REGNO)   \
? V2DFmode  \
: choose_hard_reg_mode ((REGNO), (NREGS), false))
@@ -1026,25 +1025,16 @@ extern unsigned rs6000_pointer_size;
 ((MODE) == V4SFmode\
  || (MODE) == V2DFmode)\
 
-#define VSX_SCALAR_MODE(MODE)  \
-   ((MODE) == DFmode)
-
-#define VSX_MODE(MODE) \
-   (VSX_VECTOR_MODE (MODE) \
-|| VSX_SCALAR_MODE (MODE))
-
-#define VSX_MOVE_MODE(MODE)\
-   (VSX_VECTOR_MODE (MODE) \
-|| VSX_SCALAR_MODE (MODE)  \
-|| ALTIVEC_VECTOR_MODE (MODE)  \
-|| (MODE) == TImode)
-
 #define ALTIVEC_VECTOR_MODE(MODE)  \
 ((MODE) == V16QImode   \
 

[trunk][RFA] Add __i686.get_pc_thunk.bx to libgcc i386 morestack.S

[Chris Demetriou]

After I submitted
http://gcc.gnu.org/ml/gcc-patches/2011-04/msg02422.html, Rong Xu noted
that the resulting sources, if configured --with-pic, would not
actually build properly due to missing __i686.get_pc_thunk.bx (due to
my renaming that to __x86...).

While that issue was exposed by my change, in that configuration, in
summary my change exposed a latent issue in morestack.S.
(Callers of __i686.get_pc_thunk.bx (etc.) are also supposed to define
those functions -- because who knows whether the other objects they're
linked against will provide them.)

So, I've added the __i686.get_pc_thunk.bx function (as generated by
current GCC) to libgcc/config/i386/morestack.S.  (I also added __ELF__
#ifdefs and a .size directive for the function, following the apparent
conventions in the file.)


bootstrapped (C only) on Ubuntu Lucid x86-64, and ran -m32/-m64 tests
for compilers configured as normal, and also --with-pic.
No regressions before/after.


Ian, OK for trunk?


chris

[libgcc/ChangeLog]
2011-05-03  Chris Demetriou  

* libgcc/config/i386/morestack.S (__i686.get_pc_thunk.bx): New.
[libgcc/ChangeLog]
2011-05-03  Chris Demetriou  

	* libgcc/config/i386/morestack.S (__i686.get_pc_thunk.bx): New.

Index: libgcc/config/i386/morestack.S
===
--- libgcc/config/i386/morestack.S	(revision 173287)
+++ libgcc/config/i386/morestack.S	(working copy)
@@ -449,6 +449,24 @@
 	.size	__morestack, . - __morestack
 #endif
 
+#if !defined(__x86_64__) && defined(__PIC__)
+# Output the thunk to get PC into bx, since we use it above.
+# (__i686 was already undef'd above; don't need to worry about it here.)
+	.section	.text.__i686.get_pc_thunk.bx,"axG",@progbits,__i686.get_pc_thunk.bx,comdat
+	.globl	__i686.get_pc_thunk.bx
+	.hidden	__i686.get_pc_thunk.bx
+#ifdef __ELF__
+	.type	__i686.get_pc_thunk.bx, @function
+#endif
+__i686.get_pc_thunk.bx:
+	.cfi_startproc
+	movl	(%esp), %ebx
+	ret
+	.cfi_endproc
+#ifdef __ELF__
+	.size	__i686.get_pc_thunk.bx, . - __i686.get_pc_thunk.bx
+#endif
+#endif
 
 # The exception table.  This tells the personality routine to execute
 # the exception handler.

Re: [google] Patch to support calling multi-versioned functions via new GCC builtin. (issue4440078)

[Xinliang David Li]

On Tue, May 3, 2011 at 3:00 AM, Richard Guenther
 wrote:
> On Tue, May 3, 2011 at 1:07 AM, Xinliang David Li  wrote:
>> On Mon, May 2, 2011 at 2:33 PM, Richard Guenther
>>  wrote:
>>> On Mon, May 2, 2011 at 6:41 PM, Xinliang David Li  
>>> wrote:
 On Mon, May 2, 2011 at 2:11 AM, Richard Guenther
  wrote:
> On Fri, Apr 29, 2011 at 6:23 PM, Xinliang David Li  
> wrote:
>> Here is the background for this feature:
>>
>> 1) People relies on function multi-version to explore hw features and
>> squeeze performance, but there is no standard ways of doing so, either
>> a) using indirect function calls with function pointers set at program
>> initialization; b) using manual dispatch at each callsite; b) using
>> features like IFUNC.  The dispatch mechanism needs to be promoted to
>> the language level and becomes the first class citizen;
>
> You are not doing that, you are inventing a new (crude) GCC extension.

 To capture the high level semantics and prevent user from lowering the
 dispatch calls into forms compiler can not recognize, language
 extension is the way to go.
>>>
>>> I don't think so.  With your patch only two passes understand the new
>>> high-level form, the rest of the gimple passes are just confused.
>>
>> There is no need for other passes to understand it -- just treat it as
>> opaque calls. This is goodness otherwise other passes need to be
>> modified. This is true (only some passes understand it) for things
>> like __builtin_expect.
>
> Certainly __builtin_dispatch has to be understood by alias analysis and
> all other passes that care about calls (like all IPA passes).  You can
> of course treat it conservatively (may call any function, even those
> which have their address not taken, clobber and read all memory, even
> that which doesn't escape the TU).
>
> Why obfuscate things when it is not necessary?

MVed functions are usually non-trivial, so I doubt anything will be
lost due to the obfuscation. It won't be too difficult to teach
aliaser to 'merge' the attributes from target functions either.


>> No that is not my argument. What I tried to say is it will be harder
>> to achieve without high level semantics -- it requires more
>> handshaking between compiler passes.
>
> Sure - that's life.
>

We are looking at improving the life ..

>>> Which nobody will see benefit
>>> from unless they rewrite their code?
>>
>> The target users for the builtin include compiler itself -- it can
>> synthesize dispatch calls.
>
> Hum.  I'm not at all sure the dispatch calls are the best representation
> for the IL.
>

The intension is to provide an interface at both C level (for
programmers) and IL level.  It does not have to be a builtin (both
internally and externally)  -- but it needs to map to some language
construct.


>>> Well, I say if we can improve
>>> _some_ of the existing usages that's better than never doing wrong
>>> on a new language extension.
>>
>> This is independent.
>
> It is not.
>
>>> One that I'm not convinced is the way
>>> to go (you didn't address at all the inability to use float arguments
>>> and the ABI issues with using variadic arguments - after all you
>>> did a poor-mans language extension by using GCC builtins instead
>>> of inventing a true one).
>>
>> This is an independent issue that either needs to be addressed or
>> marked as limitation. The key of the debate is whether source/IR
>> annotation using construct with high level semantics helps optimizer.
>> In fact this is common. Would it make any difference (in terms of
>> acceptance) if the builtin is only used internally by the compiler and
>> not exposed to the user?
>
> No.  I don't see at all why having everything in a single stmt is so much
> more convenient.  And I don't see why existing IL features cannot be
> used to make things a little more convenient.

Why not? The high level construct is simpler to deal with. It is all
about doing the right optimization at the right level of abstraction.
Set aside the question whether using builtin for MV dispatch is the
right high level construct, looking at gcc, we can find that gcc's IR
is pretty low level resulting in missing optimizations.

For instance, there is no high level doloop representation -- Fortran
do-loop needs to be lowered and raised back again -- the consequence
is that you may not raise the loop nest into the way it was originally
written -- perfect nested loop become non-perfect loop nest --
blocking certain loop transformations.  Not only that, I am not sure
it is even possible to record any loop level information anywhere --
is it possible to have per loop attribute such as unroll factor?

Assuming gcc can do full math function inlining (for common math
routines) -- in this case, do we still want to do sin/cos optimization
or rely on the scalar optimizer to optimize the inlined copies of sin
and cos?

Not sure about gcc, I remember that dead temporary variable removal
can be ver

Re: [trunk][RFA] Add __i686.get_pc_thunk.bx to libgcc i386 morestack.S

[Ian Lance Taylor]

Chris Demetriou  writes:

> 2011-05-03  Chris Demetriou  
>
> * libgcc/config/i386/morestack.S (__i686.get_pc_thunk.bx): New.

No "libgcc" in libgcc/ChangeLog.

This is OK.

It is also OK if you s/__i686/__x86/ to correspond to your earlier
change.  Either way is OK.

Thanks.

Ian

Re: [google] Normalize version number for google/gcc-4_6 (issue4454049)

[Matthias Klose]

On 05/02/2011 09:53 PM, Diego Novillo wrote:

Since google/gcc-4_6 follows the 4.6 branch, changes in minor
revisions cause unnecessary churn in directory names.

Fixed with this.  OK for google/gcc-4_6?

Google ref 4335466.

* BASE-VER: Change to 4.6.x-google.

diff --git a/gcc/BASE-VER b/gcc/BASE-VER
index 4110f74..33d4edd 100644
--- a/gcc/BASE-VER
+++ b/gcc/BASE-VER
@@ -1 +1 @@
-4.6.1-google
+4.6.x-google


is this enough? the subminor version number is encoded in more places, e.g. C++ 
headers, Go libraries, jar files.  For the Debian/Ubuntu packaging I'm just 
using symlinks from 4.6.x to 4.6 to avoid this kind of dependency.  Now that the 
-V option isn't supported anymore, maybe this could be addressed with something 
like a new configure option --version-alias=, similar to the target alias.


  Matthias

[v3] libstdc++/48848

[Paolo Carlini]

Hi,

tested x86_64-linux, committed to mainline.

As regards the move assignment operator, the only non-trivial bit of the 
patch, per today's discussion on the reflector, essentially we want to 
be consistent with the resolution of LWG 675, thus make sure first that 
the move-assigned-to object releases any owned resources. This implies 
that at minimum the FDIS should be amended to a linear in size(), 
instead of constant, complexity (also, the "as-if" verbiage about 
resize(v.size()) is evidently bogus, likely a pasto from the preceding 
copy-assignment operator).


Thanks,
Paolo.


2011-05-03  Paolo Carlini  

PR libstdc++/48848
* include/std/valarray (valarray<>::valarray(valarray&&),
valarray<>::operator=(valarray&&), valarray<>::swap): Add.
* doc/xml/manual/status_cxx200x.xml: Update.
* testsuite/26_numerics/valarray/moveable.cc: New.
* testsuite/26_numerics/valarray/swap.cc: Likewise.
Index: doc/xml/manual/status_cxx200x.xml
===
--- doc/xml/manual/status_cxx200x.xml   (revision 173337)
+++ doc/xml/manual/status_cxx200x.xml   (working copy)
@@ -1960,11 +1960,10 @@
   
 
 
-  
   26.6.2
   Class template valarray
-  Partial
-  Missing move and swap operations
+  Y
+  
 
 
   26.6.3
Index: include/std/valarray
===
--- include/std/valarray(revision 173337)
+++ include/std/valarray(working copy)
@@ -1,7 +1,7 @@
 // The template and inlines for the -*- C++ -*- valarray class.
 
 // Copyright (C) 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
-// 2006, 2007, 2008, 2009, 2010
+// 2006, 2007, 2008, 2009, 2010, 2011
 // Free Software Foundation, Inc.
 //
 // This file is part of the GNU ISO C++ Library.  This library is free
@@ -140,6 +140,11 @@
   ///  Copy constructor.
   valarray(const valarray&);
 
+#ifdef __GXX_EXPERIMENTAL_CXX0X__
+  ///  Move constructor.
+  valarray(valarray&&) noexcept;
+#endif
+
   ///  Construct an array with the same size and values in @a sa.
   valarray(const slice_array<_Tp>&);
 
@@ -166,14 +171,24 @@
   /**
*  @brief  Assign elements to an array.
*
-   *  Assign elements of array to values in @a v.  Results are undefined
-   *  if @a v does not have the same size as this array.
+   *  Assign elements of array to values in @a v.
*
*  @param  v  Valarray to get values from.
*/
   valarray<_Tp>& operator=(const valarray<_Tp>&);
 
+#ifdef __GXX_EXPERIMENTAL_CXX0X__
   /**
+   *  @brief  Move assign elements to an array.
+   *
+   *  Move assign elements of array to values in @a v.
+   *
+   *  @param  v  Valarray to get values from.
+   */
+  valarray<_Tp>& operator=(valarray<_Tp>&&) noexcept;
+#endif
+
+  /**
*  @brief  Assign elements to a value.
*
*  Assign all elements of array to @a t.
@@ -450,6 +465,11 @@
valarray<_Tp>& operator>>=(const _Expr<_Dom, _Tp>&);
 
   // _lib.valarray.members_ member functions:
+#ifdef __GXX_EXPERIMENTAL_CXX0X__
+  ///  Swap.
+  void swap(valarray<_Tp>& __v) noexcept;
+#endif
+
   ///  Return the number of elements in array.
   size_t size() const;
 
@@ -612,8 +632,19 @@
 { std::__valarray_copy_construct(__v._M_data, __v._M_data + _M_size,
 _M_data); }
 
+#ifdef __GXX_EXPERIMENTAL_CXX0X__
   template
 inline
+valarray<_Tp>::valarray(valarray<_Tp>&& __v) noexcept
+: _M_size(__v._M_size), _M_data(__v._M_data)
+{
+  __v._M_size = 0;
+  __v._M_data = 0;
+}
+#endif
+
+  template
+inline
 valarray<_Tp>::valarray(const slice_array<_Tp>& __sa)
 : _M_size(__sa._M_sz), _M_data(__valarray_get_storage<_Tp>(__sa._M_sz))
 {
@@ -655,7 +686,7 @@
 inline
 valarray<_Tp>::valarray(initializer_list<_Tp> __l)
 : _M_size(__l.size()), _M_data(__valarray_get_storage<_Tp>(__l.size()))
-{ std::__valarray_copy_construct (__l.begin(), __l.end(), _M_data); }
+{ std::__valarray_copy_construct(__l.begin(), __l.end(), _M_data); }
 #endif
 
   template template
@@ -698,6 +729,22 @@
 #ifdef __GXX_EXPERIMENTAL_CXX0X__
   template
 inline valarray<_Tp>&
+valarray<_Tp>::operator=(valarray<_Tp>&& __v) noexcept
+{
+  if (_M_data)
+   {
+ std::__valarray_destroy_elements(_M_data, _M_data + _M_size);
+ std::__valarray_release_memory(_M_data);
+   }
+  _M_size = __v._M_size;
+  _M_data = __v._M_data;
+  __v._M_size = 0;
+  __v._M_data = 0;
+  return *this;
+}
+
+  template
+inline valarray<_Tp>&
 valarray<_Tp>::operator=(initializer_list<_Tp> __l)
 {
   // _GLIBCXX_RESOLVE_LIB_DEFECTS
@@ -846,7 +893,17 @@
 _Array(__i));
 }
 
+#if

Re: [trunk][RFA] Add __i686.get_pc_thunk.bx to libgcc i386 morestack.S

[Chris Demetriou]

On Tue, May 3, 2011 at 15:05, Ian Lance Taylor  wrote:
>
> > 2011-05-03  Chris Demetriou  
> >
> >         * libgcc/config/i386/morestack.S (__i686.get_pc_thunk.bx): New.
>
> No "libgcc" in libgcc/ChangeLog.

Fixed, sorry.  (That's what I get for pasting from svn status output.  8-)

> It is also OK if you s/__i686/__x86/ to correspond to your earlier
> change.  Either way is OK.

Well, that change is not in trunk.
Should that change move to trunk, yes, it's appropriate to change this
as well (though strictly not *necessary*).
(On the google branches, my plan was to rename, yes.)


chris

[google] backport r17317,r17347,r17342 to google/main (issue4430080)

[David Li]

Backport patches r17342, r173177, and r173147 from trunk to google/main + some 
minor cleanups for problems found in test.

Tested: bootstrap + regression test + SPEC06 LIPO testing.

Backport r173177
2011-05-03  David Li  

* tree-profile.c (init_ic_make_global_vars): Set
tls attribute on ic vars.
* coverage.c (coverage_end_function): Initialize
function_list with zero.

Backport r173147
2011-05-03  David Li  

* tree.c (crc32_string): Use crc32_byte.
(crc32_byte): New function.
* tree.h (crc32_byte): New function.
* gcov.c (read_graph_file): Handle new cfg_cksum.
(read_count_file): Ditto.
* profile.c (instrument_values): Ditto.
(get_exec_counts): Ditto.
(read_profile_edge_counts): Ditto.
(compute_branch_probabilities): Ditto.
(compute_value_histograms): Ditto.
(branch_prob): Ditto.
(end_branch_prob): Ditto.
* coverage.c (read_counts_file): Ditto.
(get_coverage_counts): Ditto.
(tree_coverage_counter_addr): Ditto.
(coverage_checksum_string): Ditto.
(coverage_begin_output): Ditto.
(coverage_end_function): Ditto.
(build_fn_info_type): Ditto.
(build_fn_info_value): Ditto.
* libgcov.c (gcov_exit): Ditto.
* gcov-dump.c (tag_function): Ditto.
(compute_checksum): Remove.

2011-05-03  David Li  

* l-ipo.c (promote_static_var_or_func): Keep initializer
for externalized aux module variables.
(process_module_scope_static_var): Keep initializer
for promoted static vars to allow ccp.

Backport r17342
2011-05-03  Xinliang David Li  

* gcc.dg/tree-ssa/integer-addr.c: New test.
* gcc.dg/tree-ssa/alias_bug.c: New test.

Index: tree.c
===
--- tree.c  (revision 173345)
+++ tree.c  (working copy)
@@ -8489,14 +8489,12 @@ dump_tree_statistics (void)
 
 #define FILE_FUNCTION_FORMAT "_GLOBAL__%s_%s"
 
-/* Generate a crc32 of a string.  */
+/* Generate a crc32 of a byte.  */
 
 unsigned
-crc32_string (unsigned chksum, const char *string)
+crc32_byte (unsigned chksum, char byte)
 {
-  do
-{
-  unsigned value = *string << 24;
+  unsigned value = (unsigned) byte << 24;
   unsigned ix;
 
   for (ix = 8; ix--; value <<= 1)
@@ -8507,6 +8505,18 @@ crc32_string (unsigned chksum, const cha
  chksum <<= 1;
  chksum ^= feedback;
}
+  return chksum;
+}
+
+
+/* Generate a crc32 of a string.  */
+
+unsigned
+crc32_string (unsigned chksum, const char *string)
+{
+  do
+{
+  chksum = crc32_byte (chksum, *string);
 }
   while (*string++);
   return chksum;
@@ -8530,8 +8540,10 @@ clean_symbol_name (char *p)
   *p = '_';
 }
 
-/* Generate a name for a special-purpose function function.
+/* Generate a name for a special-purpose function.
The generated name may need to be unique across the whole link.
+   Changes to this function may also require corresponding changes to
+   xstrdup_mask_random.
TYPE is some string to identify the purpose of this function to the
linker or collect2; it must start with an uppercase letter,
one of:
Index: tree.h
===
--- tree.h  (revision 173345)
+++ tree.h  (working copy)
@@ -4948,6 +4948,7 @@ inlined_function_outer_scope_p (const_tr
 
 /* In tree.c */
 extern unsigned crc32_string (unsigned, const char *);
+extern unsigned crc32_byte (unsigned, char);
 extern void clean_symbol_name (char *);
 extern tree get_file_function_name (const char *);
 extern tree get_callee_fndecl (const_tree);
Index: gcov.c
===
--- gcov.c  (revision 173345)
+++ gcov.c  (working copy)
@@ -54,6 +54,13 @@ along with Gcov; see the file COPYING3. 
some places we make use of the knowledge of how profile.c works to
select particular algorithms here.  */
 
+/* The code validates that the profile information read in corresponds
+   to the code currently being compiled.  Rather than checking for
+   identical files, the code below computes a checksum on the CFG
+   (based on the order of basic blocks and the arcs in the CFG).  If
+   the CFG checksum in the gcda file match the CFG checksum for the
+   code currently being compiled, the profile data will be used.  */
+
 /* This is the size of the buffer used to read in source file lines.  */
 
 #define STRING_SIZE 200
@@ -161,7 +168,8 @@ typedef struct function_info
   /* Name of function.  */
   char *name;
   unsigned ident;
-  unsigned checksum;
+  unsigned lineno_checksum;
+  unsigned cfg_checksum;
 
   /* Array of basic blocks.  */
   block_t *blocks;
@@ -809,12 +817,14 @@ read_graph_file (void)
   if (tag == GCOV_TAG_FUNCTION)
{
  char *function_name;
- unsigned ident, checksum, lineno;
+ unsigned ident, linen