Re: [PATCH] Fix PR47127: call cloog_state_malloc and cloog_state_free only once.

[Jakub Jelinek]

On Fri, Mar 11, 2011 at 03:38:49PM -0600, Sebastian Pop wrote:
> we currently call cloog_state_malloc and cloog_state_free too many
> times.  In CLooG-Parma, these functions contain the init and fini
> functions of PPL, and so calling these in the middle of graphite would
> finalize all the PPL data structures, leading to memory corruption.
> 
> This patch fixes this problem.  It passed make -k check
> RUNTESTFLAGS=graphite.exp with CLooG-ISL and CLooG-Parma (with only
> one ICE remaining as reported in http://gcc.gnu.org/PR47128 ).  Full
> regstrap with CLooG-ISL in progress on amd64-linux.  Ok for trunk?

This broke build with legacy CLooG, because build_cloog_prog
macro in graphite-cloog-compat.h hasn't been adjusted for the:

> --- a/gcc/graphite-clast-to-gimple.c
> +++ b/gcc/graphite-clast-to-gimple.c
> @@ -1236,7 +1236,7 @@ init_cloog_input_file (int scop_number)
>  
>  static void
>  build_cloog_prog (scop_p scop, CloogProgram *prog,
> -  CloogOptions *options, CloogState *state ATTRIBUTE_UNUSED)
> +  CloogOptions *options)
>  {
>int i;
>int max_nb_loops = scop_max_loop_depth (scop);

change.  Fixed thusly, committed to trunk as obvious.

2011-03-14  Jakub Jelinek  

PR bootstrap/48102
* graphite-cloog-compat.h (build_cloog_prog): Remove STATE
parameter.

--- gcc/graphite-cloog-compat.h.jj  2010-10-04 15:00:01.0 +0200
+++ gcc/graphite-cloog-compat.h 2011-03-14 09:14:26.033390135 +0100
@@ -1,6 +1,6 @@
 /* Compatibility layer for using upstream CLooG versions with
CLooG legacy code.
-   Copyright (C) 2010 Free Software Foundation, Inc.
+   Copyright (C) 2010, 2011 Free Software Foundation, Inc.
Contributed by Andreas Simbuerger .
 
 This file is part of GCC.
@@ -37,8 +37,8 @@ typedef const char *clast_name_p;
 #ifndef CLOOG_ORG
 
 /* CloogOptions compatibility.  */
-#define build_cloog_prog(SCOP, PROG, OPT, STATE)\
-  build_cloog_prog (SCOP, PROG, STATE)
+#define build_cloog_prog(SCOP, PROG, OPT)\
+  build_cloog_prog (SCOP, PROG)
 #define cloog_program_extract_scalars(PROG, SCATT, OPT)\
   cloog_program_extract_scalars (PROG, SCATT)
 #define cloog_program_scatter(PROG, SCATT, OPT)\


Jakub

Re: fix for pr47837

[Jakub Jelinek]

On Tue, Mar 08, 2011 at 09:54:42AM -0800, Xinliang David Li wrote:
> Please review the attached patch, it does some simplification of the
> complicated logical or expressions (x1 or x2 or x3 ...) constructed
> from control flow analysis into simpler form.

BTW, PR47679 is another case of predicates too complicated for
tree-ssa-uninit ATM.

Jakub

Re: ivopts improvement

[Zdenek Dvorak]

Hi,

> diff -u gcc/tree-ssa-loop-ivopts.c gcc/tree-ssa-loop-ivopts.c
> --- gcc/tree-ssa-loop-ivopts.c(working copy)
> +++ gcc/tree-ssa-loop-ivopts.c(working copy)
> @@ -1194,6 +1300,7 @@ record_use (struct ivopts_data *data, tr
>   gimple stmt, enum use_type use_type)
>  {
>struct iv_use *use = XCNEW (struct iv_use);
> +  tree tmp;
>  
>use->id = n_iv_uses (data);
>use->type = use_type;
> @@ -1204,11 +1311,14 @@ record_use (struct ivopts_data *data, tr
>  
>/* To avoid showing ssa name in the dumps, if it was not reset by the
>   caller.  */
> +  tmp = iv->ssa_name;
>iv->ssa_name = NULL_TREE;
>  
>if (dump_file && (dump_flags & TDF_DETAILS))
>  dump_use (dump_file, use);
>  
> +  iv->ssa_name = tmp;
> +
>VEC_safe_push (iv_use_p, heap, data->iv_uses, use);
>  
>return use;

this is not ok.  You can get the ssa name from extract_cond_operands.

> +  /* Determine if the exit test is formulated in terms of the phi or the
> + increment of the use iv.  */
> +  use_uses_inced_iv
> += gimple_code (SSA_NAME_DEF_STMT (use->iv->ssa_name)) != GIMPLE_PHI;
> +
> +  /* Determine if the exit test is before or after the increment of the
> + cand.  */
> +  use_after_cand_inc
> += stmt_after_increment (data->current_loop, cand, use->stmt);
> +
> +  /* For now, we only handle these cases.  */
> +  if (use_after_cand_inc != use_uses_inced_iv)
> +return false;

what is this trying to achieve?  USE_USES_INCED_IV is pretty much meaningless --
the value of USE does not depend in any way on whether it comes directly from
a PHI node or from some other calculation.

> +  /* Calculate bound.  */
> +  bound = fold_build_plus (PLUS_EXPR, base_ptr,
> +fold_convert (sizetype, use_lt_bound));
> +  if (bound == NULL_TREE)
> +return false;

How could the result be NULL_TREE?

Zdenek

PING: Reducing the overhead of dwarf2 location tracking

[Richard Sandiford]

Ping for this patch (for 4.6 and 4.5):

http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00255.html

It fixes a source of quadratic memory use while generating dwarf2
var-tracking information.

Thanks,
Richard

Re: [libgfortran, patch] More than 26 temporary files with weak mktemp()

[Janne Blomqvist]

On Sat, Mar 12, 2011 at 17:21, FX  wrote:
> The attached patch fixes half of PR 47439. On platform with weak or 
> historical implementations of mktemp(), this function cannot generate more 
> than 26 unique filenames for a given base. This happens in particular on 
> Windows, and limits us to 26 scratch files open simultaneously.
>
> The patch works around that by adding an almost unique prefix to the filename 
> string, which has a period of 17576. Thus, the new implementation allows to 
> generate 456976 unique filenames, which I deemed enough :)
>
> As the issue is not a regression, I don't think it's 4.6 material so, if 
> approved, I will commit when 4.7 branches unless instructed to do otherwise. 
> I'd also like feedback on the attached test: do we expect systems to fail 
> because of limits not allowing them to open 30 files?
>
> Manually tested on i586-pc-mingw32, regtested on x86_64-linux by editing 
> config.h to fake the absence of mkstemp().
> OK for 4.7?

A static variable which is modified introduces a race condition.
Secondly, you reset the count to 0 at the start of every loop which
makes the static thing superfluous?

One solution would be to declare count as an automatic int and set it
to 0 outside the do-while loop; this implies there will be an extra
trip through the loop once 26 temp files are in use, two extra trips
once 2*26 temp files are used etc. but I don't think this is worth
worrying about.

If that is not acceptable, one can manipulate the static counter with
__sync_fetch_and_add (with #ifdef HAVE_SYNC_FETCH_AND_ADD) or
protected by a mutex.

> PS: Please note that, on modern targets providing the POSIX mkstemp(), this 
> code is not used at all.
>
>



-- 
Janne Blomqvist

Re: fix for pr47837

[Richard Guenther]

On Sat, Mar 12, 2011 at 1:44 AM, Xinliang David Li  wrote:
> On Fri, Mar 11, 2011 at 11:50 AM, Jeff Law  wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 03/09/11 09:24, Xinliang David Li wrote:
>>> On Wed, Mar 9, 2011 at 6:03 AM, Jeff Law  wrote:
>>> On 03/09/11 02:45, Richard Guenther wrote:
>> On Tue, Mar 8, 2011 at 11:04 PM, Jeff Law  wrote:
>>>
>> True.  I've been repeatedly thinking of building some on-the-side CFG
>> with value-numbered predicates to also catch the CFG vs. scalar-code
>> predicate combinations we have.  On such on-the-side data structure
>> we could do very aggressive jump-threading just for analysis purposes
>> (experiments when working on separating conditions shows that
>> a PRE-like algorithm could drive this).
>>> I'm pondering the same kind of thing.  PRE on the predicates with a more
>>> structured approach to block copying to isolate the paths seems to be
>>> the way to go.
>>>
>>>
 Any simple examples to show how your idea would work?
>> Our current jump threading is just a special case of path isolation; the
>> biggest problem with path isolation is exploding codesize.
>
> Jump threading can reduce size in some cases -- due to more aggressive
> cleanups -- the -Os need to be more intelligent about it.
>
>>
>> I'd like to see that code generalized in a few ways based on well known
>> algorithms rather than the ad-hoc stuff we've got now keeping a
>> reasonable knob on the codesize bloat.
>>
>> In cases where we want more accurate warnings, but aren't willing to
>> accept the size bloat, on the side structures might be the way to go.
>>
>> I'm still looking a literature on the subject, but there's clearly
>> things we can do to improve the path sensitivity of the optimizers and
>> warning analysis.
>
> There are actually many papers on this (e.g. IMPACT group)  as a
> result of research for EPIC optimizations (predication and if
> convert). Most of them talk about predicate query systems (efficient
> and accurate), e.g PQS using partition graph, PAS using BDD etc.  The
> predicates relation can be built as side data structure, and the
> following queries can be made:
>
>  p1 = get_predicate (gimple_stmt1);
>  p2 = get_predicate (gimple_stmt2);
>
> if (is_disjoint (p1, p2) )
>  ..
> else if is_subset(p1, p2).
>   ..
>
> Keeping the information up to date with transformations can be difficult.

Sure, I'd say this is a clear candidate for something that would get
re-computed if needed.

Richard.

Add a testcase for reload PR 47166

[Richard Sandiford]

A reload patch that I posted in January:

http://gcc.gnu.org/ml/gcc-patches/2011-01/msg00548.html

turned out to be related to PR 47166, so Bernd committed a combined fix:


http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01620.htmlhttp://gcc.gnu.org/ml/gcc-patches/2011-01/msg01620.html

Is it OK to commit the testcase from the first patch to 4.5 and 4.6?

Thanks,
Richard


gcc/testsuite/
PR rtl-optimization/47166
* gcc.c-torture/execute/postmod-1.c: New test.

Index: gcc/testsuite/gcc.c-torture/execute/postmod-1.c
===
--- /dev/null   2010-12-14 12:47:12.274544604 +
+++ gcc/testsuite/gcc.c-torture/execute/postmod-1.c 2011-01-10 
13:52:05.0 +
@@ -0,0 +1,62 @@
+#define DECLARE_ARRAY(A) array##A[0x10]
+#define DECLARE_COUNTER(A) counter##A = 0
+#define DECLARE_POINTER(A) *pointer##A = array##A + x
+/* Create a loop that allows post-modification of pointerA, followed by
+   a use of the post-modified address.  */
+#define BEFORE(A) counter##A += *pointer##A, pointer##A += 3
+#define AFTER(A) counter##A += pointer##A[x]
+
+/* Set up the arrays so that one iteration of the loop sets the counter
+   to 3.0f.  */
+#define INIT_ARRAY(A) array##A[1] = 1.0f, array##A[5] = 2.0f
+
+/* Check that the loop worked correctly for all values.  */
+#define CHECK_ARRAY(A) exit_code |= (counter##A != 3.0f)
+
+/* Having 6 copies triggered the bug for ARM and Thumb.  */
+#define MANY(A) A (0), A (1), A (2), A (3), A (4), A (5)
+
+/* Each addendA should be allocated a register.  */
+#define INIT_VOLATILE(A) addend##A = vol
+#define ADD_VOLATILE(A) vol += addend##A
+
+/* Having 5 copies triggered the bug for ARM and Thumb.  */
+#define MANY2(A) A (0), A (1), A (2), A (3), A (4)
+
+float MANY (DECLARE_ARRAY);
+float MANY (DECLARE_COUNTER);
+
+volatile int stop = 1;
+volatile int vol;
+
+void __attribute__((noinline))
+foo (int x)
+{
+  float MANY (DECLARE_POINTER);
+  int i;
+
+  do
+{
+  MANY (BEFORE);
+  MANY (AFTER);
+  /* Create an inner loop that should ensure the code above
+has registers free for reload inheritance.  */
+  {
+   int MANY2 (INIT_VOLATILE);
+   for (i = 0; i < 10; i++)
+ MANY2 (ADD_VOLATILE);
+  }
+}
+  while (!stop);
+}
+
+int
+main (void)
+{
+  int exit_code = 0;
+
+  MANY (INIT_ARRAY);
+  foo (1);
+  MANY (CHECK_ARRAY);
+  return exit_code;
+}

Re: [libgfortran, patch] More than 26 temporary files with weak mktemp()

[Jakub Jelinek]

On Mon, Mar 14, 2011 at 12:18:16PM +0200, Janne Blomqvist wrote:
> On Sat, Mar 12, 2011 at 17:21, FX  wrote:
> A static variable which is modified introduces a race condition.

That is true.

> Secondly, you reset the count to 0 at the start of every loop which
> makes the static thing superfluous?

This is wrong, in C, C++
static int count = 0;
means that the static variable is initialized to 0 in its static storage,
not that count = 0; is executed anywhere where the static block local
variable enters its scope.  The "= 0" part is redundant for static vars
BTW, static vars are initialized to 0 when they don't have an explicit
initializer.

If M$ mktemp when already 26 files exist with the same prefix at least
properly fails, then it would be better to just retry with a changed prefix
if it fails.

Jakub

Re: [libgfortran, patch] More than 26 temporary files with weak mktemp()

[Kai Tietz]

2011/3/14 Jakub Jelinek :
> On Mon, Mar 14, 2011 at 12:18:16PM +0200, Janne Blomqvist wrote:
>> On Sat, Mar 12, 2011 at 17:21, FX  wrote:
>> A static variable which is modified introduces a race condition.
>
> That is true.
>
>> Secondly, you reset the count to 0 at the start of every loop which
>> makes the static thing superfluous?
>
> If M$ mktemp when already 26 files exist with the same prefix at least
> properly fails, then it would be better to just retry with a changed prefix
> if it fails.

Yes, altering prefix here would be in my opinion the saner way.
Additional there shouldn't be a need to add locking, as a file itself
is created if not already present, which represents a file-locking
already.

Regards,
Kai

[PATCH] Fix PR48098

[Richard Guenther]

I am currently testing the following patch for PR48098 which exposes
the fact that TREE_TYPE (vector-type) does not return T when
vector-type is built using make_vector_type (T).  This is because
we move all qualifiers from T to the vector-type and keep an unqualified
element type.  This finally confuses us with the requirement to
preserve conversions to restrict qualified pointers.

I need to think about this more.  For now make the check symmetric
(it's a bug that it wasn't) and compare unqualified types.  Any
issues this hides are missed optimizations with respect to restrict
handling.  It also eventually just postpones verification ICEs to
later phases.

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

Richard.

2011-03-14  Richard Guenther  

PR middle-end/48098
* tree.c (build_vector_from_val): Adjust assert to requirements
and reality.

* gcc.dg/torture/pr48098.c: New testcase.

Index: gcc/tree.c
===
*** gcc/tree.c  (revision 170933)
--- gcc/tree.c  (working copy)
*** build_vector_from_val (tree vectype, tre
*** 1376,1383 
if (sc == error_mark_node)
  return sc;
  
!   gcc_assert (useless_type_conversion_p (TREE_TYPE (sc),
!TREE_TYPE (vectype)));
  
v = VEC_alloc (constructor_elt, gc, nunits);
for (i = 0; i < nunits; ++i)
--- 1376,1389 
if (sc == error_mark_node)
  return sc;
  
!   /* Verify that the vector type is suitable for SC.  Note that there
!  is some inconsistency in the type-system with respect to restrict
!  qualifications of pointers.  Vector types always have a main-variant
!  element type and the qualification is applied to the vector-type.
!  So TREE_TYPE (vector-type) does not return a properly qualified
!  vector element-type.  */
!   gcc_checking_assert (types_compatible_p (TYPE_MAIN_VARIANT (TREE_TYPE (sc)),
!  TREE_TYPE (vectype)));
  
v = VEC_alloc (constructor_elt, gc, nunits);
for (i = 0; i < nunits; ++i)
Index: gcc/testsuite/gcc.dg/torture/pr48098.c
===
*** gcc/testsuite/gcc.dg/torture/pr48098.c  (revision 0)
--- gcc/testsuite/gcc.dg/torture/pr48098.c  (revision 0)
***
*** 0 
--- 1,12 
+ /* { dg-do compile } */
+ 
+ void
+ foo (int n)
+ {
+   static char *__restrict *p;
+   int i;
+   p = __builtin_malloc (n);
+   for (i = 0; i < n; i++)
+ p[i] = 0;
+ }
+ 

Re: Add a testcase for reload PR 47166

[Richard Guenther]

On Mon, Mar 14, 2011 at 11:25 AM, Richard Sandiford
 wrote:
> A reload patch that I posted in January:
>
>    http://gcc.gnu.org/ml/gcc-patches/2011-01/msg00548.html
>
> turned out to be related to PR 47166, so Bernd committed a combined fix:
>
>    
> http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01620.htmlhttp://gcc.gnu.org/ml/gcc-patches/2011-01/msg01620.html
>
> Is it OK to commit the testcase from the first patch to 4.5 and 4.6?

Sure.

Thanks,
Richard.

> Thanks,
> Richard
>
>
> gcc/testsuite/
>        PR rtl-optimization/47166
>        * gcc.c-torture/execute/postmod-1.c: New test.
>
> Index: gcc/testsuite/gcc.c-torture/execute/postmod-1.c
> ===
> --- /dev/null   2010-12-14 12:47:12.274544604 +
> +++ gcc/testsuite/gcc.c-torture/execute/postmod-1.c     2011-01-10 
> 13:52:05.0 +
> @@ -0,0 +1,62 @@
> +#define DECLARE_ARRAY(A) array##A[0x10]
> +#define DECLARE_COUNTER(A) counter##A = 0
> +#define DECLARE_POINTER(A) *pointer##A = array##A + x
> +/* Create a loop that allows post-modification of pointerA, followed by
> +   a use of the post-modified address.  */
> +#define BEFORE(A) counter##A += *pointer##A, pointer##A += 3
> +#define AFTER(A) counter##A += pointer##A[x]
> +
> +/* Set up the arrays so that one iteration of the loop sets the counter
> +   to 3.0f.  */
> +#define INIT_ARRAY(A) array##A[1] = 1.0f, array##A[5] = 2.0f
> +
> +/* Check that the loop worked correctly for all values.  */
> +#define CHECK_ARRAY(A) exit_code |= (counter##A != 3.0f)
> +
> +/* Having 6 copies triggered the bug for ARM and Thumb.  */
> +#define MANY(A) A (0), A (1), A (2), A (3), A (4), A (5)
> +
> +/* Each addendA should be allocated a register.  */
> +#define INIT_VOLATILE(A) addend##A = vol
> +#define ADD_VOLATILE(A) vol += addend##A
> +
> +/* Having 5 copies triggered the bug for ARM and Thumb.  */
> +#define MANY2(A) A (0), A (1), A (2), A (3), A (4)
> +
> +float MANY (DECLARE_ARRAY);
> +float MANY (DECLARE_COUNTER);
> +
> +volatile int stop = 1;
> +volatile int vol;
> +
> +void __attribute__((noinline))
> +foo (int x)
> +{
> +  float MANY (DECLARE_POINTER);
> +  int i;
> +
> +  do
> +    {
> +      MANY (BEFORE);
> +      MANY (AFTER);
> +      /* Create an inner loop that should ensure the code above
> +        has registers free for reload inheritance.  */
> +      {
> +       int MANY2 (INIT_VOLATILE);
> +       for (i = 0; i < 10; i++)
> +         MANY2 (ADD_VOLATILE);
> +      }
> +    }
> +  while (!stop);
> +}
> +
> +int
> +main (void)
> +{
> +  int exit_code = 0;
> +
> +  MANY (INIT_ARRAY);
> +  foo (1);
> +  MANY (CHECK_ARRAY);
> +  return exit_code;
> +}
>

Re: [libgfortran, patch] More than 26 temporary files with weak mktemp()

[Janne Blomqvist]

On Mon, Mar 14, 2011 at 12:31, Jakub Jelinek  wrote:
> On Mon, Mar 14, 2011 at 12:18:16PM +0200, Janne Blomqvist wrote:
>> On Sat, Mar 12, 2011 at 17:21, FX  wrote:
>> A static variable which is modified introduces a race condition.
>
> That is true.
>
>> Secondly, you reset the count to 0 at the start of every loop which
>> makes the static thing superfluous?
>
> This is wrong, in C, C++
> static int count = 0;
> means that the static variable is initialized to 0 in its static storage,
> not that count = 0; is executed anywhere where the static block local
> variable enters its scope.

Oops, brown paper bag moment. :)

I remembered that this was a case where C and Fortran differ, but
alas, both work similarly.

>  The "= 0" part is redundant for static vars
> BTW, static vars are initialized to 0 when they don't have an explicit
> initializer.

Well, FWIW, this is where C and Fortran differ, as Fortran static vars
(SAVE) have undefined initial value unless explicitly initialized. In
practice, gfortran puts them into .bss so they are zero initialized,
but from the perspective of the standard their value is undefined.

> If M$ mktemp when already 26 files exist with the same prefix at least
> properly fails, then it would be better to just retry with a changed prefix
> if it fails.

Yes, this was what I meant with my proposal to make count an automatic
instead of static and initializing it outside the do-while loop.


-- 
Janne Blomqvist

Re: ivopts improvement

[Tom de Vries]

On 03/14/2011 10:58 AM, Zdenek Dvorak wrote:
> Hi,
> 
>> diff -u gcc/tree-ssa-loop-ivopts.c gcc/tree-ssa-loop-ivopts.c
>> --- gcc/tree-ssa-loop-ivopts.c   (working copy)
>> +++ gcc/tree-ssa-loop-ivopts.c   (working copy)
>> @@ -1194,6 +1300,7 @@ record_use (struct ivopts_data *data, tr
>>  gimple stmt, enum use_type use_type)
>>  {
>>struct iv_use *use = XCNEW (struct iv_use);
>> +  tree tmp;
>>  
>>use->id = n_iv_uses (data);
>>use->type = use_type;
>> @@ -1204,11 +1311,14 @@ record_use (struct ivopts_data *data, tr
>>  
>>/* To avoid showing ssa name in the dumps, if it was not reset by the
>>   caller.  */
>> +  tmp = iv->ssa_name;
>>iv->ssa_name = NULL_TREE;
>>  
>>if (dump_file && (dump_flags & TDF_DETAILS))
>>  dump_use (dump_file, use);
>>  
>> +  iv->ssa_name = tmp;
>> +
>>VEC_safe_push (iv_use_p, heap, data->iv_uses, use);
>>  
>>return use;
> 
> this is not ok.  You can get the ssa name from extract_cond_operands.
> 

Ok, I did that now.

>> +  /* Determine if the exit test is formulated in terms of the phi or the
>> + increment of the use iv.  */
>> +  use_uses_inced_iv
>> += gimple_code (SSA_NAME_DEF_STMT (use->iv->ssa_name)) != GIMPLE_PHI;
>> +
>> +  /* Determine if the exit test is before or after the increment of the
>> + cand.  */
>> +  use_after_cand_inc
>> += stmt_after_increment (data->current_loop, cand, use->stmt);
>> +
>> +  /* For now, we only handle these cases.  */
>> +  if (use_after_cand_inc != use_uses_inced_iv)
>> +return false;
> 
> what is this trying to achieve?  USE_USES_INCED_IV is pretty much meaningless 
> --
> the value of USE does not depend in any way on whether it comes
> directly from
> a PHI node or from some other calculation.

it is trying to allow for

do
  {
*p = '\0';
i++; /* use_uses_inced_iv == true */
p++; /* use_after_cand_inc == true */
if (!(i < n))
  break;
  }
while (1);

and for

do
  {
*p = '\0';
if (!(i < n))
  break;
i++; /* use_uses_inced_iv == false */
p++; /* use_after_cand_inc == false */
  }
while (1);

but not for

do
  {
*p = '\0';
i++; /* use_uses_inced_iv == true */
if (!(i < n))
  break;
p++; /* use_after_cand_inc == false */
  }
while (1);

and not for

do
  {
*p = '\0';
p++; /* use_after_cand_inc == true */
if (!(i < n))
  break;
i++; /* use_uses_inced_iv == false */
  }
while (1);

In the latter 2 cases, I cannot simply replace i < n with p < base + n.

>> +  /* Calculate bound.  */
>> +  bound = fold_build_plus (PLUS_EXPR, base_ptr,
>> +   fold_convert (sizetype, use_lt_bound));
>> +  if (bound == NULL_TREE)
>> +return false;
> 
> How could the result be NULL_TREE?

It can't, indeed. I removed that now.

- Tom
diff -u gcc/tree-ssa-loop-ivopts.c gcc/tree-ssa-loop-ivopts.c
--- gcc/tree-ssa-loop-ivopts.c	(working copy)
+++ gcc/tree-ssa-loop-ivopts.c	(working copy)
@@ -419,6 +419,67 @@
   return fold_build2 (code, TREE_TYPE (a), a, b);
 }
 
+/* Folds (TREE_TYPE (A))(A CODE B), where CODE is either PLUS_EXPR or
+   MINUS_EXPR.  Returns the folded expression if folding is successful.
+   Otherwise, return NULL_TREE.  Handles the case that A is a pointer
+   robustly.  */
+
+static inline tree
+fold_plus (enum tree_code code, tree a, tree b)
+{
+  tree a_type = TREE_TYPE (a);
+  tree res;
+
+  STRIP_NOPS (a);
+  robust_plus (&code, a, &b);
+
+  res = fold_binary (code, TREE_TYPE (a), a, b);
+  if (res == NULL_TREE)
+return NULL_TREE;
+
+  return fold_convert (a_type, res);
+}
+
+/* Folds (TREE_TYPE (A))(A CODE B), where CODE is either PLUS_EXPR or
+   MINUS_EXPR, possibly using the defining stmt of A.  Returns the folded
+   expression if folding is successful.  Otherwise, return NULL_TREE.  */
+
+static inline tree
+fold_walk_def_plus (enum tree_code code, tree a, tree b)
+{
+  tree a_type = TREE_TYPE (a);
+  tree res, a0, a1;
+  gimple def_stmt;
+
+  res = fold_plus (code, a, b);
+  if (res != NULL_TREE)
+return res;
+
+  STRIP_NOPS (a);
+
+  if (TREE_CODE (a) != SSA_NAME)
+return NULL_TREE;
+
+  def_stmt = SSA_NAME_DEF_STMT (a);
+  if (!is_gimple_assign (def_stmt)
+  || (gimple_assign_rhs_code (def_stmt) != PLUS_EXPR
+	  && gimple_assign_rhs_code (def_stmt) != POINTER_PLUS_EXPR))
+return NULL_TREE;
+  a0 = gimple_assign_rhs1 (def_stmt);
+  a1 = gimple_assign_rhs2 (def_stmt);
+
+  def_stmt = SSA_NAME_DEF_STMT (a1);
+  if (is_gimple_assign (def_stmt)
+  && CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (def_stmt)))
+a1 = fold_convert (TREE_TYPE (a1), gimple_assign_rhs1 (def_stmt));
+
+  res = fold_plus (code, fold_build_plus (PLUS_EXPR, a0, a1), b);
+  if (res == NULL_TREE)
+return NULL_TREE;
+
+  return fold_convert (a_type, res);
+}
+
 /* Number of uses recorded in DATA.  */
 
 static inline unsigned
@@ -825,17 +886,25 @@
 
   if (!slot)
 {
-  /* Try to determine number of iterations.  We must know it
-	 unconditionally (i.e.

Fix for PR target/47951

[Henderson, Stuart]

Hi,
The attached patch is an attempt to fix PR 47951, however I'm fairly new to GCC 
and have little confidence in it.  I've done some testing with it and it avoids 
the problem and doesn't appear to cause any new problems, but I'd appreciate 
more experienced eyes looking over it and giving pointers.
Thanks,
Stu


47951.patch
Description: 47951.patch

Re: ivopts improvement

[Zdenek Dvorak]

Hi,

> >> +  /* Determine if the exit test is formulated in terms of the phi or the
> >> + increment of the use iv.  */
> >> +  use_uses_inced_iv
> >> += gimple_code (SSA_NAME_DEF_STMT (use->iv->ssa_name)) != GIMPLE_PHI;
> >> +
> >> +  /* Determine if the exit test is before or after the increment of the
> >> + cand.  */
> >> +  use_after_cand_inc
> >> += stmt_after_increment (data->current_loop, cand, use->stmt);
> >> +
> >> +  /* For now, we only handle these cases.  */
> >> +  if (use_after_cand_inc != use_uses_inced_iv)
> >> +return false;
> > 
> > what is this trying to achieve?  USE_USES_INCED_IV is pretty much 
> > meaningless --
> > the value of USE does not depend in any way on whether it comes
> > directly from
> > a PHI node or from some other calculation.
> 
> it is trying to allow for
> 
> do
>   {
> *p = '\0';
> i++; /* use_uses_inced_iv == true */
> p++; /* use_after_cand_inc == true */
> if (!(i < n))
>   break;
>   }
> while (1);
> 
> and for
> 
> do
>   {
> *p = '\0';
> if (!(i < n))
>   break;
> i++; /* use_uses_inced_iv == false */
> p++; /* use_after_cand_inc == false */
>   }
> while (1);
> 
> but not for
> 
> do
>   {
> *p = '\0';
> i++; /* use_uses_inced_iv == true */
> if (!(i < n))
>   break;
> p++; /* use_after_cand_inc == false */
>   }
> while (1);
> 
> and not for
> 
> do
>   {
> *p = '\0';
> p++; /* use_after_cand_inc == true */
> if (!(i < n))
>   break;
> i++; /* use_uses_inced_iv == false */
>   }
> while (1);
> 
> In the latter 2 cases, I cannot simply replace i < n with p < base + n.

Why not (other than that the value to compare with varies in these cases, but
it always is "the value of p in the last iteration of the loop")?

One more thing: what is fold_walk_def_plus for?

Zdenek

Re: ivopts improvement

[Tom de Vries]

On 03/14/2011 01:14 PM, Zdenek Dvorak wrote:
> Hi,
> 
 +  /* Determine if the exit test is formulated in terms of the phi or the
 + increment of the use iv.  */
 +  use_uses_inced_iv
 += gimple_code (SSA_NAME_DEF_STMT (use->iv->ssa_name)) != GIMPLE_PHI;
 +
 +  /* Determine if the exit test is before or after the increment of the
 + cand.  */
 +  use_after_cand_inc
 += stmt_after_increment (data->current_loop, cand, use->stmt);
 +
 +  /* For now, we only handle these cases.  */
 +  if (use_after_cand_inc != use_uses_inced_iv)
 +return false;
>>>
>>> what is this trying to achieve?  USE_USES_INCED_IV is pretty much 
>>> meaningless --
>>> the value of USE does not depend in any way on whether it comes
>>> directly from
>>> a PHI node or from some other calculation.
>>
>> it is trying to allow for
>>
>> do
>>   {
>> *p = '\0';
>> i++; /* use_uses_inced_iv == true */
>> p++; /* use_after_cand_inc == true */
>> if (!(i < n))
>>   break;
>>   }
>> while (1);
>>
>> and for
>>
>> do
>>   {
>> *p = '\0';
>> if (!(i < n))
>>   break;
>> i++; /* use_uses_inced_iv == false */
>> p++; /* use_after_cand_inc == false */
>>   }
>> while (1);
>>
>> but not for
>>
>> do
>>   {
>> *p = '\0';
>> i++; /* use_uses_inced_iv == true */
>> if (!(i < n))
>>   break;
>> p++; /* use_after_cand_inc == false */
>>   }
>> while (1);
>>
>> and not for
>>
>> do
>>   {
>> *p = '\0';
>> p++; /* use_after_cand_inc == true */
>> if (!(i < n))
>>   break;
>> i++; /* use_uses_inced_iv == false */
>>   }
>> while (1);
>>
>> In the latter 2 cases, I cannot simply replace i < n with p < base + n.
> 
> Why not (other than that the value to compare with varies in these cases, but
> it always is "the value of p in the last iteration of the loop")?

In the 2 latter cases, the value to compare with will be either base + n
+ 1 or base + n - 1. The code does not handle these cases yet.

> One more thing: what is fold_walk_def_plus for?

It tries to fold a plus, and if not successful, finds ssa vars in
operands of the plus, substitutes the defining statements of ssa vars
for those ssa vars and retries folding.

Thanks,
- Tom

Re: ivopts improvement

[Zdenek Dvorak]

Hi,

> >> it is trying to allow for
> >>
> >> do
> >>   {
> >> *p = '\0';
> >> i++; /* use_uses_inced_iv == true */
> >> p++; /* use_after_cand_inc == true */
> >> if (!(i < n))
> >>   break;
> >>   }
> >> while (1);
> >>
> >> and for
> >>
> >> do
> >>   {
> >> *p = '\0';
> >> if (!(i < n))
> >>   break;
> >> i++; /* use_uses_inced_iv == false */
> >> p++; /* use_after_cand_inc == false */
> >>   }
> >> while (1);
> >>
> >> but not for
> >>
> >> do
> >>   {
> >> *p = '\0';
> >> i++; /* use_uses_inced_iv == true */
> >> if (!(i < n))
> >>   break;
> >> p++; /* use_after_cand_inc == false */
> >>   }
> >> while (1);
> >>
> >> and not for
> >>
> >> do
> >>   {
> >> *p = '\0';
> >> p++; /* use_after_cand_inc == true */
> >> if (!(i < n))
> >>   break;
> >> i++; /* use_uses_inced_iv == false */
> >>   }
> >> while (1);
> >>
> >> In the latter 2 cases, I cannot simply replace i < n with p < base + n.
> > 
> > Why not (other than that the value to compare with varies in these cases, 
> > but
> > it always is "the value of p in the last iteration of the loop")?
> 
> In the 2 latter cases, the value to compare with will be either base + n
> + 1 or base + n - 1. The code does not handle these cases yet.

well, if not, then it certainly handles one of the first two cases incorrectly
(since the use_uses_inced_iv test is meaningless).

> > One more thing: what is fold_walk_def_plus for?
> 
> It tries to fold a plus, and if not successful, finds ssa vars in
> operands of the plus, substitutes the defining statements of ssa vars
> for those ssa vars and retries folding.

Sorry for not being more clear; I meant, why is it used?

Zdenek

Re: fix for pr47837

[Diego Novillo]

On Fri, Mar 11, 2011 at 14:32, Jeff Law  wrote:

>> Regarding this particular patch, I hope it can be checked in to make
>> the test clean. It is a simple enhancement to a wheel that is already
>> there. It also serves as a case that can be referenced in the future
>> when the more general mechanism is available.
> Just to be clear, I'm not going to object to this patch; I don't have
> the time right now to really look at it.
>
> I was merely raising the issue that we have a need to solve the larger
> problem and that we need to be looking a the bigger picture.

Agreed.  I'm not happy about the patch, but I won't object to it.
It's clear, however, that we cannot keep adding hack on top of hack
here.  David, will you be looking at creating a more general solution
for 4.7?

Given the stage we are in, you will need OKs from our release managers for 4.6.


Diego.

[cxx-mem-model] options for controlling data races

[Aldy Hernandez]

The following patch adds the --param(eters) needed to tweak the 
optimizers into allowing or disallowing data races in cross-thread 
visible data.


There will be additional flags added later to make these parameters 
available to the common user.  It has been suggested to use 
-fmemory-model=xxx, but I will implement this later.


The next step will be to find out where we introduce the data races in 
the testsuite, and fix the optimizers accordingly.


Committed to branch.
* params.h (ALLOW_LOAD_DATA_RACES): New.
(ALLOW_STORE_DATA_RACES): New.
(ALLOW_PACKED_LOAD_DATA_RACES): New.
(ALLOW_PACKED_STORE_DATA_RACES): New.
* params.def (PARAM_ALLOW_LOAD_DATA_RACES): New.
(PARAM_ALLOW_STORE_DATA_RACES): New.
(PARAM_ALLOW_PACKED_LOAD_DATA_RACES): New.
(PARAM_ALLOW_PACKED_STORE_DATA_RACES): New.
* doc/invoke.texi (Optimize Options): Document above parameters.

Index: doc/invoke.texi
===
--- doc/invoke.texi (revision 170745)
+++ doc/invoke.texi (working copy)
@@ -8897,6 +8897,26 @@ partitions.
 The maximum number of namespaces to consult for suggestions when C++
 name lookup fails for an identifier.  The default is 1000.
 
+@item allow-load-data-races
+Allow optimizers to introduce new data races on loads.
+Set to 1 to allow, otherwise to 0.  This option is enabled by default
+unless implicitly set by the @option{-fmemory-model=} option.
+
+@item allow-store-data-races
+Allow optimizers to introduce new data races on stores.
+Set to 1 to allow, otherwise to 0.  This option is enabled by default
+unless implicitly set by the @option{-fmemory-model=} option.
+
+@item allow-packed-load-data-races
+Allow optimizers to introduce new data races on packed data loads.
+Set to 1 to allow, otherwise to 0.  This option is enabled by default
+unless implicitly set by the @option{-fmemory-model=} option.
+
+@item allow-packed-store-data-races
+Allow optimizers to introduce new data races on packed data stores.
+Set to 1 to allow, otherwise to 0.  This option is enabled by default
+unless implicitly set by the @option{-fmemory-model=} option.
+
 @end table
 @end table
 
Index: params.h
===
--- params.h(revision 170745)
+++ params.h(working copy)
@@ -206,4 +206,13 @@ extern void init_param_values (int *para
   PARAM_VALUE (PARAM_PREFETCH_MIN_INSN_TO_MEM_RATIO)
 #define MIN_NONDEBUG_INSN_UID \
   PARAM_VALUE (PARAM_MIN_NONDEBUG_INSN_UID)
+#define ALLOW_LOAD_DATA_RACES \
+  PARAM_VALUE (PARAM_ALLOW_LOAD_DATA_RACES)
+#define ALLOW_STORE_DATA_RACES \
+  PARAM_VALUE (PARAM_ALLOW_STORE_DATA_RACES)
+#define ALLOW_PACKED_LOAD_DATA_RACES \
+  PARAM_VALUE (PARAM_ALLOW_PACKED_LOAD_DATA_RACES)
+#define ALLOW_PACKED_STORE_DATA_RACES \
+  PARAM_VALUE (PARAM_ALLOW_PACKED_STORE_DATA_RACES)
+
 #endif /* ! GCC_PARAMS_H */
Index: testsuite/gcc.dg/memmodel/speculative-store.c
===
--- testsuite/gcc.dg/memmodel/speculative-store.c   (revision 170852)
+++ testsuite/gcc.dg/memmodel/speculative-store.c   (working copy)
@@ -1,14 +1,12 @@
 /* { dg-do link } */
-/* { dg-options "-O2" } */
+/* { dg-options "-O2 --param allow-store-data-races=0" } */
 /* { dg-final { memmodel-gdb-test } } */
 
-/* FIXME: I can't get this to fail.  */
-
 #include 
 #include "memmodel.h"
 
 /* This file tests that speculative store movement out of a loop doesn't 
-   happen.  This is disallowed when -fno-allow-store-data-races is on.  */
+   happen.  This is disallowed when --param allow-store-data-races is 0.  */
 
 int global = 100;
 
Index: testsuite/gcc.dg/memmodel/subfields.c
===
--- testsuite/gcc.dg/memmodel/subfields.c   (revision 170852)
+++ testsuite/gcc.dg/memmodel/subfields.c   (working copy)
@@ -1,9 +1,7 @@
 /* { dg-do link } */
-/* { dg-options "-O2" } */
+/* { dg-options "-O2 --param allow-packed-store-data-races=0" } */
 /* { dg-final { memmodel-gdb-test } } */
 
-/* FIXME: I can't get this to fail.  */
-
 #include 
 #include "memmodel.h"
 
Index: testsuite/gcc.dg/memmodel/global-hoist.c
===
--- testsuite/gcc.dg/memmodel/global-hoist.c(revision 170852)
+++ testsuite/gcc.dg/memmodel/global-hoist.c(working copy)
@@ -1,10 +1,10 @@
 /* { dg-do link } */
-/* { dg-options "-O2" } */
+/* { dg-options "-O2 --param allow-load-data-races=0" } */
 /* { dg-final { memmodel-gdb-test } } */
 
 /* Verify that a load of a global is not hoisted out of a loop.  This
can introduce a data race, and is dissallowed if
-   -fno-allow-load-data-races is enabled. */
+   --param allow-load-data-races is 0. */
 
 #include 
 #include 
Index: testsuite/gcc.dg/memmodel/d2.c
===
--- testsuite/gcc.dg/me

Re: ivopts improvement

[Tom de Vries]

On 03/14/2011 01:55 PM, Zdenek Dvorak wrote:
> Hi,
> 
 it is trying to allow for

 do
   {
 *p = '\0';
 i++; /* use_uses_inced_iv == true */
 p++; /* use_after_cand_inc == true */
 if (!(i < n))
   break;
   }
 while (1);

 and for

 do
   {
 *p = '\0';
 if (!(i < n))
   break;
 i++; /* use_uses_inced_iv == false */
 p++; /* use_after_cand_inc == false */
   }
 while (1);

 but not for

 do
   {
 *p = '\0';
 i++; /* use_uses_inced_iv == true */
 if (!(i < n))
   break;
 p++; /* use_after_cand_inc == false */
   }
 while (1);

 and not for

 do
   {
 *p = '\0';
 p++; /* use_after_cand_inc == true */
 if (!(i < n))
   break;
 i++; /* use_uses_inced_iv == false */
   }
 while (1);

 In the latter 2 cases, I cannot simply replace i < n with p < base + n.
>>>
>>> Why not (other than that the value to compare with varies in these cases, 
>>> but
>>> it always is "the value of p in the last iteration of the loop")?
>>
>> In the 2 latter cases, the value to compare with will be either base + n
>> + 1 or base + n - 1. The code does not handle these cases yet.
> 
> well, if not, then it certainly handles one of the first two cases incorrectly

The ivopts code for the first example is:

:
  p_5 = p_3(D) + i_4(D);
  D.2698_12 = p_3(D) + n_8(D);

:
  # p_1 = PHI 
  *p_1 = 0;
  p_7 = p_1 + 1;
  if (p_7 >= D.2698_12)
goto ;
  else
goto ;

:
  goto ;

:
  return;

and for the second example is:

:
  p_5 = p_3(D) + i_4(D);
  D.2704_13 = p_3(D) + n_6(D);

:
  # p_1 = PHI 
  *p_1 = 0;
  if (p_1 >= D.2704_13)
goto ;
  else
goto ;

:
  p_8 = p_1 + 1;
  goto ;

:
  return;

both seem correct to me.

> (since the use_uses_inced_iv test is meaningless).

To me it seems use_uses_inced_iv has meaning:
- it models something: it states whether the comparison is using
  the iv increment result or the iv phi result.
- it is used to detect cases were we would generate incorrect code.

>>> One more thing: what is fold_walk_def_plus for?
>>
>> It tries to fold a plus, and if not successful, finds ssa vars in
>> operands of the plus, substitutes the defining statements of ssa vars
>> for those ssa vars and retries folding.
> 
> Sorry for not being more clear; I meant, why is it used?
> 

In the following code

:
  p_5 = p_3(D) + i_4(D);

:
  # p_1 = PHI 
  # i_2 = PHI 
  *p_1 = 0;
  i_6 = i_2 + 1;
  p_7 = p_1 + 1;
  if (i_6 >= n_8(D))
goto ;
  else
goto ;

:
  goto ;

:
  return;


I'm trying to prove that p_5 == x + i_4 where x is an ssa_name. I can't
do that without going through the defining statement of p_5.

> Zdenek

Re: ivopts improvement

[Zdenek Dvorak]

Hi,

> > (since the use_uses_inced_iv test is meaningless).
> 
> To me it seems use_uses_inced_iv has meaning:
> - it models something: it states whether the comparison is using
>   the iv increment result or the iv phi result.

but that has nothing to do with the value of the iv.  For instance,
in the following:

a = phi (0, a')
b = phi (1, b')
c = phi (1, c')

a' = a + 1;
tmp = b;

compare (a'/tmp/c, something)

b' = tmp + 1;
c' = c + 1;

a', tmp and c are completely equivalent, yet your code for some reason claims
to handle c and the other two differently.

Zdenek

Re: [Patch][AVR]: Support tail calls

[Georg-Johann Lay]

Boyapati, Anitha schrieb:

> To be on same page, can you explain how gcc optimizes above case?

in

void bar0 (void);
int bar1 (int);

int foo (int x)
{
bar0();
return bar1 (x);
}

x must be saved somewhere. avr-gcc choses Y.
Compiled -Os -mmcu=atmega8 -fno-optimize-sibling-calls reads

foo:
push r28 ;
push r29 ;
.L__stack_usage = 2
movw r28,r24 ;  x, x
rcall bar0   ;
movw r24,r28 ; , x
rcall bar1   ;
pop r29  ;
pop r28  ;
ret

and -Os -mmcu=atmega8 -foptimize-sibling-calls

foo:
push r28 ;
push r29 ;
.L__stack_usage = 2
movw r28,r24 ;  x, x
rcall bar0   ;
movw r24,r28 ; , x
pop r29  ;
pop r28  ;
rjmp bar1;

> As I understand, in a tail-call optimization, bar1 can return to
> the caller of foo(). There can be different cases of handling this.
> But how is this handled in gcc after recognizing that foo() is a
> candidate for tail call?

gcc recognizes most cases where tail call optimization must not be
applied. But in some cases backend has to impose more restrictions,
this is what TARGET_FUNCTION_OK_FOR_SIBCALL is for. E.g. An ISR must
not tail-call an ordinary function because the epilogues must be
compatible bit ISR resp. non-ISR have incompatible epilogues.

gcc also evaluates standard insns "sibcall", "sibcall_value",
"sibcall_epilogue" which are analoga to "call", "call_value",
"epilogue", resp.

> Also, I have applied the patch, and used it for a small test case
> as below:
> 
> int bar1(int x) { x++; return x; }
> 
> int foo (int x) { return bar1 (x); }
> 
> int main() { volatile int i; return foo(i);
> 
> }
> 
> avr-gcc -S -foptimize-sibling-calls tail-call.c
> 
> 
> I find no difference in the code generated with and without tail
> call optimization. (I am assuming -foptimize-sibling-calls should
> turn on this). Let me know if I am doing something wrong.
> 
> Anitha

As with all other optimization options/passes, they are only applied
in the presence of optimization, i.e. with -O0 options like
-foptimize-sibling-calls have no effect. You will have to specify at
least -O1 to see effects.

Johann

[PATCH][i386] Implement ix86_emit_swdivsf more efficiently

[Richard Guenther]

This rewrites the iteration step of swdivsf to be more register
efficient (two registers instead of four, no load of a FP constant).
This matches how ICC emits the rcp sequence and causes no overall loss
of precision (Micha might still remember the exact details).  The patch is
fallout of the work trying to fix PR47989.

Bootstrapped and tested on x86_64-unknown-linux-gnu, ok for 4.7?

Thanks,
Richard.

2011-03-14  Richard Guenther  

* config/i386/i386.c (ix86_emit_swdivsf): Implement more
efficiently.

Index: trunk/gcc/config/i386/i386.c
===
--- trunk.orig/gcc/config/i386/i386.c   2011-03-09 11:52:21.0 +0100
+++ trunk/gcc/config/i386/i386.c2011-03-10 15:43:47.0 +0100
@@ -31747,38 +31747,38 @@ void ix86_emit_i387_log1p (rtx op0, rtx
 
 void ix86_emit_swdivsf (rtx res, rtx a, rtx b, enum machine_mode mode)
 {
-  rtx x0, x1, e0, e1, two;
+  rtx x0, x1, e0, e1;
 
   x0 = gen_reg_rtx (mode);
   e0 = gen_reg_rtx (mode);
   e1 = gen_reg_rtx (mode);
   x1 = gen_reg_rtx (mode);
 
-  two = CONST_DOUBLE_FROM_REAL_VALUE (dconst2, SFmode);
-
-  if (VECTOR_MODE_P (mode))
-two = ix86_build_const_vector (mode, true, two);
-
-  two = force_reg (mode, two);
-
-  /* a / b = a * rcp(b) * (2.0 - b * rcp(b)) */
+  /* a / b = a * ((rcp(b) + rcp(b)) - (b * rcp(b) * rcp (b))) */
 
   /* x0 = rcp(b) estimate */
   emit_insn (gen_rtx_SET (VOIDmode, x0,
  gen_rtx_UNSPEC (mode, gen_rtvec (1, b),
  UNSPEC_RCP)));
-  /* e0 = x0 * a */
+  /* e0 = x0 * b */
   emit_insn (gen_rtx_SET (VOIDmode, e0,
- gen_rtx_MULT (mode, x0, a)));
-  /* e1 = x0 * b */
-  emit_insn (gen_rtx_SET (VOIDmode, e1,
  gen_rtx_MULT (mode, x0, b)));
-  /* x1 = 2. - e1 */
+
+  /* e0 = x0 * e0 */
+  emit_insn (gen_rtx_SET (VOIDmode, e0,
+ gen_rtx_MULT (mode, x0, e0)));
+
+  /* e1 = x0 + x0 */
+  emit_insn (gen_rtx_SET (VOIDmode, e1,
+ gen_rtx_PLUS (mode, x0, x0)));
+
+  /* x1 = e1 - e0 */
   emit_insn (gen_rtx_SET (VOIDmode, x1,
- gen_rtx_MINUS (mode, two, e1)));
-  /* res = e0 * x1 */
+ gen_rtx_MINUS (mode, e1, e0)));
+
+  /* res = a * x1 */
   emit_insn (gen_rtx_SET (VOIDmode, res,
- gen_rtx_MULT (mode, e0, x1)));
+ gen_rtx_MULT (mode, a, x1)));
 }
 
 /* Output code to perform a Newton-Rhapson approximation of a

Re: fix for pr47837

[Xinliang David Li]

On Mon, Mar 14, 2011 at 6:16 AM, Diego Novillo  wrote:
> On Fri, Mar 11, 2011 at 14:32, Jeff Law  wrote:
>
>>> Regarding this particular patch, I hope it can be checked in to make
>>> the test clean. It is a simple enhancement to a wheel that is already
>>> there. It also serves as a case that can be referenced in the future
>>> when the more general mechanism is available.
>> Just to be clear, I'm not going to object to this patch; I don't have
>> the time right now to really look at it.
>>
>> I was merely raising the issue that we have a need to solve the larger
>> problem and that we need to be looking a the bigger picture.
>
> Agreed.  I'm not happy about the patch, but I won't object to it.
> It's clear, however, that we cannot keep adding hack on top of hack
> here.

I don't think I have added too many pattern handling (aka Hack) since
the predicate aware analysis was checked in -- this is actually the
first attempt to try to do predicate simplification.  Things like this
is a natural course of software evolution.

> David, will you be looking at creating a more general solution
> for 4.7?

I think it is a good area to explore, not necessarily by me though.

>
> Given the stage we are in, you will need OKs from our release managers for 
> 4.6.
>

Richard, if it is too late for 4.6, I can wait until stage-1 is reopened.

Thanks,

David

>
> Diego.
>

Re: fix for pr47837

[Richard Guenther]

On Mon, Mar 14, 2011 at 5:33 PM, Xinliang David Li  wrote:
> On Mon, Mar 14, 2011 at 6:16 AM, Diego Novillo  wrote:
>> On Fri, Mar 11, 2011 at 14:32, Jeff Law  wrote:
>>
 Regarding this particular patch, I hope it can be checked in to make
 the test clean. It is a simple enhancement to a wheel that is already
 there. It also serves as a case that can be referenced in the future
 when the more general mechanism is available.
>>> Just to be clear, I'm not going to object to this patch; I don't have
>>> the time right now to really look at it.
>>>
>>> I was merely raising the issue that we have a need to solve the larger
>>> problem and that we need to be looking a the bigger picture.
>>
>> Agreed.  I'm not happy about the patch, but I won't object to it.
>> It's clear, however, that we cannot keep adding hack on top of hack
>> here.
>
> I don't think I have added too many pattern handling (aka Hack) since
> the predicate aware analysis was checked in -- this is actually the
> first attempt to try to do predicate simplification.  Things like this
> is a natural course of software evolution.
>
>> David, will you be looking at creating a more general solution
>> for 4.7?
>
> I think it is a good area to explore, not necessarily by me though.
>
>>
>> Given the stage we are in, you will need OKs from our release managers for 
>> 4.6.
>>
>
> Richard, if it is too late for 4.6, I can wait until stage-1 is reopened.

Should happen soon.  So, yes, please wait for stage1 and then eventually
backport for 4.6.1.

Thanks,
Richard.

Re: [PATCH][ARM] Discourage use of NEON on Cortex-A8

[Richard Earnshaw]

On Sun, 2011-03-13 at 16:31 +, Andrew Stubbs wrote:
> This patch discourages the use of NEON for integer operations on ARM 
> Cortex-A8.
> 
> The problem is that transferring data from NEON/VFP registers to core 
> registers is prohibitively expensive on A8. This should not affect 
> Cortex-A9 in the same way.
> 
> This change gives a 6% increase in performance on SPEC2000 crafty, on an 
> imx51 board.
> 
> An older version of the patch has been used for some time in the 
> CodeSourcery and Linaro toolchains, so it's fairly well tested.
> 
> OK (for stage 1)?
> 
> Andrew

There's no denying numbers like that, so I'm going to approve this for
stage 1, but I'm far from convinced that this isn't papering over other
problems.

Did you look at REGISTER_MOVE_COST?  That code for ARM looks rather
crufty these days and should really be the place where the cost of
moving between the classes is expressed.  I also wonder whether IRA is
really taking these costs into account when doing preferencing.

Finally, alternatives from an insn are normally selected left-to-right
from those available in a pattern, all other things being equal.  So
really the A8-only alternative should come after the core registers
alternatives if its less preferable.

R.

[patch libcpp]: Improve handling of DOS-filenames and -paths

[Kai Tietz]

Hello,

this patch fixes some DOS-filename comparision and directory-separator checks.

Changelog libcpp

2011-03-14  Kai Tietz

* files.c (file_hash_eq): Use filename_cmp
instead of strcmp.
(nonexistent_file_hash_eq): Likewise.
(remap_filename): Likewise.
Handle absolute DOS-path,
(append_file_to_dir): Check for IS_DIR_SEPARATOR
instead of slash.
(read_name_map): Likewise.
* linemap.c (linemap_add): Use filename_cmp
instead of strcmp.
* mkdeps.c (apply_vpath): Use filename_ncmp
instead of strncmp.
(deps_restore): Use filename_cmp instead of
strcmp.
* init.c (read_original_directory): Use
IS_DIR_SEPARATOR instead of checking for slash.

Tested for x86_64-pc-linux-gnu and x86_64-w64-mingw32. Ok for apply?

Regards,
Kai
Index: gcc/libcpp/files.c
===
--- gcc.orig/libcpp/files.c 2011-03-14 17:28:34.106392100 +0100
+++ gcc/libcpp/files.c  2011-03-14 18:03:04.260379100 +0100
@@ -1155,7 +1155,7 @@ file_hash_eq (const void *p, const void
   else
 hname = entry->u.dir->name;
 
-  return strcmp (hname, fname) == 0;
+  return filename_cmp (hname, fname) == 0;
 }
 
 /* Compare entries in the nonexistent file hash table.  These are just
@@ -1163,7 +1163,7 @@ file_hash_eq (const void *p, const void
 static int
 nonexistent_file_hash_eq (const void *p, const void *q)
 {
-  return strcmp ((const char *) p, (const char *) q) == 0;
+  return filename_cmp ((const char *) p, (const char *) q) == 0;
 }
 
 /* Initialize everything in this source file.  */
@@ -1413,7 +1413,7 @@ append_file_to_dir (const char *fname, c
   flen = strlen (fname);
   path = XNEWVEC (char, dlen + 1 + flen + 1);
   memcpy (path, dir->name, dlen);
-  if (dlen && path[dlen - 1] != '/')
+  if (dlen && !IS_DIR_SEPARATOR (path[dlen - 1]))
 path[dlen++] = '/';
   memcpy (&path[dlen], fname, flen + 1);
 
@@ -1461,7 +1461,7 @@ read_name_map (cpp_dir *dir)
   len = dir->len;
   name = (char *) alloca (len + sizeof (FILE_NAME_MAP_FILE) + 1);
   memcpy (name, dir->name, len);
-  if (len && name[len - 1] != '/')
+  if (len && !IS_DIR_SEPARATOR (name[len - 1]))
 name[len++] = '/';
   strcpy (name + len, FILE_NAME_MAP_FILE);
   f = fopen (name, "r");
@@ -1532,10 +1532,18 @@ remap_filename (cpp_reader *pfile, _cpp_
read_name_map (dir);
 
   for (index = 0; dir->name_map[index]; index += 2)
-   if (!strcmp (dir->name_map[index], fname))
+   if (!filename_cmp (dir->name_map[index], fname))
return xstrdup (dir->name_map[index + 1]);
-
+  if (IS_ABSOLUTE_PATH (fname))
+   return NULL;
   p = strchr (fname, '/');
+#ifdef HAVE_DOS_BASED_FILE_SYSTEM
+  {
+   char *p2 = strchr (fname, '\\');
+   if (!p || (p > p2))
+ p = p2;
+  }
+#endif
   if (!p || p == fname)
return NULL;
 
Index: gcc/libcpp/line-map.c
===
--- gcc.orig/libcpp/line-map.c  2011-03-14 17:28:34.108392100 +0100
+++ gcc/libcpp/line-map.c   2011-03-14 18:03:04.274380900 +0100
@@ -138,7 +138,7 @@ linemap_add (struct line_maps *set, enum
   else
{
  from = INCLUDED_FROM (set, map - 1);
- error = to_file && strcmp (from->to_file, to_file);
+ error = to_file && filename_cmp (from->to_file, to_file);
}
 
   /* Depending upon whether we are handling preprocessed input or
Index: gcc/libcpp/mkdeps.c
===
--- gcc.orig/libcpp/mkdeps.c2011-03-14 17:28:34.114392100 +0100
+++ gcc/libcpp/mkdeps.c 2011-03-14 18:03:04.278881500 +0100
@@ -130,7 +130,7 @@ apply_vpath (struct deps *d, const char
   unsigned int i;
   for (i = 0; i < d->nvpaths; i++)
{
- if (!strncmp (d->vpathv[i], t, d->vpathlv[i]))
+ if (!filename_ncmp (d->vpathv[i], t, d->vpathlv[i]))
{
  const char *p = t + d->vpathlv[i];
  if (!IS_DIR_SEPARATOR (*p))
@@ -421,7 +421,7 @@ deps_restore (struct deps *deps, FILE *f
   buf[num_to_read] = '\0';
 
   /* Generate makefile dependencies from .pch if -nopch-deps.  */
-  if (self != NULL && strcmp (buf, self) != 0)
+  if (self != NULL && filename_cmp (buf, self) != 0)
 deps_add_dep (deps, buf);
 }
 
Index: gcc/libcpp/init.c
===
--- gcc.orig/libcpp/init.c  2011-03-14 17:28:34.107392100 +0100
+++ gcc/libcpp/init.c   2011-03-14 18:03:04.283882100 +0100
@@ -26,6 +26,7 @@ along with this program; see the file CO
 #include "internal.h"
 #include "mkdeps.h"
 #include "localedir.h"
+#include "filenames.h"
 
 static void init_library (void);
 static void mark_named_operators (cpp_reader *, int);
@@ -640,8 +641,8 @@ read_original_directory (cpp_reader *pfi
 
   if (token->type != CPP_STRING
   || ! (token

Re: PATCH: Enable __float128 in gcc.target/i386/builtin-copysign.c for 32bit

[Uros Bizjak]

On Sat, Mar 12, 2011 at 7:28 PM, H.J. Lu  wrote:
> Hi,
>
> __float128 has been supported on ia32 for a while.  This patch removes
> __LP64__ check.  OK for 4.7?
>
> Thanks.
>
> H.J.
> ---
> 2011-03-12  H.J. Lu  
>
>        * gcc.target/i386/builtin-copysign.c: Remove __LP64__ check.

OK.

Thanks,
Uros.

Re: [PATCH][i386] Implement ix86_emit_swdivsf more efficiently

[Uros Bizjak]

Hello!

> This rewrites the iteration step of swdivsf to be more register
> efficient (two registers instead of four, no load of a FP constant).
> This matches how ICC emits the rcp sequence and causes no overall loss
> of precision (Micha might still remember the exact details).  The patch is
> fallout of the work trying to fix PR47989.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, ok for 4.7?
>
> Thanks,
> Richard.
>
> 2011-03-14  Richard Guenther  
>
>   * config/i386/i386.c (ix86_emit_swdivsf): Implement more
>   efficiently.

OK for 4.7.

Thanks,
Uros.

[DOC PATCH] 4.6 branching changes

[Jakub Jelinek]

Hi!

I've committed these changes to reflect the creation of 4.6 branch.

--- c99status.html  6 Apr 2010 11:34:44 -   1.55
+++ c99status.html  14 Mar 2011 13:52:00 -  1.56
@@ -21,6 +21,7 @@ paragraph 6) do not count as library iss
 
 This page describes the C99 support in mainline GCC, not in any
 particular release.  Information is also available on C99 support in GCC 4.5, C99 support in GCC 4.5, C99 support in GCC 4.4, C99 support in GCC 4.3, 
--- index.html  7 Mar 2011 10:53:25 -   1.778
+++ index.html  14 Mar 2011 17:25:47 -  1.780
@@ -108,6 +108,23 @@ Any additions?  Don't be shy, send them 
 
 
 Current release series:
+  GCC 4.6.0 (changes)
+
+  Status:
+  
+  http://gcc.gnu.org/ml/gcc/2011-03/msg00176.html";>2011-03-14
+  
+  (regression fixes and docs only, RM approval required).
+  
+  http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=4.6&target_milestone=4.3.6&target_milestone=4.4.6&target_milestone=4.5.3&target_milestone=4.6.0&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&priority=P1&priority=P2&priority=P3&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=";>Serious
+  regressions.
+  http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=4.6&target_milestone=4.3.6&target_milestone=4.4.6&target_milestone=4.5.3&target_milestone=4.6.0&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=";>All
+  regressions.
+
+
+Previous release series:
   GCC 4.5.2
   (changes)
 
@@ -125,7 +142,7 @@ Any additions?  Don't be shy, send them 
   regressions.
 
 
-Previous release series:
+Older maintained release series:
   GCC 4.4.5
   (changes)
 
@@ -159,19 +176,19 @@ Any additions?  Don't be shy, send them 
  
 
 Active development:
-  GCC 4.6.0 (changes)
+  GCC 4.7.0 (changes)
 
   Status:
-  
-  http://gcc.gnu.org/ml/gcc/2011-03/msg00081.html";>2011-03-07
-  
-  (regression fixes and docs only).
+  
+  http://gcc.gnu.org/ml/gcc/2011-03/msg00178.html";>2011-03-14
+  
+  Stage 1, open for development.
   
   http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=4.6&target_milestone=4.3.6&target_milestone=4.4.6&target_milestone=4.5.3&target_milestone=4.6.0&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&priority=P1&priority=P2&priority=P3&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=";>Serious
+  
href="http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=4.7&target_milestone=4.3.6&target_milestone=4.4.6&target_milestone=4.5.3&target_milestone=4.6.0&target_milestone=4.7.0&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&priority=P1&priority=P2&priority=P3&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0

[4.6 PATCH] 4.6 branching changes

[Jakub Jelinek]

Hi!

I've committed following patch to 4.6 branch:

2011-03-14  Jakub Jelinek  

* doc/invoke.texi, doc/standards.texi: Refer to
gcc-4.6/c99status.html.

* DEV-PHASE: Mark "prerelease".

--- gcc/doc/standards.texi  (.../trunk) (revision 170924)
+++ gcc/doc/standards.texi  (.../branches/gcc-4_6-branch)   (revision 
170945)
@@ -1,4 +1,4 @@
-@c Copyright (C) 2000, 2001, 2002, 2004, 2006, 2007, 2008, 2010
+@c Copyright (C) 2000, 2001, 2002, 2004, 2006, 2007, 2008, 2010, 2011
 @c Free Software Foundation, Inc.
 @c This is part of the GCC manual.
 @c For copying conditions, see the file gcc.texi.
@@ -86,7 +86,7 @@ as @dfn{AMD1}; the amended standard is s
 A new edition of the ISO C standard was published in 1999 as ISO/IEC
 9899:1999, and is commonly known as @dfn{C99}.  GCC has incomplete
 support for this standard version; see
-@uref{http://gcc.gnu.org/c99status.html} for details.  To select this
+@uref{http://gcc.gnu.org/gcc-4.6/c99status.html} for details.  To select this
 standard, use @option{-std=c99} or @option{-std=iso9899:1999}.  (While in
 development, drafts of this standard version were referred to as
 @dfn{C9X}.)
--- gcc/doc/invoke.texi (.../trunk) (revision 170924)
+++ gcc/doc/invoke.texi (.../branches/gcc-4_6-branch)   (revision 170945)
@@ -1529,7 +1529,7 @@ ISO C90 as modified in amendment 1.
 @itemx iso9899:1999
 @itemx iso9899:199x
 ISO C99.  Note that this standard is not yet fully supported; see
-@w{@uref{http://gcc.gnu.org/c99status.html}} for more information.  The
+@w{@uref{http://gcc.gnu.org/gcc-4.6/c99status.html}} for more information.  The
 names @samp{c9x} and @samp{iso9899:199x} are deprecated.
 
 @item c1x
--- gcc/DEV-PHASE   (.../trunk) (revision 170924)
+++ gcc/DEV-PHASE   (.../branches/gcc-4_6-branch)   (revision 170945)
@@ -1 +1 @@
-experimental
+prerelease

Jakub

[PATCH] Trunk is now 4.7

[Jakub Jelinek]

Hi!

2011-03-14  Jakub Jelinek  

* BASE-VER: Change to 4.7.0.

--- gcc/BASE-VER(revision 170924)
+++ gcc/BASE-VER(revision 170945)
@@ -1 +1 @@
-4.6.0
+4.7.0

Jakub

Re: Add a testcase for reload PR 47166

[Jakub Jelinek]

On Mon, Mar 14, 2011 at 12:34:16PM +0100, Richard Guenther wrote:
> On Mon, Mar 14, 2011 at 11:25 AM, Richard Sandiford
>  wrote:
> > A reload patch that I posted in January:
> >
> >    http://gcc.gnu.org/ml/gcc-patches/2011-01/msg00548.html
> >
> > turned out to be related to PR 47166, so Bernd committed a combined fix:
> >
> >    
> > http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01620.htmlhttp://gcc.gnu.org/ml/gcc-patches/2011-01/msg01620.html
> >
> > Is it OK to commit the testcase from the first patch to 4.5 and 4.6?
> 
> Sure.

Please commit also to 4.6 branch, you've just committed it to 4.5 and 4.7.

> > gcc/testsuite/
> >        PR rtl-optimization/47166
> >        * gcc.c-torture/execute/postmod-1.c: New test.

Jakub

Re: [PATCH][ARM] Discourage use of NEON on Cortex-A8

[Bernd Schmidt]

On 03/14/2011 06:10 PM, Richard Earnshaw wrote:
> 
> On Sun, 2011-03-13 at 16:31 +, Andrew Stubbs wrote:
>> This patch discourages the use of NEON for integer operations on ARM 
>> Cortex-A8.
>>
>> The problem is that transferring data from NEON/VFP registers to core 
>> registers is prohibitively expensive on A8. This should not affect 
>> Cortex-A9 in the same way.
>>
>> This change gives a 6% increase in performance on SPEC2000 crafty, on an 
>> imx51 board.
>>
>> An older version of the patch has been used for some time in the 
>> CodeSourcery and Linaro toolchains, so it's fairly well tested.
>>
>> OK (for stage 1)?
>>
>> Andrew
> 
> There's no denying numbers like that, so I'm going to approve this for
> stage 1, but I'm far from convinced that this isn't papering over other
> problems.

Oh, I agree. I seem to recall we tried using REGISTER_MOVE_COST, but it
didn't help.
Ideally, we'd fix this in the register allocator and in lower-subreg,
but I believe that would be a significantly larger project. You'd have
to detect that if a certain pseudo is allocated to a NEON register, this
would cause an expensive register move (because it's used in an insn
that only allows GENERAL_REGS), and then recursively every other
operation that involves this pseudo also needs to avoid NEON registers
for the same reason. Doing this in lower-subreg would give the best
results (splitting pseudos that shouldn't go into NEON regs and leaving
the others alone), but it would also work to do it in IRA.


Bernd

Re: PATCH: PR other/48007: Unwind library doesn't work with UNITS_PER_WORD > sizeof (void *)

[H.J. Lu]

On Sun, Mar 6, 2011 at 4:15 PM, H.J. Lu  wrote:
> On Sun, Mar 6, 2011 at 3:40 PM, H.J. Lu  wrote:
>> On Sun, Mar 6, 2011 at 3:23 PM, Richard Guenther
>>  wrote:
>>> On Sun, Mar 6, 2011 at 10:28 PM, H.J. Lu  wrote:
 On Sun, Mar 6, 2011 at 1:15 PM, Andrew Pinski  wrote:
> On Sun, Mar 6, 2011 at 9:18 AM, H.J. Lu  wrote:
>> Hi,
>>
>> We shouldn't save call frame hard registers as "void *".  This patch
>> changes the unwind library to save call frame hard registers as
>> _Unwind_Word.  OK for 4.7?
>
> I think this will break the ABI for the MIPS N32 ABI.  Not to mention
> the MIPS N32 ABI works fine with the unwinding part this way.  Does
> someone use the unwinding library to look at the registers in previous
> stack frames?

 It may be psABI/implementation specific.  X32 glibc force unwind calls
 _Unwind_SetGRValue to get a 64bit register value.
>>>
>>> So fix it on that side?
>>>
>>
>> How? One function in question is
>>
>> /* Overwrite the saved value for register INDEX in CONTEXT with VAL.  */
>>
>> static inline void
>> _Unwind_SetGRValue (struct _Unwind_Context *context, int index,
>>                    _Unwind_Word val)
>>
>>
>> Are you saying it shouldn't be called if UNITS_PER_WORD > sizeof (void *)?
>>
>
> FWIW, the type of GR is _Unwind_Word, not void *.  They may not
> have the same size.  Why does the DWARF unwind library use
> void * to store GR? Can a target have an option to save a _Unwind_Word
> value in _Unwind_Word, instead of void *?
>

From what I can tell, _Unwind_Context is internal to the unwind library
and only one copy unwind library can be used in a process. I don't
think changing _Unwind_Context will impact binary compatibility.

Is my patch OK for 4.7?

Thanks.


-- 
H.J.

Re: Patch: suppress -Woverlength-strings in asm()

[Tom Tromey]

>> 2011-02-02  Tom Tromey  
>> 
>> * c-parser.c (c_parser_asm_string_literal): Clear
>> warn_overlength_strings.
>> 
>> 2011-02-02  Tom Tromey  
>> 
>> * gcc.dg/Woverlength-strings-pedantic-c90-asm.c: New file.
>> * gcc.dg/Woverlength-strings-pedantic-c89-asm.c: New file.
>> * gcc.dg/Woverlength-strings-pedantic-c99-asm.c: New file.

Joseph> OK.

Now that Stage 1 is open, I am checking this in.

I think this is minor enough that it need not be synchronized with any
other commit.

Tom

Re: RFA: let __extension__ suppress overlength string warning

[Tom Tromey]

>> 2011-01-18  Tom Tromey  
>> 
>> * c-parser.c (disable_extension_diagnostics): Save
>> warn_overlength_strings.
>> (restore_extension_diagnostics): Restore warn_overlength_strings.
>> 
>> 2011-01-18  Tom Tromey  
>> 
>> * gcc.dg/Woverlength-strings-pedantic-c89-ext.c: New file.
>> * gcc.dg/Woverlength-strings-pedantic-c90-ext.c: New file.
>> * gcc.dg/Woverlength-strings-pedantic-c99-ext.c: New file.

Joseph> OK.

Now that Stage 1 is open, I am checking this in.

I think this is minor enough that it need not be synchronized with any
other commit.

Tom

Tom

Re: [PATCH][ARM] Discourage use of NEON on Cortex-A8

[Andrew Stubbs]

On 14/03/11 17:10, Richard Earnshaw wrote:

Finally, alternatives from an insn are normally selected left-to-right
from those available in a pattern, all other things being equal.  So
really the A8-only alternative should come after the core registers
alternatives if its less preferable.


OK, I can do that, but I'm not exactly sure how far to the right you 
want them moved?


Do you want the onlya8 alternatives moved the the right of all 
alternatives without a '?' modifier (so, changing only iordi3_neon and 
anddi3_neon)? Or do you mean moving it all the way to the right hand end?


Or something completely different?

Andrew

Re: [PATCH][ARM] Discourage use of NEON on Cortex-A8

[Richard Earnshaw]

On Mon, 2011-03-14 at 17:55 +, Andrew Stubbs wrote:
> On 14/03/11 17:10, Richard Earnshaw wrote:
> > Finally, alternatives from an insn are normally selected left-to-right
> > from those available in a pattern, all other things being equal.  So
> > really the A8-only alternative should come after the core registers
> > alternatives if its less preferable.
> 
> OK, I can do that, but I'm not exactly sure how far to the right you 
> want them moved?
> 
> Do you want the onlya8 alternatives moved the the right of all 
> alternatives without a '?' modifier (so, changing only iordi3_neon and 
> anddi3_neon)? Or do you mean moving it all the way to the right hand end?
> 
> Or something completely different?
> 
> Andrew
> 
So taking the current adddi3 pattern we have alternatives (in order of
preference): not-a8, only-a8, core-regs, core-regs.

I think the order should be: not-a8, core-regs, core-regs, only-a8.

R.

Re: Patch: add systemtap-style marker to _Unwind_DebugHook

[Tom Tromey]

Roland> That test would work.  (That macro is not defined at all in
Roland> earlier versions.)

Tom> Here is an updated version.

Tom> 2011-01-14  Tom Tromey  
Tom>* unwind-dw2.c: Include sys/sdt.h if it exists.
Tom>(_Unwind_DebugHook): Use STAP_PROBE2.
Tom>* config.in, configure: Rebuild.
Tom>* configure.ac: Check for sys/sdt.h.

Now that Stage 1 is open, I am checking this in.

Tom

[v3] libstdc++/48114

[Paolo Carlini]

Hi,

a couple of issues with the C++0x , very easy to fix but very 
serious from the user point of view: due to a stupid thinko of mine we 
have been computing the binomial distribution incorrectly for p > 0.5 + 
we had the TR1 != C++0x definition for the geometric_distribution.


Both fixes applied to mainline and 4_6-branch, only the first one to 
4_5-branch.


Paolo.

///
2011-03-14  Andrey Zholos  

PR libstdc++/48114
* include/bits/random.h (geometric_distribution): Correct formula
in comment, per C++0x.
(geometric_distribution<>::param_type::param_type(double)): Fix check.
(geometric_distribution<>::param_type::_M_initialize):
Store log(1 - p).
* include/bits/random.tcc (geometric_distribution<>::operator()):
Fix computation.
(binomial_distribution<>::operator()): Likewise.
Index: include/bits/random.tcc
===
--- include/bits/random.tcc (revision 170943)
+++ include/bits/random.tcc (working copy)
@@ -1025,7 +1025,7 @@
 
double __cand;
do
- __cand = std::ceil(std::log(__aurng()) / __param._M_log_p);
+ __cand = std::floor(std::log(__aurng()) / __param._M_log_1_p);
while (__cand >= __thr);
 
return result_type(__cand + __naf);
@@ -1434,7 +1434,7 @@
   {
result_type __ret;
const _IntType __t = __param.t();
-   const _IntType __p = __param.p();
+   const double __p = __param.p();
const double __p12 = __p <= 0.5 ? __p : 1.0 - __p;
__detail::_Adaptor<_UniformRandomNumberGenerator, double>
  __aurng(__urng);
Index: include/bits/random.h
===
--- include/bits/random.h   (revision 170943)
+++ include/bits/random.h   (working copy)
@@ -1,6 +1,6 @@
 // random number generation -*- C++ -*-
 
-// Copyright (C) 2009, 2010 Free Software Foundation, Inc.
+// Copyright (C) 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
@@ -3589,7 +3589,7 @@
* @brief A discrete geometric random number distribution.
*
* The formula for the geometric probability density function is
-   * @f$p(i|p) = (1 - p)p^{i-1}@f$ where @f$p@f$ is the parameter of the
+   * @f$p(i|p) = p(1 - p)^{i}@f$ where @f$p@f$ is the parameter of the
* distribution.
*/
   template
@@ -3611,8 +3611,8 @@
param_type(double __p = 0.5)
: _M_p(__p)
{
- _GLIBCXX_DEBUG_ASSERT((_M_p >= 0.0)
-&& (_M_p <= 1.0));
+ _GLIBCXX_DEBUG_ASSERT((_M_p > 0.0)
+&& (_M_p < 1.0));
  _M_initialize();
}
 
@@ -3627,11 +3627,11 @@
   private:
void
_M_initialize()
-   { _M_log_p = std::log(_M_p); }
+   { _M_log_1_p = std::log(1.0 - _M_p); }
 
double _M_p;
 
-   double _M_log_p;
+   double _M_log_1_p;
   };
 
   // constructors and member function

Re: [RFC PATCH, i386]: Vectorize calls to floor, ceil, trunc and rint functions.

[Uros Bizjak]

On Sun, Feb 27, 2011 at 2:45 PM, Uros Bizjak  wrote:

> Attached [RFC] patch vectorizes calls to floor, ceil, trunc and rint
> (and their float variants) functions using roundps/roundpd SSE4.1
> instruction.
>
> 2011-02-27  Uros Bizjak  
>
>        * config/i386/i386.md (ROUND_FLOOR): New constant.
>        (ROUND_CEIL): Ditto.
>        (ROUND_TRUNC): Ditto.
>        (ROUND_MXCSR): Ditto.
>        (ROUND_NO_EXC): Ditto.
>        (rint2): Use new defines instead of numerical constant.
>        (floor2): Ditto.
>        (ceil2): Ditto.
>        (btrunc2): Ditto.
>        * config/i386/i386-builtin-types.def: Define ROUND function type
>        aliases.
>        * config/i386/i386.c (enum ix86_builtins): Add
>        IX86_BUILTIN_{FLOOR,CEIL,TRUNC,RINT}{PS,PD}{,256} defines.
>        (struct builtin_description): Add
>        __builtin_ia32_{floor,ceil,trunc,rint}{pd,ps}{,256} descriptions.
>        (ix86_expand_sse_round): New static function.
>        (ix86_expand_args_builtin): Call ix86_expand_sse_round for ROUND
>        function types.
>        (ix86_builtin_vectorized_function): Handle
>        BUILT_IN_{FLOOR,CEIL,TRUNC,RINT}{,F} builtins.
>
> Patch was bootstrapped and regression tested on x86_64-pc-linux-gnu
> (--with-fpmath=avx). Currently, it does not include test cases, but it
> is RFC at this gcc development stage anyway.

I have added testcases and committed slightly changed patch.

2011-03-14  Uros Bizjak  

* gcc.target/i386/sse4_1-floor-vec.c: New test.
* gcc.target/i386/sse4_1-ceil-vec.c: Ditto.
* gcc.target/i386/sse4_1-trunc-vec.c: Ditto.
* gcc-target/i386/sse4_1-rint-vec.c: Ditto.
* gcc.target/i386/sse4_1-floorf-vec.c: Ditto.
* gcc.target/i386/sse4_1-ceilf-vec.c: Ditto.
* gcc.target/i386/sse4_1-truncf-vec.c: Ditto.
* gcc.target/i386/sse4_1-rintf-vec.c: Ditto.
* gcc.target/i386/avx-floor-vec.c: Ditto.
* gcc.target/i386/avx-ceil-vec.c: Ditto.
* gcc.target/i386/avx-trunc-vec.c: Ditto.
* gcc.target/i386/avx-rint-vec.c: Ditto.
* gcc.target/i386/avx-floorf-vec.c: Ditto.
* gcc.target/i386/avx-ceilf-vec.c: Ditto.
* gcc.target/i386/avx-truncf-vec.c: Ditto.
* gcc.target/i386/avx-rintf-vec.c: Ditto.

Bootstrapped and regression tested on x86_64-pc-linux-gnu {,-m32} AVX target.

Uros.
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 170945)
+++ config/i386/i386.md (working copy)
@@ -272,6 +272,15 @@
   UNSPECV_SPLIT_STACK_RETURN
 ])
 
+;; Constants to represent rounding modes in the ROUND instruction
+(define_constants
+  [(ROUND_FLOOR0x1)
+   (ROUND_CEIL 0x2)
+   (ROUND_TRUNC0x3)
+   (ROUND_MXCSR0x4)
+   (ROUND_NO_EXC   0x8)
+  ])
+
 ;; Constants to represent pcomtrue/pcomfalse variants
 (define_constants
   [(PCOM_FALSE 0)
@@ -14573,7 +14582,7 @@
FAIL;
   if (TARGET_ROUND)
emit_insn (gen_sse4_1_round2
-  (operands[0], operands[1], GEN_INT (0x04)));
+  (operands[0], operands[1], GEN_INT (ROUND_MXCSR)));
   else
ix86_expand_rint (operand0, operand1);
 }
@@ -14819,7 +14828,7 @@
FAIL;
   if (TARGET_ROUND)
emit_insn (gen_sse4_1_round2
-  (operands[0], operands[1], GEN_INT (0x01)));
+  (operands[0], operands[1], GEN_INT (ROUND_FLOOR)));
   else if (TARGET_64BIT || (mode != DFmode))
ix86_expand_floorceil (operand0, operand1, true);
   else
@@ -15074,7 +15083,7 @@
 {
   if (TARGET_ROUND)
emit_insn (gen_sse4_1_round2
-  (operands[0], operands[1], GEN_INT (0x02)));
+  (operands[0], operands[1], GEN_INT (ROUND_CEIL)));
   else if (optimize_insn_for_size_p ())
FAIL;
   else if (TARGET_64BIT || (mode != DFmode))
@@ -15329,7 +15338,7 @@
 {
   if (TARGET_ROUND)
emit_insn (gen_sse4_1_round2
-  (operands[0], operands[1], GEN_INT (0x03)));
+  (operands[0], operands[1], GEN_INT (ROUND_TRUNC)));
   else if (optimize_insn_for_size_p ())
FAIL;
   else if (TARGET_64BIT || (mode != DFmode))
Index: config/i386/i386-builtin-types.def
===
--- config/i386/i386-builtin-types.def  (revision 170945)
+++ config/i386/i386-builtin-types.def  (working copy)
@@ -377,6 +377,11 @@ DEF_FUNCTION_TYPE (V16QI, V16QI, INT, V1
 
 DEF_FUNCTION_TYPE (V8QI, QI, QI, QI, QI, QI, QI, QI, QI)
 
+DEF_FUNCTION_TYPE_ALIAS (V2DF_FTYPE_V2DF, ROUND)
+DEF_FUNCTION_TYPE_ALIAS (V4DF_FTYPE_V4DF, ROUND)
+DEF_FUNCTION_TYPE_ALIAS (V4SF_FTYPE_V4SF, ROUND)
+DEF_FUNCTION_TYPE_ALIAS (V8SF_FTYPE_V8SF, ROUND)
+
 DEF_FUNCTION_TYPE_ALIAS (INT_FTYPE_V2DF_V2DF, PTEST)
 DEF_FUNCTION_TYPE_ALIAS (INT_FTYPE_V2DI_V2DI, PTEST)
 DEF_FUNCT

Re: [build, lto] Only accept -fuse-linker-plugin if linker supports -plugin (PR lto/46944)

[Rainer Orth]

Richard Guenther  writes:

>> > Can you update your patch with the tri-state solution?
>> 
>> Sure if the solution is deemed acceptable.  There isn't much point in
>> following that route if you see problems up front.
>
> If that solution avoids 3) then yes, I'm fine with going that route.
> Both 1) and 2) are very desirable anyway.

Here's the updated patch, which also incorporates Paolo's suggestion.
Bootstrapped without regressions on i386-pc-solaris2.11 with Sun as/ld
and GNU as/ld 2.21.  I couldn't really test the middle ground (gold 2.20
with limited plugin support) since even mainline gold doesn't work for
me yet.  What I've done is rebuild xgcc after manually changing
HAVE_LTO_PLUGIN to 1 in auto-host.h.  After I realized that I needed to
remove the existing specs file, that variant worked as expected in that
-plugin is only passed to the linker with an explicit
-fuse-linker-plugin.

I had to make a last-minute change when I realized that two other uses
of #ifdef HAVE_LTO_PLUGIN needed to be updated since that macro is now
always defined.  I'm running fresh bootstraps to make sure nothing broke
that way.

Ok for mainline if that passes, and perhaps also the 4.6 branch?

Thanks.
Rainer


2011-02-05  Rainer Orth  

PR lto/46944
* configure.ac (gcc_cv_gld_major_version, gcc_cv_gld_minor):
Handle in-tree gold.
(ld_vers): Extract binutils version for gold.
(gcc_cv_ld_hidden): Handle gold here.
(gcc_cv_lto_plugin): Determine level of linker plugin support.
* configure: Regenerate.
* config.in: Regenerate.
* gcc.c: Only use LTO plugin if HAVE_LTO_PLUGIN > 0, reject
-fuse-linker-plugin otherwise.
(LINK_PLUGIN_SPEC): Define.  Extract from LINK_COMMAND_SPEC.
(LINK_COMMAND_SPEC): Use it.
(main): Only look for LTOPLUGINSONAME if HAVE_LTO_PLUGIN > 0.

diff -r 71f0a0dc3338 gcc/configure.ac
--- a/gcc/configure.ac  Mon Mar 14 19:57:51 2011 +0100
+++ b/gcc/configure.ac  Mon Mar 14 19:59:05 2011 +0100
@@ -1967,7 +1967,8 @@
 esac 
 
 AC_MSG_CHECKING(what linker to use)
-if test "$gcc_cv_ld" = ../ld/ld-new$build_exeext; then
+if test "$gcc_cv_ld" = ../ld/ld-new$build_exeext \
+   || test "$gcc_cv_ld" = ../gold/ld-new$build_exeext; then
# Single tree build which includes ld.  We want to prefer it
# over whatever linker top-level may have detected, since
# we'll use what we're building after installation anyway.
@@ -1978,6 +1979,8 @@
|| grep 'EMUL = .*linux' ../ld/Makefile \
|| grep 'EMUL = .*lynx' ../ld/Makefile) > /dev/null; then
  in_tree_ld_is_elf=yes
+   elif test "$ld_is_gold" = yes; then
+ in_tree_ld_is_elf=yes
fi
for f in $gcc_cv_ld_bfd_srcdir/configure 
$gcc_cv_ld_gld_srcdir/configure $gcc_cv_ld_gld_srcdir/configure.in 
$gcc_cv_ld_gld_srcdir/Makefile.in
do
@@ -2192,11 +2195,23 @@
 changequote(,)dnl
 if test $in_tree_ld != yes ; then
   ld_ver=`$gcc_cv_ld --version 2>/dev/null | sed 1q`
-  if test x"$ld_is_gold" = xyes; then
-gcc_cv_ld_hidden=yes
-  elif echo "$ld_ver" | grep GNU > /dev/null; then
-ld_vers=`echo $ld_ver | sed -n \
-   -e 's,^.*[   ]\([0-9][0-9]*\.[0-9][0-9]*.*\)$,\1,p'`
+  if echo "$ld_ver" | grep GNU > /dev/null; then
+if test x"$ld_is_gold" = xyes; then
+  # GNU gold --version looks like this:
+  #
+  # GNU gold (GNU Binutils 2.21.51.20110225) 1.11
+  #
+  # We extract the binutils version which is more familiar and specific
+  # than the gold version.
+  ld_vers=`echo $ld_ver | sed -n \
+ -e 's,^[^)]*[  ]\([0-9][0-9]*\.[0-9][0-9]*[^)]*\)) .*$,\1,p'`
+else
+  # GNU ld --version looks like this:
+  #
+  # GNU ld (GNU Binutils) 2.21.51.20110225
+  ld_vers=`echo $ld_ver | sed -n \
+ -e 's,^.*[ ]\([0-9][0-9]*\.[0-9][0-9]*.*\)$,\1,p'`
+fi
 ld_date=`echo $ld_ver | sed -n 
's,^.*\([2-9][0-9][0-9][0-9]\)[-]*\([01][0-9]\)[-]*\([0-3][0-9]\).*$,\1\2\3,p'`
 ld_vers_major=`expr "$ld_vers" : '\([0-9]*\)'`
 ld_vers_minor=`expr "$ld_vers" : '[0-9]*\.\([0-9]*\)'`
@@ -2235,7 +2250,9 @@
   fi
 else
   gcc_cv_ld_hidden=yes
-  if echo "$ld_ver" | grep GNU > /dev/null; then
+  if test x"$ld_is_gold" = xyes; then
+:
+  elif echo "$ld_ver" | grep GNU > /dev/null; then
 if test 0"$ld_date" -lt 20020404; then
   if test -n "$ld_date"; then
# If there was date string, but was earlier than 2002-04-04, fail
@@ -3173,23 +3190,27 @@
 fi
 
 AC_MSG_CHECKING(linker plugin support)
-gcc_cv_lto_plugin=no
+gcc_cv_lto_plugin=0
 if test -f liblto_plugin.la; then
   if test $in_tree_ld = yes -a x"$ORIGINAL_PLUGIN_LD_FOR_TARGET=" = 
x"$gcc_cv_ld"; then
-if test x"$ld_is_gold" = xyes; then
-  gcc_cv_lto_plugin=yes
-elif test "$gcc_cv_gld_major_version" -eq 2 -a "$gcc_cv_gld_minor_version" 
-ge 21 -o "$gcc_cv_gld_major_version" -gt 2; then \
-  gcc_cv_lto_plugin=yes
+if test "$gcc_cv_gld_major_

Re: PATCH: PR target/46770: Use .init_array/.fini_array sections

[H.J. Lu]

On Thu, Jan 27, 2011 at 2:40 AM, Richard Guenther
 wrote:
> On Thu, Jan 27, 2011 at 12:12 AM, H.J. Lu  wrote:
>> On Tue, Dec 14, 2010 at 05:20:48PM -0800, H.J. Lu wrote:
>>> This patch uses .init_array/.fini_array sections instead of
>>> .ctors/.dtors sections if mixing .init_array/.fini_array and
>>> .ctors/.dtors sections with init_priority works.
>>>
>>> It removes .ctors/.ctors sections from executables and DSOes, which will
>>> remove one function call at startup time from each executable and DSO.
>>> It should reduce image size and improve system startup time.
>>>
>>> If a platform with a working .init_array/.fini_array support needs a
>>> different .init_array/.fini_array implementation, it can set
>>> use_initfini_array to no.
>>>
>>> Since .init_array/.fini_array is a target feature. --enable-initfini-array
>>> is default to no unless the native run-time test is passed.
>>>
>>> To pass the native run-time test, a linker with SORT_BY_INIT_PRIORITY
>>> support is required.  The binutils patch is available at
>>>
>>> http://sourceware.org/ml/binutils/2010-12/msg00466.html
>>
>> Linker patch has been checked in.
>>
>>>
>>> This patch passed 32bit/64bit regression test on Linux/x86-64.  Any
>>> comments?
>>>
>>
>> This updated patch fixes build on Linux/ia64 and should work on others.
>> Any comments?
>
> Yes.  This is stage1 material.
>

Here is the updated patch.  OK for trunk?

Thanks.


-- 
H.J.

2011-03-14  H.J. Lu  

PR target/46770
* acinclude.m4 (gcc_AC_INITFINI_ARRAY): Removed.

* config.gcc (use_initfini_array): New variable.
Use initfini-array.o if supported.

* crtstuff.c: Don't generate .ctors nor .dtors sections if
NO_CTORS_DTORS_SECTIONS is defined.

* configure.ac: Remove gcc_AC_INITFINI_ARRAY.  Add
--enable-initfini-array and check if .init_array can be used with
.ctors.

* configure: Regenerated.

* config/initfini-array.c: New.
* config/initfini-array.h: Likewise.
* config/t-initfini-array: Likewise.

* config/arm/arm.c (arm_asm_init_sections): Call
elf_initfini_array_init_sections if NO_CTORS_DTORS_SECTIONS
is defined.
* config/avr/avr.c (avr_asm_init_sections): Likewise.
* config/ia64/ia64.c (ia64_asm_init_sections): Likewise.
* config/mep/mep.c (mep_asm_init_sections): Likewise.
* config/microblaze/microblaze.c (microblaze_elf_asm_init_sections):
Likewise.
* config/rs6000/rs6000.c (rs6000_elf_asm_init_sections): Likewise.
* config/stormy16/stormy16.c (xstormy16_asm_init_sections):
Likewise.
* config/v850/v850.c (v850_asm_init_sections): Likewise.
This patch uses .init_array/.fini_array sections instead of
.ctors/.dtors sections if mixing .init_array/.fini_array and
.ctors/.dtors sections with init_priority works.

It removes .ctors/.ctors sections from executables and DSOes, which will
remove one function call at startup time from each executable and DSO.
It should reduce image size and improve system startup time. 

If a platform with a working .init_array/.fini_array support needs a
different .init_array/.fini_array implementation, it can set
use_initfini_array to no.

Since .init_array/.fini_array is a target feature. --enable-initfini-array
is default to no unless the native run-time test is passed.

To pass the native run-time test, a linker with SORT_BY_INIT_PRIORITY
support is required.  The binutils patch is available at

http://sourceware.org/ml/binutils/2010-12/msg00466.html

This patch passed 32bit/64bit regression test on Linux/x86-64.

Thanks.

H.J.
---
2011-03-14  H.J. Lu  

PR target/46770
* acinclude.m4 (gcc_AC_INITFINI_ARRAY): Removed.

* config.gcc (use_initfini_array): New variable.
Use initfini-array.o if supported.

* crtstuff.c: Don't generate .ctors nor .dtors sections if
NO_CTORS_DTORS_SECTIONS is defined.

* configure.ac: Remove gcc_AC_INITFINI_ARRAY.  Add
--enable-initfini-array and check if .init_array can be used with
.ctors.

* configure: Regenerated.

* config/initfini-array.c: New.
* config/initfini-array.h: Likewise.
* config/t-initfini-array: Likewise.

* config/arm/arm.c (arm_asm_init_sections): Call
elf_initfini_array_init_sections if NO_CTORS_DTORS_SECTIONS
is defined.
* config/avr/avr.c (avr_asm_init_sections): Likewise.
* config/ia64/ia64.c (ia64_asm_init_sections): Likewise.
* config/mep/mep.c (mep_asm_init_sections): Likewise.
* config/microblaze/microblaze.c (microblaze_elf_asm_init_sections):
Likewise.
* config/rs6000/rs6000.c (rs6000_elf_asm_init_sections): Likewise.
* config/stormy16/stormy16.c (xstormy16_asm_init_sections):
Likewise.
* config/v850/v850.c (v850_asm_init_sections): Likewise.

diff --git a/gcc/acinclude.m4 b/gcc/acinclude.m4
i

[v3] Replace docs.sun.com URLs by their OTN equivalents

[Rainer Orth]

In their infinite wisdom, Oracle has moved all contents from
docs.sun.com to the Oracle Technical Network without putting specific
redirects in place, thus invalidating more than a decade of links in a
single stroke.  Oh well ;-(

The following patch deals with the outfall.  I've decided to remove the
links from gcc/config/sol2.c, leaving only the citations in place.  In
the libstdc++ manual, OTOH, I've updated the URLs.  I've no idea how
stable they are going to be, tough: in about a week, the first link has
already been invalidated by inserting a /html somewhere in the middle.
So much for competent webmasters.

Unfortunately, I've again lost the battle against the DocBook/XSL tools:
even with the exact same version of docbook-xsl (1.75.2), I couldn't
properly regenerate doc/html/manual/abi.html.  I will never be able to
understand how people are able to cope with this mess.

When this patch is checked in, could someone with the right magic please
regenerate that file for me?  Thanks.

Ok for mainline and perhaps the 4.6 branch?

Rainer


2011-03-06  Rainer Orth  

gcc:
* config/sol2.c (solaris_assemble_visibility): Remove obsolete
URLs.

libstdc++-v3:
* doc/xml/manual/abi.xml: Replace docs.sun.com URLs by their OTN
equivalents.
* doc/html/manual/abi.html: Regenerate.

diff -r 2cb06ad64348 gcc/config/sol2.c
--- a/gcc/config/sol2.c Sun Mar 06 00:52:15 2011 +0100
+++ b/gcc/config/sol2.c Sun Mar 06 00:59:45 2011 +0100
@@ -1,5 +1,5 @@
 /* General Solaris system support.
-   Copyright (C) 2004, 2005 , 2007, 2010 Free Software Foundation, Inc.
+   Copyright (C) 2004, 2005 , 2007, 2010, 2011 Free Software Foundation, Inc.
Contributed by CodeSourcery, LLC.
 
 This file is part of GCC.
@@ -136,10 +136,8 @@
  STV_SINGLETON, and STV_ELIMINATE.
 
  See Linker and Libraries Guide, Ch. 2, Link-Editor, Defining
- Additional Symbols with a mapfile,
- http://docs.sun.com/app/docs/doc/819-0690/gdzmc?a=view
- and Ch. 7, Object-File Format, Symbol Table Section,
- http://docs.sun.com/app/docs/doc/819-0690/chapter6-79797?a=view  */
+ Additional Symbols, and Ch. 7, Object-File Format, Symbol Table
+ Section.  */
 
   static const char * const visibility_types[] = {
 NULL, "symbolic", "hidden", "hidden"
diff -r 2cb06ad64348 libstdc++-v3/doc/xml/manual/abi.xml
--- a/libstdc++-v3/doc/xml/manual/abi.xml   Sun Mar 06 00:52:15 2011 +0100
+++ b/libstdc++-v3/doc/xml/manual/abi.xml   Sun Mar 06 00:59:45 2011 +0100
@@ -1127,7 +1127,7 @@
   
 
   
-http://www.w3.org/1999/xlink"; 
xlink:href="http://docs.sun.com/app/docs/doc/819-0690"; class="uri">
+http://www.w3.org/1999/xlink"; 
xlink:href="http://download.oracle.com/docs/cd/E19963-01/html/819-0690/index.html";
 class="uri">
   
   
Linker and Libraries Guide (document 819-0690)
@@ -1136,7 +1136,7 @@
 
 
   
-http://www.w3.org/1999/xlink"; 
xlink:href="http://docs.sun.com/app/docs/doc/819-3689"; class="uri">
+http://www.w3.org/1999/xlink"; 
xlink:href="http://download.oracle.com/docs/cd/E19422-01/819-3689/index.html"; 
class="uri">
 
 
   Sun Studio 11: C++ Migration Guide (document 819-3689)


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

PATCH: PR target/48084: [x32] internal compiler error: in copy_to_mode_reg, at explow.c:630

[H.J. Lu]

Hi Uros,

Is this patch:

http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00679.html

OK for trunk?


Thanks.


H.J.

Re: [v3] Replace docs.sun.com URLs by their OTN equivalents

[Benjamin Kosnik]

>   libstdc++-v3:
>   * doc/xml/manual/abi.xml: Replace docs.sun.com URLs by their
> OTN equivalents.

This is ok.

-benjamin

Patch ping

[Jakub Jelinek]

Hi!

http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01749.html
  - PR middle-end/47917, snprintf folding

Jakub

Re: [v3] Replace docs.sun.com URLs by their OTN equivalents

[Rainer Orth]

Benjamin Kosnik  writes:

>>  libstdc++-v3:
>>  * doc/xml/manual/abi.xml: Replace docs.sun.com URLs by their
>> OTN equivalents.
>
> This is ok.

Thanks.  Jakub, ok for 4.6, too?

Unless I'm mistaken, even doc patches require RM approval now?

Rainer

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

Re: Patch ping

[Diego Novillo]

On Mon, Mar 14, 2011 at 16:19, Jakub Jelinek  wrote:
> Hi!
>
> http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01749.html
>  - PR middle-end/47917, snprintf folding

OK.


Diego.

Re: FYI: update libstdc++ pretty-printers

[Tom Tromey]

> "Tom" == Tom Tromey  writes:

Tom> Doug Evans recently added some features to gdb to make it possible for
Tom> the user to individually enable or disable pretty-printers.  In order
Tom> for this to work, the printers must conform to a certain extended
Tom> protocol.

Tom> I happened to notice that I forgot to actually check the 'enabled'
Tom> flag -- so disabling did not actually work with the previous patch.

Tom> Here's an updated patch.

Now that GCC is in Stage 1, I am checking this in.

Tom

Re: [v3] Replace docs.sun.com URLs by their OTN equivalents

[Jakub Jelinek]

On Mon, Mar 14, 2011 at 09:26:56PM +0100, Rainer Orth wrote:
> Benjamin Kosnik  writes:
> >>libstdc++-v3:
> >>* doc/xml/manual/abi.xml: Replace docs.sun.com URLs by their
> >> OTN equivalents.
> >
> > This is ok.
> 
> Thanks.  Jakub, ok for 4.6, too?

Yeah.

Jakub

Re: [pph] Refactor pth/pph code out of cp/parser.c

[Diego Novillo]

On Tue, Jan 4, 2011 at 11:11, Diego Novillo  wrote:
> On Thu, Dec 2, 2010 at 18:28, Jason Merrill  wrote:
>> On 12/02/2010 04:55 PM, Diego Novillo wrote:
>>>
>>> Jason, would it be OK if I ported cp/parser.h to mainline now?
>>> It does not change anything in terms of functionality but it
>>> would simplify future merges from trunk into the branch.
>>
>> Yeah, OK.
>
> [ I thought this had gone out before, but it got stuck in my mailbox.
> Sending again. ]
>
> All cosmetic/factoring changes:
>
> - Moved structure definitions to cp/parser.h
> - Tweaked token dumping routines.
> - Changed token buffer to be a VEC and simplify the main lexing loop.
>
> OK for mainline?  Tested on x86_64.
>
>
> Thanks.
>
>
> 2010-12-28  Diego Novillo  
>
>        * cp/Make-lang.in (CXX_PARSER_H): New.
>        (cp/parser.o): Add dependency on CXX_PARSER_H.
>        Add dependency on tree-pretty-print.h
>        (cp/cp-lang.o): Add dependency on CXX_PARSER_H.
>        * cp/cp-lang.c: Include parser.h.
>        * cp/parser.c: Include parser.h.
>        (struct cp_token): Add bitfield purged_p.
>        Update all users.
>        Move to parser.h.
>        (CPP_PURGED): Remove.  Update all users.
>        (struct cp_lexer): Change field buffer to be a VEC of cp_token.
>        Remove field buffer_length.
>        Update all users.
>        Move to parser.h.
>        (struct tree_check): Move to parser.h.
>        (cp_token_position): Likewise.
>        (struct cp_token_cache): Likewise.
>        (CPP_KEYWORD): Likewise.
>        (CPP_TEMPLATE_ID): Likewise.
>        (CPP_NESTED_NAME_SPECIFIER): Likewise.
>        (N_CP_TTYPES): Likewise.
>        (enum cp_parser_status_kind): Likewise.
>        (struct cp_parser_context): Likewise.
>        (struct cp_default_arg_entry_d): Likewise.
>        (struct cp_unparsed_functions_entry_d): Likewise.
>        (struct cp_parser): Likewise.
>        (cp_lexer_dump_tokens): New.
>        (cp_lexer_debug_tokens): New.
>        (cp_lexer_finished_p): New.
>        (cp_lexer_alloc): Factor out of cp_lexer_new_main.
>        (cp_lexer_new_main): Re-write main lexing loop to push
>        tokens into the new VEC buffer.
>        (cp_lexer_print_token): Improve printing of CPP_NUMBER tokens.
>        Do not abort if the token type is not recognized, just print
>        its code.
>        * cp/parser.h: New file.
>        * cp/config-lang.in (gtfiles): Add cp/parser.h.
>

Jason, Dodji,

Now that we are in stage 1, I am planning to commit this to trunk
soonish.  Would this cause any conflicts with any branch you're
planning to merge?


Diego.

Re: RFC: add a testsuite for libstdc++ pretty-printers

[Tom Tromey]

Tom> * testsuite/libstdc++-pp/simple.cc: New file.
Tom> * testsuite/lib/gdb-test.exp: New file.
Tom> * testsuite/libstdc++-pp/pp.exp: New file.

Benjamin> feel free to spell out prettyprinters instead of using pp, if you want
Benjamin> to make it very obvious what is going on in this directory.

Benjamin> we really strive for clarity given that this testsuite is so large

Tom> No problem, I will do that.

I updated my patch for this.

These new tests require a very new gdb in order to fully pass.  In
particular these tests pointed out some buglets that are only fixed in
CVS, not in any release.


Trying to dynamically adjust the tests for the gdb version looks like a
pain.

Maybe I could change the tests to check the gdb version and xfail the
tests for gdb < 7.3.  Would that be ok?

Or I could leave it as-is, but I assume that nobody wants to see new
FAILs.

Tom

Re: [v3] Replace docs.sun.com URLs by their OTN equivalents

[Rainer Orth]

Jakub Jelinek  writes:

> On Mon, Mar 14, 2011 at 09:26:56PM +0100, Rainer Orth wrote:
>> Benjamin Kosnik  writes:
>> >>   libstdc++-v3:
>> >>   * doc/xml/manual/abi.xml: Replace docs.sun.com URLs by their
>> >> OTN equivalents.
>> >
>> > This is ok.
>> 
>> Thanks.  Jakub, ok for 4.6, too?
>
> Yeah.

Installed on both.  Benjamin, perhaps you could regenerate abi.html so
the ChangeLog doesn't lie?

Thanks.
Rainer

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

Re: RFC: add a testsuite for libstdc++ pretty-printers

[Jonathan Wakely]

On 14 March 2011 20:33, Tom Tromey wrote:
> Tom> * testsuite/libstdc++-pp/simple.cc: New file.
> Tom> * testsuite/lib/gdb-test.exp: New file.
> Tom> * testsuite/libstdc++-pp/pp.exp: New file.
>
> Benjamin> feel free to spell out prettyprinters instead of using pp, if you 
> want
> Benjamin> to make it very obvious what is going on in this directory.
>
> Benjamin> we really strive for clarity given that this testsuite is so large
>
> Tom> No problem, I will do that.
>
> I updated my patch for this.
>
> These new tests require a very new gdb in order to fully pass.  In
> particular these tests pointed out some buglets that are only fixed in
> CVS, not in any release.
>
>
> Trying to dynamically adjust the tests for the gdb version looks like a
> pain.
>
> Maybe I could change the tests to check the gdb version and xfail the
> tests for gdb < 7.3.  Would that be ok?

That works for me, currently noone can test the printers, so if we get
to a point where people with a new enough gdb can test them that's a
huge improvement.

> Or I could leave it as-is, but I assume that nobody wants to see new
> FAILs.

Not really :-)

Re: [v3] Replace docs.sun.com URLs by their OTN equivalents

[Jonathan Wakely]

On 14 March 2011 20:37, Rainer Orth wrote:
> Jakub Jelinek  writes:
>
>> On Mon, Mar 14, 2011 at 09:26:56PM +0100, Rainer Orth wrote:
>>> Benjamin Kosnik  writes:
>>> >>   libstdc++-v3:
>>> >>   * doc/xml/manual/abi.xml: Replace docs.sun.com URLs by their
>>> >> OTN equivalents.
>>> >
>>> > This is ok.
>>>
>>> Thanks.  Jakub, ok for 4.6, too?
>>
>> Yeah.
>
> Installed on both.  Benjamin, perhaps you could regenerate abi.html so
> the ChangeLog doesn't lie?

I can do that later, if Benjamin doesn't beat me to it (I just need to
check out a 4.6 branch)

I don't think we can regenerate a single html file, because running
'make doc-html' changes loads of indices and cross-reference URLs, so
I always just regenerate the entire doc/html directory and check it
all in.

[PATCH, committed] Refix 48053, do not abort in loading 0 into VSX register under 32-bit

[Michael Meissner]

After the fix for 48053 was installed, we discovered that if reload wanted to
load a 0 into a VSX register, it would fail on 32-bit.  This is due to the fact
that a define_split was trying to break the load into 2 separate GPR registers,
but in this case there is only a single VSX register.

I bootstrapped the compiler with the patch and ran make check with no
regressions before committing the change.

2011-03-14  Michael Meissner  

* config/rs6000/rs6000.md (movdi split for 32-bit): Don't split up
64-bit constants being loaded into registers other than GPRs such
as loading 0 into a VSX register.

Index: gcc/config/rs6000/rs6000.md
===
--- gcc/config/rs6000/rs6000.md (revision 170943)
+++ gcc/config/rs6000/rs6000.md (working copy)
@@ -10071,7 +10071,8 @@ (define_insn "*movdi_internal32"
 (define_split
   [(set (match_operand:DI 0 "gpc_reg_operand" "")
(match_operand:DI 1 "const_int_operand" ""))]
-  "! TARGET_POWERPC64 && reload_completed"
+  "! TARGET_POWERPC64 && reload_completed
+   && gpr_or_gpr_p (operands[0], operands[1])"
   [(set (match_dup 2) (match_dup 4))
(set (match_dup 3) (match_dup 1))]
   "


-- 
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

[patch gcc c++ c-family java fortan lto]: Fix DOS-filesystem issues

[Kai Tietz]

Hello,

This patch addresses some general issues occuring for DOS-based
filesystems. In some cases it might be better to replace the strrchr
by lbasename, but I did this initial patch more mechanical. Of special
interest is the code-change in gcov.c's function make_gcov_file_name.
Most of the code is dead from Oct 2010. I modified it in a way that it
has intended behavior.
The cp/lex.c interface_strcmp() part I used filename_cmp for character
comparision. Sadly there is no character comparision routine for
filenames. So it might be an option here to implement directly within
this option the file-system dependent code. For cleaness I avoid this
for now.

Changelog c-family/

2011-03-14  Kai Tietz

* c-ada-spec.c (compare_comment): Use filename_cmp
instead of strcmp for filename.


Changelog fortran/

2011-03-14  Kai Tietz

* scanner.c (preprocessor_line): Use filename_cmp
instead of strcmp.

Changelog gcc/

2011-03-14  Kai Tietz

* collect2.c (write_c_file_stat): Handle backslash
as right-hand directory separator.
(resolve_lib_name): Use IS_DIR_SEPARATOR instead of
checking just for slash.
* coverage.c (coverage_init): Use IS_ABSOLUTE_PATH
instead of checking for trailing slash.
* gcc.c (record_temp_file): Use filename_cmp instead
of strcmp.
(do_spec_1): Likewise.
(replace_outfile_spec_function): Likewise.
(is_directory): Use filename_ncmp instead of strncmp.
(print_multilib_info): Likewise.
* gcov.c (find_source): Use filename_cmp instead
instead of strcmp.
(make_gcov_file_name): Fix order of slash/backslash
checks.
* incpath.c (DIRS_EQ): Use filename_cmp instead of strcmp.
(add_standard_paths): Likewise.
* mips-tfile.c (saber_stop): Handle backslash.
* prefix.c (update_path): Use filename_ncmp instead of
strncmp.
* profile.c (output_location): Use filename_cmp instead
of strcmp.
* read-md.c (handle_toplevel_file): Handle backslash.
* tlink.c (frob_extension):  Likewise.
* tree-cfg.c (same_line_p): Use filename_cmp instead of
strcmp.
* tree-dump.c (dequeue_and_dump): Handle backslash.
* tree.c (get_file_function_name): Likewise.
* gengtype.c (read_input_list): Likewise.
(get_file_realbasename): Likewise.
(get_output_file_with_visibility): Use filename_cmp
instead of strcmp.

ChangeLog java/

2011-03-14  Kai Tietz

* jcf-parse.c (java_read_sourcefilenames): Use filename_cmp
instead of strcmp.
(set_source_filename): Likewise.
* win32-host.c (jcf_open_exact_case): Likewise.

ChangeLog lto/

2011-03-14  Kai Tietz

* lto.c (lto_resolution_read): Use filename_cmp instead
of strcmp.
(lto_read_section_data): Likewise.


ChangeLog cp/

2011-03-14  Kai Tietz

* lex.c (interface_strcmp): Handle dos-paths.
(handle_pragma_implementation): Use filename_cmp instead of
strcmp.
(in_main_input_context): Likewise.

Tested for x86_64-pc-linux-gnu, i686-pc-cygwin, and
x86_64-w64-mingw32. Ok for apply?

Regards,
Kai
Index: gcc/gcc/c-family/c-ada-spec.c
===
--- gcc.orig/gcc/c-family/c-ada-spec.c  2011-03-14 18:45:20.566392100 +0100
+++ gcc/gcc/c-family/c-ada-spec.c   2011-03-14 20:22:19.023299300 +0100
@@ -559,7 +559,8 @@ compare_comment (const void *lp, const v
   const cpp_comment *rhs = (const cpp_comment *) rp;
 
   if (LOCATION_FILE (lhs->sloc) != LOCATION_FILE (rhs->sloc))
-return strcmp (LOCATION_FILE (lhs->sloc), LOCATION_FILE (rhs->sloc));
+return filename_cmp (LOCATION_FILE (lhs->sloc),
+LOCATION_FILE (rhs->sloc));
 
   if (LOCATION_LINE (lhs->sloc) != LOCATION_LINE (rhs->sloc))
 return LOCATION_LINE (lhs->sloc) - LOCATION_LINE (rhs->sloc);
Index: gcc/gcc/collect2.c
===
--- gcc.orig/gcc/collect2.c 2011-03-14 18:45:20.567392100 +0100
+++ gcc/gcc/collect2.c  2011-03-14 18:45:52.479501600 +0100
@@ -30,6 +30,7 @@ along with GCC; see the file COPYING3.
 #include "system.h"
 #include "coretypes.h"
 #include "tm.h"
+#include "filenames.h"
 
 /* TARGET_64BIT may be defined to use driver specific functionality. */
 #undef TARGET_64BIT
@@ -2315,6 +2316,13 @@ write_c_file_stat (FILE *stream, const c
 
   /* Figure out name of output_file, stripping off .so version.  */
   p = strrchr (output_file, '/');
+#ifdef HAVE_DOS_BASED_FILE_SYSTEM
+  {
+char *p2 = strrchr (output_file, '\\');
+if (!p || (p2 && p2 > p))
+  p = p2;
+  }
+#endif
   if (p == 0)
 p = output_file;
   else
@@ -3192,10 +3200,10 @@ resolve_lib_name (const char *name)
   for (; list; list = list->next)
{
  /* The following lines are needed because path_prefix list
-may cont

Re: [PATCH][ARM] Fix RVCT interoperation issue

[Ramana Radhakrishnan]

On 11/03/11 17:21, Andrew Stubbs wrote:

On 09/03/11 16:12, Ramana Radhakrishnan wrote:

On Fri, 2011-03-04 at 11:23 +, Andrew Stubbs wrote:

The attached patch, submitted on behalf of Dan Jacobowitz, fixes an
unwind bug when using RealView and libgcc.

It's an old patch that has been in CodeSourcery and Linaro toolchains
for sometime, but somehow escaped being posted here.


I would like to see some context around this patch before accepting or
rejecting this, maybe a testcase (agreed that this is harder) or a
description of the problem this patch is attempting to fix.


A testcase would be difficult. GCC won't produce anything that will
exercise this code. We'd have to cook something up in hand-coded
assembler, or maybe import something from RVCT - I don't know.

However, the logic can easily be compared with the ARM EHABI document,
section 9.2:

http://infocenter.arm.com/help/topic/com.arm.doc.ihi0038a/IHI0038A_ehabi.pdf


The key sentences are:

"If the high bit is set in the word containing N, then the type_info
list is followed by a prel31 landing pad offset (with bit 31 clear)
to be entered in the event that no type matches the thrown type. High
bit clear in the N word signifies that implicitly the no match case
should result in a call to __cxa_call_unexpected. When the high bit
clear format is used, object producers must emit an R_ARM_NONE
relocation to __cxa_call_unexpected to indicate the dependency to the
linker."


This is OK for trunk.

cheers
Ramana

[Ping] [PR19351, C++] Fix heap overflow in operator new[]

[Florian Weimer]

* Florian Weimer:

> I have run "make check-c++" with no new failures on x86_64-gnu-linux
> twice, with the operator new[] check enabled and disabled; there were
> no new failures.  If the check is disabled, trunk and patch produce
> identical assembler code for the test case.
>
> I still need some guidance where to put the test case.  There don't
> seem to be any direct tests for operator new[] funcionality.
>
> 2011-02-21  Florian Weimer  
>
>   * c.opt (foperator-new-overflow-check): New.
>
> 2011-02-21  Florian Weimer  
>
>   PR c++/19351
>
>   * init.c (maybe_build_size_mult_saturated, build_new_size_expr): Add.
>   (build_new_1): Use these new functions in size calculations.
>
>   * call.c (build_operator_new_call): Add size_with_cookie argument.
>   * cp-tree.h (build_operator_new_call): Likewise.

Sorry, but: ping?

Re: RFC: add a testsuite for libstdc++ pretty-printers

[Benjamin Kosnik]

> Trying to dynamically adjust the tests for the gdb version looks like
> a pain.
> 
> Maybe I could change the tests to check the gdb version and xfail the
> tests for gdb < 7.3.  Would that be ok?

Yeah.
 
> Or I could leave it as-is, but I assume that nobody wants to see new
> FAILs.

Right. Unsupported makes more sense.

-benjamin

Re: RFC: add a testsuite for libstdc++ pretty-printers

[Mike Stump]

On Mar 14, 2011, at 1:33 PM, Tom Tromey wrote:
> These new tests require a very new gdb in order to fully pass.  In
> particular these tests pointed out some buglets that are only fixed in
> CVS, not in any release.
> 
> 
> Trying to dynamically adjust the tests for the gdb version looks like a
> pain.
> 
> Maybe I could change the tests to check the gdb version and xfail the
> tests for gdb < 7.3.  Would that be ok?

Almost sounds more like unsupported.  I'd just have a dynamic gdb check that 
tests a single feature and then gate all the others on it.  If you test one of 
the last features to go in, you can then have them all turn off for the 
released gdbs, and when the new gdb is released, then they all just pop on.  
For hard core developers (those that have gdb trunk installed and do gcc trunk 
development) , they all pop on when they do an update/update install.

Also, this is better than merely checking gdb versions, as someone could add 
support for the printers to their version of gdb (or gdb clone), and all the 
testcases would pop on, once they get the first one working.

That said, the above is just a comment.

Re: [patch gcc c++ c-family java fortan lto]: Fix DOS-filesystem issues

[Pedro Alves]

On Monday 14 March 2011 21:19:52, Kai Tietz wrote:
> @@ -1572,6 +1579,12 @@ get_file_realbasename (const input_file
>  {
>const char *f = get_input_file_name (inpf);
>const char *lastslash = strrchr (f, '/');
> +#ifdef HAVE_DOS_BASED_FILE_SYSTEM
> +  const char *lastslash2 = strrchr (f, '\\');
> +
> +  if (!lastslash || (lastslash2 && lastslash2 > lastslash))
> +lastslash = lastslash2;
> +#endif
>  
>return (lastslash != NULL) ? lastslash + 1 : f;

All of this is just

 return lbasename (get_input_file_name (inpf));

There are other similar cases in the patch.

-- 
Pedro Alves

Re: PR debug/47510

[Dodji Seketeli]

Tom Tromey  writes:

> After a lot of discussion on irc, we came up with another idea: extend
> this patch to add DW_AT_linkage_name == 't' to the anonymous
> structure.  This makes the DWARF remain a faithful representation of
> the C++, but also makes it simple for debuginfo readers to understand
> what is going on.  In particular I think it will make the gdb side of
> this tractable.

I have updated the patch to make add the DW_AT_linkage_name to the
anonymous type.

Tested on x86_64-unknown-linux-gnus against trunk and 4.6.  I think this
is material for 4.7 that we can backport to 4.6 after its release.

-- 
Dodji

>From 5cc08083834604525a11e4e4b6de830734520f6e Mon Sep 17 00:00:00 2001
From: Dodji Seketeli 
Date: Fri, 28 Jan 2011 11:53:49 +0100
Subject: [PATCH] PR debug/47510

PR debug/47510
* gcc/dwarf2out.c (strip_naming_typedef): Factorize out of ...
(lookup_type_die_strip_naming_typedef): ... here.
(get_context_die): Use it.
(gen_typedef_die): Add a DW_AT_{MIPS}_linkage_name attribute to
the anonymous struct named by the naming typedef.
* gcc/testsuite/g++.dg/debug/dwarf2/typedef6.C: New test.
---
 gcc/dwarf2out.c  |   36 +
 gcc/testsuite/g++.dg/debug/dwarf2/typedef6.C |   30 +
 2 files changed, 60 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/debug/dwarf2/typedef6.C

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index dfe1086..cf935d0 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -6346,6 +6346,7 @@ static void remove_child_TAG (dw_die_ref, enum dwarf_tag);
 static void add_child_die (dw_die_ref, dw_die_ref);
 static dw_die_ref new_die (enum dwarf_tag, dw_die_ref, tree);
 static dw_die_ref lookup_type_die (tree);
+static dw_die_ref strip_naming_typedef (tree, dw_die_ref);
 static dw_die_ref lookup_type_die_strip_naming_typedef (tree);
 static void equate_type_number_to_die (tree, dw_die_ref);
 static hashval_t decl_die_table_hash (const void *);
@@ -8120,6 +8121,22 @@ lookup_type_die (tree type)
   return TYPE_SYMTAB_DIE (type);
 }
 
+/* Given a TYPE_DIE representing the type TYPE, if TYPE is an
+   anonymous type named by the typedef TYPE_DIE, return the DIE of the
+   anonymous type instead the one of the naming typedef.  */
+
+static inline dw_die_ref
+strip_naming_typedef (tree type, dw_die_ref type_die)
+{
+  if (type
+  && TREE_CODE (type) == RECORD_TYPE
+  && type_die
+  && type_die->die_tag == DW_TAG_typedef
+  && is_naming_typedef_decl (TYPE_NAME (type)))
+type_die = get_AT_ref (type_die, DW_AT_type);
+  return type_die;
+}
+
 /* Like lookup_type_die, but if type is an anonymous type named by a
typedef[1], return the DIE of the anonymous type instead the one of
the naming typedef.  This is because in gen_typedef_die, we did
@@ -8134,11 +8151,7 @@ static inline dw_die_ref
 lookup_type_die_strip_naming_typedef (tree type)
 {
   dw_die_ref die = lookup_type_die (type);
-  if (TREE_CODE (type) == RECORD_TYPE
-  && die->die_tag == DW_TAG_typedef
-  && is_naming_typedef_decl (TYPE_NAME (type)))
-die = get_AT_ref (die, DW_AT_type);
-  return die;
+  return strip_naming_typedef (type, die);
 }
 
 /* Equate a DIE to a given type specifier.  */
@@ -20350,6 +20363,14 @@ gen_typedef_die (tree decl, dw_die_ref context_die)
 anonymous struct DIE.  */
  if (!TREE_ASM_WRITTEN (type))
gen_tagged_type_die (type, context_die, DINFO_USAGE_DIR_USE);
+
+ /* This is a GNU Extension.  We are adding a
+DW_AT_linkage_name attribute to the DIE of the
+anonymous struct TYPE.  The value of that attribute
+is the name of the typedef decl naming the anonymous
+struct.  This greatly eases the work of consumers of
+this debug info.  */
+ add_linkage_attr (lookup_type_die (type), decl);
}
}
 
@@ -20830,7 +20851,10 @@ get_context_die (tree context)
 {
   /* Find die that represents this context.  */
   if (TYPE_P (context))
-   return force_type_die (TYPE_MAIN_VARIANT (context));
+   {
+ context = TYPE_MAIN_VARIANT (context);
+ return strip_naming_typedef (context, force_type_die (context));
+   }
   else
return force_decl_die (context);
 }
diff --git a/gcc/testsuite/g++.dg/debug/dwarf2/typedef6.C 
b/gcc/testsuite/g++.dg/debug/dwarf2/typedef6.C
new file mode 100644
index 000..8896446
--- /dev/null
+++ b/gcc/testsuite/g++.dg/debug/dwarf2/typedef6.C
@@ -0,0 +1,30 @@
+// Origin PR debug/
+// { dg-options "-g -dA" }
+
+class C {
+public:
+  C() {}
+  ~C() {}
+};
+typedef struct {
+  C m;
+} t;
+typedef t s;
+s v;
+
+/*
+  We want to check that we have a DIE describing the typedef t like this:
+
+   .uleb128 0xc# (DIE (0xb8) DW_TAG_typedef)
+   .ascii "t\0"# DW_AT_name
+ 

Re: [pph] Refactor pth/pph code out of cp/parser.c

[Jason Merrill]

On 03/14/2011 04:33 PM, Diego Novillo wrote:

Now that we are in stage 1, I am planning to commit this to trunk
soonish.  Would this cause any conflicts with any branch you're
planning to merge?


Nope.

Jason

[google] Skip g++.dg/rtti/repo1.C (issue4290043)

[Diego Novillo]

The use of --sysroot conflicts with this test because it's not passed
to COLLECT_GCC_OPTIONS when using -frepo.  Since we don't use -frepo,
this patch skips the test.

Tested on x86_64/{-m32,-m64}.  Committed to google/integration.



testsuite/ChangeLog.google-integration

2011-03-14  Diego Novillo  

* g++.dg/rtti/repo1.C: Skip.

Google ref 39481.

Index: testsuite/g++.dg/rtti/repo1.C
===
--- testsuite/g++.dg/rtti/repo1.C   (revision 170776)
+++ testsuite/g++.dg/rtti/repo1.C   (working copy)
@@ -2,6 +2,7 @@
 // { dg-options "-frepo" }
 // { dg-require-host-local "" }
 // { dg-skip-if "dkms are not final links" { vxworks_kernel } }
+// { dg-skip-if "-frepo not supported with --sysroot (as it is not passed to 
COLLECT_GCC_OPTIONS" { *-*-linux* } { "*" } { "" } }
 
 #include 
 template

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

[google] Do not run gcc.dg/cproj-fails-with-broken-glibc.c (issue4281048)

[Diego Novillo]

We are using an older version of glibc.  I'm marking this test as
compile-only in google/integration for now.

Tested on x86_64/{-m32,-m64}.  Committed to google/integration.


2011-03-14  Diego Novillo  

* gcc.dg/cproj-fails-with-broken-glibc.c: Just compile.

Index: testsuite/gcc.dg/cproj-fails-with-broken-glibc.c
===
--- testsuite/gcc.dg/cproj-fails-with-broken-glibc.c(revision 170776)
+++ testsuite/gcc.dg/cproj-fails-with-broken-glibc.c(working copy)
@@ -7,7 +7,8 @@
 
Origin: Kaveh R. Ghazi,  April 20, 2010.  */
 
-/* { dg-do run } */
+/* FIXME google - Change to dg-run after upgrading glibc.  */
+/* { dg-do compile } */
 /* { dg-options "-fno-builtin-cproj" } */
 /* { dg-add-options c99_runtime } */
 /* { dg-require-effective-target c99_runtime } */

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

[patch, fortran] Function call optimization

[Thomas Koenig]

Hello world,

the attached patch is a front-end optimization which replaces multiple 
calls to a function with identical argument lists with an assignment to 
a temporary variable, and then uses that variable in the original 
expression.


AFAIK, this is permitted by the Fortran standard because such functions 
have side effects, the program is illegal.


OK for trunk, now that it has reopened?

Thomas

2010-03-14  Thomas Koenig  

PR fortran/22572
* frontend_passes (expr_array):  New static variable.
(expr_size):  Likewise.
(expr_count):  Likewise.
(current_code):  Likewise.
(current_ns):  Likewise.
(gfc_run_passes):  Allocate and free space for expressions.
(compare_functions):  New function.
(cfe_expr):  New function.
(create_var):  New function.
(cfc_expr_0):  New function.
(cfe_code):  New function.
(optimize_namespace):  Invoke gfc_code_walker with cfe_code
and cfe_expr_0.

2010-03-14  Thomas Koenig  

PR fortran/22572
* gfortran.dg/function_optimize_1.f90:  New test.
! { dg-do compile }
! { dg-options "-O -fdump-tree-original" }
program main
  implicit none
  real, dimension(2,2) :: a, b, c, d
  character(60) :: line
  real, external :: ext_func
  real :: x
  data a /2., 3., 5., 7./
  data b /11., 13., 17., 23./
  write (unit=line, fmt='(4F7.2)') matmul(a,b) + matmul(a,b)
  d = sin(a) + cos(a) + sin(a) + cos(a)
  x = ext_func(a) + 23 + ext_func(a)
end program main
! { dg-final { scan-tree-dump-times "matmul_r4" 1 "original" } }
! { dg-final { scan-tree-dump-times "__builtin_sinf" 1 "original" } }
! { dg-final { scan-tree-dump-times "__builtin_cosf" 1 "original" } }
! { dg-final { scan-tree-dump-times "ext_func" 1 "original" } }
! { dg-final { cleanup-tree-dump "original" } }
Index: frontend-passes.c
===
--- frontend-passes.c	(Revision 170960)
+++ frontend-passes.c	(Arbeitskopie)
@@ -40,6 +40,21 @@ static bool optimize_trim (gfc_expr *);
 
 static int count_arglist;
 
+/* Pointer to an array of gfc_expr ** we operate on, plus its size
+   and counter.  */
+
+static gfc_expr ***expr_array;
+static int expr_size, expr_count;
+
+/* Pointer to the gfc_code we currently work on - to be able to insert
+   a statement before.  */
+
+static gfc_code **current_code;
+
+/* The namespace we are currently dealing with.  */
+
+gfc_namespace *current_ns;
+
 /* Entry point - run all passes for a namespace.  So far, only an
optimization pass is run.  */
 
@@ -48,9 +63,16 @@ gfc_run_passes (gfc_namespace *ns)
 {
   if (optimize)
 {
+  expr_size = 20;
+  expr_array = XNEWVEC(gfc_expr **, expr_size);
+
   optimize_namespace (ns);
   if (gfc_option.dump_fortran_optimized)
 	gfc_dump_parse_tree (ns, stdout);
+
+  /* FIXME: The following should be XDELETEVEC(expr_array);
+  but we cannot do that because it depends on free.  */
+  gfc_free (expr_array);
 }
 }
 
@@ -106,11 +128,222 @@ optimize_expr (gfc_expr **e, int *walk_subtrees AT
   return 0;
 }
 
+/* Compare two functions for equality.  We could use gfc_dep_compare_expr
+   except that we also consider impure functions equal, because anybody
+   changing the return value of the function within an expression would
+   violate the Fortran standard.  */
+
+static bool
+compare_functions (gfc_expr **ep1, gfc_expr **ep2)
+{
+  gfc_expr *e1, *e2;
+
+  e1 = *ep1;
+  e2 = *ep2;
+
+  if (e1->expr_type != EXPR_FUNCTION || e2->expr_type != EXPR_FUNCTION)
+return false;
+
+  if ((e1->value.function.esym && e2->value.function.esym
+   && e1->value.function.esym == e2->value.function.esym)
+  || (e1->value.function.isym && e2->value.function.isym
+	  && e1->value.function.isym == e2->value.function.isym))
+{
+  gfc_actual_arglist *args1, *args2;
+  
+  args1 = e1->value.function.actual;
+  args2 = e2->value.function.actual;
+
+  /* Compare the argument lists for equality.  */
+  while (args1 && args2)
+	{
+	  /*  Bitwise xor, since C has no non-bitwise xor operator.  */
+	  if ((args1->expr == NULL) ^ (args2->expr == NULL))
+	return false;
+
+	  if (args1->expr != NULL && args2->expr != NULL
+	  && gfc_dep_compare_expr (args1->expr, args2->expr) != 0)
+	return false;
+
+	  args1 = args1->next;
+	  args2 = args2->next;
+	}
+  return args1 == NULL && args2 == NULL;
+}
+  else
+return false;
+  
+}
+
+/* Callback function for gfc_expr_walker, called from cfe_expr_0.  Put all
+   eligible function expressions into expr_array.  We can't do allocatable
+   functions.  */
+
+static int
+cfe_expr (gfc_expr **e, int *walk_subtrees ATTRIBUTE_UNUSED,
+	  void *data ATTRIBUTE_UNUSED)
+{
+  if ((*e)->expr_type != EXPR_FUNCTION)
+return 0;
+
+  /* We don't do character functions (yet).  */
+  if ((*e)->ts.type == BT_CHARACTER)
+return 0;
+
+  /* If we don't know the shape at compile t

[google] XFAIL some guality tests (issue4289045)

[Diego Novillo]

These tests fail on trunk as well as google/integration.  XFAILing to
pacify testers.

Tested on x86_64/{-m32,-m64}.  Committed to google/integration.


2011-03-14  Diego Novillo  

* gcc.dg/guality/vla-1.c: XFAIL.
* gcc.dg/guality/vla-2.c: XFAIL.
* gcc.dg/guality/sra-1.c: XFAIL.

Index: testsuite/gcc.dg/guality/vla-1.c
===
--- testsuite/gcc.dg/guality/vla-1.c(revision 170776)
+++ testsuite/gcc.dg/guality/vla-1.c(working copy)
@@ -14,14 +14,14 @@ f1 (int i)
 {
   char a[i + 1];
   a[0] = 5;/* { dg-final { gdb-test 17 "i" "5" } } */
-  return a[0]; /* { dg-final { gdb-test 17 "sizeof (a)" "6" } } */
+  return a[0]; /* { dg-final { gdb-test 17 "sizeof (a)" "6" { xfail 
*-*-* } } } */
 }
 
 int __attribute__((noinline))
 f2 (int i)
 {
   short a[i * 2 + 7];  /* { dg-final { gdb-test 24 "i" "5" } } */
-  bar (a); /* { dg-final { gdb-test 24 "sizeof (a)" "17 * sizeof 
(short)" } } */
+  bar (a); /* { dg-final { gdb-test 24 "sizeof (a)" "17 * sizeof 
(short)" { xfail *-*-* } } } */
   return a[i + 4];
 }
 
Index: testsuite/gcc.dg/guality/vla-2.c
===
--- testsuite/gcc.dg/guality/vla-2.c(revision 170776)
+++ testsuite/gcc.dg/guality/vla-2.c(working copy)
@@ -13,7 +13,7 @@ fn2 (int i)
 {
   int a[i];
   fn1 (a, i);
-  fn1 (a, i);  /* { dg-final { gdb-test 16 "sizeof (a)" "5 * sizeof 
(int)" } } */
+  fn1 (a, i);  /* { dg-final { gdb-test 16 "sizeof (a)" "5 * sizeof 
(int)" { xfail *-*-* } } } */
   return i;
 }
 
@@ -22,7 +22,7 @@ fn3 (int i)
 {
   int a[i];
   fn1 (a, i);
-  fn1 (a, i);  /* { dg-final { gdb-test 25 "sizeof (a)" "6 * sizeof 
(int)" } } */
+  fn1 (a, i);  /* { dg-final { gdb-test 25 "sizeof (a)" "6 * sizeof 
(int)" { xfail *-*-* } } } */
   return i;
 }
 
Index: testsuite/gcc.dg/guality/sra-1.c
===
--- testsuite/gcc.dg/guality/sra-1.c(revision 170776)
+++ testsuite/gcc.dg/guality/sra-1.c(working copy)
@@ -40,7 +40,7 @@ f3 (int k)
   asm ("" : "+r" (a.i));
   a.j++;
   bar (a.i);   /* { dg-final { gdb-test 43 "a.i" "4" } } */
-  bar (a.j);   /* { dg-final { gdb-test 43 "a.j" "14" } } */
+  bar (a.j);   /* { dg-final { gdb-test 43 "a.j" "14" { xfail *-*-* } 
} } */
   return a.i + a.j;
 }
 

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

[google] XFAIL libmudflap.c/pass49-frag.c. (issue4290044)

[Diego Novillo]

This test is failing on trunk as well as google/integration.  XFAIL to
pacify the testers.

Tested on x86_64{-m32,-m64}.  Committed to google/integration.


2011-03-14  Diego Novillo  

* testsuite/libmudflap.c/pass49-frag.c: XFAIL.

Index: testsuite/libmudflap.c/pass49-frag.c
===
--- testsuite/libmudflap.c/pass49-frag.c(revision 170776)
+++ testsuite/libmudflap.c/pass49-frag.c(working copy)
@@ -1,3 +1,4 @@
+/* { dg-do run } */
 #include 
 #include 
 #include 
@@ -32,4 +33,4 @@ int main ()
   foo (7, "hello ", 5, " ", 3, " world ", 9, "\n");
   return 0;
 }
-/* { dg-output "hello 5 3 world 9" } */
+/* { dg-output "hello 5 3 world 9" { xfail *-*-* } } */

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

Re: [DOC PATCH] Add -Wunused-but-set-* note to gcc-4.6/changes.html and mention removal of in STL headers

[Gerald Pfeifer]

On Thu, 10 Mar 2011, Jakub Jelinek wrote:
> This mentions -Wunused-but-set-* warnings (which are C/C++/ObjC/ObjC++, so
> not sure how to mention them in the language specific areas instead) and
> briefly mentions removal of  includes.  More should go probably
> into gcc-4.6/porting_to.html.

This is very nice, thanks Jakub!

One idea would be to add a "C language family" subsection, but I think
your current approach is fine, too.


> +Most libstdc++ standard headers have been changed to longer include

"to no longer", I assume?

> +  cstddef header as an implementation detail.  Code that

the ... header

> +  standard headers will need include cstddef 
> explicitly.

"need to include"


Gerald

Ping^2 Re: [PATCH, ARM] Fix PR 43872, incorrectly aligned VLAs

[Chung-Lin Tang]

Ping.

On 2011/3/7 10:10 PM, Chung-Lin Tang wrote:
> Ping.
> 
> On 2011/2/17 06:01 PM, Chung-Lin Tang wrote:
>> Hi,
>> this PR is a case where we have a leaf function with a zero-size frame,
>> that calls alloca() (here through a C99 VLA).
>>
>> The ARM backend recognizes the leaf-and-no-frame opportunity to save an
>> unneeded stack alignment. But when calling alloca(), the allocated block
>> is of BIGGEST_ALIGNMENT, which is 8-bytes under current AAPCS. Thus a
>> stack align may still be needed to place the alloca() returned block
>> properly.
>>
>> This patch adjusts the early return condition with !cfun->calls_alloca.
>> Tested without regressions on ARM-Linux, okay for trunk?
>>
>> Also related, the BIGGEST_ALIGNMENT defined for ARM is currently
>> ABI-based; 64-bits for AAPCS targets, and 32 for old ABI.  Should this
>> also consider arch-level as well? i.e. anything >= ARMv5TE (with ldrd)
>> should have this set to 64.
>>
>> Thanks,
>> Chung-Lin
>>
>> 2011-02-17  Chung-Lin Tang  
>>
>>  PR target/43872
>>  * config/arm/arm.c (arm_get_frame_offsets): Adjust early
>>  return condition with !cfun->calls_alloca.
> 

Ping^3 Re: [patch, ARM] ICE in get_arm_condition_code()

[Chung-Lin Tang]

Ping.

On 2011/3/7 10:10 PM, Chung-Lin Tang wrote:
> Ping.
> 
> On 2011/1/26 11:09 AM, Chung-Lin Tang wrote:
>> Ping.
>> (I'll fix the minor nits before actually committing, thanks Ramana :)
>>
>> On 2011/1/13 08:24, Chung-Lin Tang wrote:
>>> Hi,
>>> there's an ICE in arm.c:get_arm_condition_code(), from here:
>>> https://bugs.launchpad.net/gcc-linaro/+bug/689887
>>>
>>> The report was on a 4.5 based compiler, but I verified it also occurs on
>>> current trunk, under Thumb-2.
>>>
>>> The problem as I found, happens in RTL ifcvt after the combine pass.
>>> ifcvt.c:noce_emit_cmove() creates this:
>>> (insn 58 57 59 4 (parallel [
>>> (set (reg:CC_NCV 24 cc)
>>> (compare:CC_NCV (reg:DI 140)
>>> (reg:DI 147)))
>>> (clobber (scratch:SI))
>>> ]) p.c:13 202 {*arm_cmpdi_insn}
>>>  (nil))
>>>
>>> (insn 59 58 60 4 (set (reg:SI 146)
>>> (if_then_else:SI (gt (reg:CC_NCV 24 cc)
>>> (const_int 0 [0]))
>>> (reg:SI 145)
>>> (reg:SI 144))) p.c:13 701 {*thumb2_movsicc_insn}
>>>  (nil))
>>>
>>> which is wrong; the GT comparison requires testing of the Z, C, and V
>>> flags, which CC_NCV does not satisfy. The ICE happens later when the asm
>>> emitting actually hits assert fail in get_arm_condition_code().
>>>
>>> This patch fixes this by stratifying the "arm_comparison_operator"
>>> predicate, by leveraging the current logic in get_arm_condition_code().
>>> I abstracted out the body into a new arm_comparison_to_cond_code()
>>> function, which returns an invalid code instead of assert fail, and used
>>> it to add a check to the comparison RTX in "arm_comparison_operator".
>>> This way, invalid comparisons like the above would be blocked from emitting.
>>>
>>> Tests were run with no regressions found. Okay for trunk?
>>>
>>> Thanks,
>>> Chung-Lin
>>>
>>> 2011-01-12  Chung-Lin Tang  
>>>
>>> * config/arm/arm.h (enum arm_cond_code): Add ARM_COND_INVALID.
>>> * config/arm/arm.c (arm_comparison_to_cond_code): Renamed from
>>> get_arm_condition_code(), change gcc_unreachable()s to return
>>> ARM_COND_INVALID.
>>> (get_arm_condition_code): Implement by calling
>>> arm_comparison_to_cond_code(), with result test by gcc_assert().
>>> (arm_valid_comparison_p): New function to test for valid ARM
>>> comparison RTX.
>>> * config/arm/arm-protos.h (arm_valid_comparison_p): Add
>>> prototype.
>>> * config/arm/predicates.md (arm_comparison_operator): Add
>>> additional check based on arm_valid_comparison_p().
>>>
>>> testsuite/
>>> * gcc.target/arm/20110112-1.c: New test.
>>>
>>>
>>>
>>
> 

Ping^3 Re: [PATCH, ARM] Fix PR44557, Thumb-1 ICE

[Chung-Lin Tang]

Ping.

On 2011/3/7 10:11 PM, Chung-Lin Tang wrote:
> Ping.
> 
> On 2011/1/26 11:07 AM, Chung-Lin Tang wrote:
>> On 2011/1/1 19:21, Chung-Lin Tang wrote:
>>> On 2010/12/21 02:03, Richard Earnshaw wrote:

 On Thu, 2010-12-09 at 14:08 +0800, Chung-Lin Tang wrote:
> Hi,
> this patch fixes the ICE in PR44557. It now occurs on trunk only under 
> quite specific option conditions, but debugging this PR leaded to quite 
> obvious Thumb-1 fixes.
>
> Also added a simplified testcase, derived from the one on bugzilla. 
> Tested without regressions, okay to commit to trunk?
>
> Thanks,
> Chung-Lin
>
> 2010-12-09  Chung-Lin Tang  
>
>   PR target/44557
>   * config/arm/arm.h (PREFERRED_RELOAD_CLASS): Add CORE_REGS to
>   Thumb-1 return LO_REGS case.
>   * config/arm/arm.md (reload_inhi): Change scratch constraint
>   from 'r' to 'l'.
>
>   testsuite/
>   * gcc.target/arm/pr44557.c: New.
>

 Changing the scratch constraint to 'l' is going to pessimize thumb2 code
 reload generation which can quite reasonably take an 'r' class here.  

 I'm not sure there's an easy way to fix this without going the whole hog
 and getting rid of reload_inhi entirely (which would be a good thing,
 TM) and replacing it with the new reload infrastructure that Joern wrote
 a few years back.

 Before approving this I want to be sure that it doesn't cause major
 problems on Thumb-2.  What testing have you done for that configuration?

 R.

 PS: Maybe another way to fix this would be to introduce a new register
 class that expands to GENERAL_REGS on 32-bit cores and LO_REGS on
 Thumb-1 only.

>>>
>>> Hi Richard,
>>>
>>> My testing was for Thumb-1 (-march=armv5te -mthumb), as that was what
>>> the ICE was about. I later tried another test run with Thumb-2 as you
>>> suggested, to be sure, and saw no regressions too.
>>>
>>> I've then been looking into the secondary reload logic. The ARM
>>> backend's SECONDARY_INPUT/OUTPUT_RELOAD_CLASS macros already returns
>>> NO_REGS under TARGET_32BIT for integer modes (no secondary reloads
>>> needed). Looking at the default_secondary_reload() function, this means
>>> that the reload_in/outhi patterns are never used for Thumb-2.
>>>
>>> So this patch should only affect Thumb-1, and the Thumb-2 considerations
>>> should be unneeded.
>>
>> Hi Richard, pinging this patch.
>> I think I've explained the effects of this fix, and it should be Thumb-1
>> only. Is this patch okay?
>>
>> Thanks,
>> Chung-Lin
> 

Re: Fix pr48032, powerpc64 -mcmodel=medium invalid ld offset

[Alan Modra]

After some discussion with David and Richard, this is what I'm about
to commit.  Differs from the previous patch in returning false for
BLKmode (via GET_MODE_SIZE(mode)==0 test) in the !decl branch of
offsettable_ok_by_alignment.

PR target/48032
* config/rs6000/rs6000.c (offsettable_ok_by_alignment): Do not
presume symbol_refs without a symbol_ref_decl are suitably
aligned, nor other trees we may see here.  Handle anchor symbols.
(legitimate_constant_pool_address_p): Comment.  Add mode param.
Check cmodel=medium addresses.  Adjust all calls.
(rs6000_emit_move): Don't call offsettable_ok_by_alignment on
creating cmodel=medium optimized access to locals.
* config/rs6000/constraints.md (R): Pass QImode to
legitimate_constant_pool_address_p.
* config/rs6000/predicates.md (input_operand): Pass mode to
legitimate_constant_pool_address_p.
* config/rs6000/rs6000-protos.h (legitimate_constant_pool_address_p):
Update prototype.

Index: gcc/config/rs6000/constraints.md
===
--- gcc/config/rs6000/constraints.md(revision 170975)
+++ gcc/config/rs6000/constraints.md(working copy)
@@ -166,7 +166,7 @@ (define_address_constraint "a"
 
 (define_constraint "R"
   "AIX TOC entry"
-  (match_test "legitimate_constant_pool_address_p (op, false)"))
+  (match_test "legitimate_constant_pool_address_p (op, QImode, false)"))
 
 ;; General constraints
 
Index: gcc/config/rs6000/predicates.md
===
--- gcc/config/rs6000/predicates.md (revision 170975)
+++ gcc/config/rs6000/predicates.md (working copy)
@@ -854,7 +854,7 @@ (define_predicate "input_operand"
 return 1;
 
   /* A SYMBOL_REF referring to the TOC is valid.  */
-  if (legitimate_constant_pool_address_p (op, false))
+  if (legitimate_constant_pool_address_p (op, mode, false))
 return 1;
 
   /* A constant pool expression (relative to the TOC) is valid */
Index: gcc/config/rs6000/rs6000-protos.h
===
--- gcc/config/rs6000/rs6000-protos.h   (revision 170975)
+++ gcc/config/rs6000/rs6000-protos.h   (working copy)
@@ -41,7 +41,8 @@ extern int small_data_operand (rtx, enum
 extern bool toc_relative_expr_p (rtx);
 extern bool invalid_e500_subreg (rtx, enum machine_mode);
 extern void validate_condition_mode (enum rtx_code, enum machine_mode);
-extern bool legitimate_constant_pool_address_p (const_rtx, bool);
+extern bool legitimate_constant_pool_address_p (const_rtx, enum machine_mode,
+   bool);
 extern bool legitimate_indirect_address_p (rtx, int);
 extern bool legitimate_indexed_address_p (rtx, int);
 extern bool avoiding_indexed_address_p (enum machine_mode);
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 170975)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -5791,6 +5791,94 @@ virtual_stack_registers_memory_p (rtx op
  && regnum <= LAST_VIRTUAL_POINTER_REGISTER);
 }
 
+/* Return true if memory accesses to OP are known to never straddle
+   a 32k boundary.  */
+
+static bool
+offsettable_ok_by_alignment (rtx op, HOST_WIDE_INT offset,
+enum machine_mode mode)
+{
+  tree decl, type;
+  unsigned HOST_WIDE_INT dsize, dalign;
+
+  if (GET_CODE (op) != SYMBOL_REF)
+return false;
+
+  decl = SYMBOL_REF_DECL (op);
+  if (!decl)
+{
+  if (GET_MODE_SIZE (mode) == 0)
+   return false;
+
+  /* -fsection-anchors loses the original SYMBOL_REF_DECL when
+replacing memory addresses with an anchor plus offset.  We
+could find the decl by rummaging around in the block->objects
+VEC for the given offset but that seems like too much work.  */
+  dalign = 1;
+  if (SYMBOL_REF_HAS_BLOCK_INFO_P (op)
+ && SYMBOL_REF_ANCHOR_P (op)
+ && SYMBOL_REF_BLOCK (op) != NULL)
+   {
+ struct object_block *block = SYMBOL_REF_BLOCK (op);
+ HOST_WIDE_INT lsb, mask;
+
+ /* Given the alignment of the block..  */
+ dalign = block->alignment;
+ mask = dalign / BITS_PER_UNIT - 1;
+
+ /* ..and the combined offset of the anchor and any offset
+to this block object..  */
+ offset += SYMBOL_REF_BLOCK_OFFSET (op);
+ lsb = offset & -offset;
+
+ /* ..find how many bits of the alignment we know for the
+object.  */
+ mask &= lsb - 1;
+ dalign = mask + 1;
+   }
+  return dalign >= GET_MODE_SIZE (mode);
+}
+
+  if (DECL_P (decl))
+{
+  if (TREE_CODE (decl) == FUNCTION_DECL)
+   return true;
+
+  if (!DECL_SIZE_UNIT (decl))
+   return false;
+
+  if (!host_integerp (DECL_SIZE_UNIT (decl), 1))
+   return false;
+
+

[PATCH] Re-enable lto on powerpc-apple-darwin*

[Jack Howarth]

  The assembler bug in Xcode 3.2.6/4.0 can't impact powerpc-apple-darwin*
(except in the old-ball case of building the powerpc-apple-darwin* target
under Rosetta on Snow Leopard), lto can be re-enabled for that target in
gcc trunk. Re-enabling lto for powerpc-apple-darwin* in gcc trunk allows us to
continue to monitor the status of darwin lto support while the containerized
lto changes for PR48108 are completed. Okay for gcc trunk?

2011-03-14  Jack Howarth  

* configure.ac: Re-enable LTO on powerpc-apple-darwin*.
* configure: Regenerate.

Index: configure.ac
===
--- configure.ac(revision 170975)
+++ configure.ac(working copy)
@@ -1743,7 +1743,7 @@ ACX_ELF_TARGET_IFELSE([# ELF platforms b
   build_lto_plugin=yes
 ],[if test x"$default_enable_lto" = x"yes" ; then
 case $target in
-  *-cygwin* | *-mingw*) ;;
+  powerpc-apple-darwin* | *-cygwin* | *-mingw*) ;;
   # On other non-ELF platforms, LTO has yet to be validated.
   *) enable_lto=no ;;
 esac

[v3] regex versioned namespaces

[Benjamin Kosnik]

Ugh. While doing other things I realized that the namespace versioning
for regex header files is off: it's not on the inner-most nested
namespace.

Fixed thusly.

tested x86/linux
tested x86/linux --enable-symvers=gnu-namespace-versioned

-benjamin2011-03-14  Benjamin Kosnik  

	* include/bits/regex_compiler.h: Nest namespace versioning.
	* include/bits/regex_grep_matcher.tcc: Same.
	* include/bits/regex_grep_matcher.h: Same.
	* include/bits/regex_cursor.h: Same.
	* include/bits/regex_nfa.h: Same.
	* include/bits/regex_nfa.tcc: Same.

	* include/bits/regex_grep_matcher.h: Version forward declarations.
	* include/bits/c++config: Add namespace association for __regex.
	* include/bits/regex.h: Make sub_match consistent.


Index: include/bits/regex_grep_matcher.h
===
--- include/bits/regex_grep_matcher.h	(revision 170975)
+++ include/bits/regex_grep_matcher.h	(working copy)
@@ -30,12 +30,15 @@
 
 namespace std _GLIBCXX_VISIBILITY(default)
 {
+_GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   template
 class sub_match;
 
   template
 class match_results;
+
+_GLIBCXX_END_NAMESPACE_VERSION
   
 namespace __regex
 {
Index: include/bits/c++config
===
--- include/bits/c++config	(revision 170975)
+++ include/bits/c++config	(working copy)
@@ -170,9 +170,6 @@
 {
   inline namespace _6 { }
 
-  namespace __detail { inline namespace _6 { } }
-
-
   namespace rel_ops { inline namespace _6 { } }
 
   namespace tr1
@@ -189,6 +186,9 @@
   namespace placeholders { inline namespace _6 { } }
   namespace regex_constants { inline namespace _6 { } }
   namespace this_thread { inline namespace _6 { } }
+
+  namespace __detail { inline namespace _6 { } }
+  namespace __regex { inline namespace _6 { } }
 }
 
 namespace __gnu_cxx
Index: include/bits/regex.h
===
--- include/bits/regex.h	(revision 170975)
+++ include/bits/regex.h	(working copy)
@@ -1459,7 +1459,7 @@
   template > >
 class match_results
-: private std::vector, _Allocator>
+: private std::vector, _Allocator>
 {
 private:
   /*
@@ -1473,8 +1473,7 @@
* [n+1] prefix
* [n+2] suffix
*/
-  typedef std::vector, _Allocator>
-  _Base_type;
+  typedef std::vector, _Allocator>_Base_type;
 
 public:
   /**

Re: [DOC PATCH] Add -Wunused-but-set-* note to gcc-4.6/changes.html and mention removal of in STL headers

[Matthias Klose]

On 10.03.2011 17:04, Jakub Jelinek wrote:
> +default by -Wall flag and 
> -Wunused-but-set-parameter
> +by -Wall -W flags.

-W is documented as "old option".  Maybe use -Wextra instead?

  Matthias

Re: [v3] typeinfo tuning

[Hans-Peter Nilsson]

On Mon, 14 Mar 2011, Benjamin Kosnik wrote:
> This is versioned for 4.6.0, but I'll wait a day or two to see how it
> goes before I plead with the RMs.

It broke build, hopefully for trivial reasons.  It seems like
your bugzilla options are set to not receive email, so I'll have
to bug you like this, and ask that you please have a look at
PR48130.

> tested x86_64/linux

Broke cris-elf (et al, presumably).

brgds, H-P

Re: [v3] regex versioned namespaces

[Hans-Peter Nilsson]

On Mon, 14 Mar 2011, Benjamin Kosnik wrote:
>
> Ugh. While doing other things I realized that the namespace versioning
> for regex header files is off: it's not on the inner-most nested
> namespace.
>
> Fixed thusly.

But it seems like it's not committed?

brgds, H-P

Re: [v3] typeinfo tuning

[Benjamin Kosnik]

> It broke build, hopefully for trivial reasons.  It seems like
> your bugzilla options are set to not receive email, so I'll have
> to bug you like this, and ask that you please have a look at
> PR48130.

No problem. Sorry about the breakage. Indeed, it was trivial. 

> > tested x86_64/linux  

tested x86/64, compiled arm-eabi

-benjamin2011-03-14  Benjamin Kosnik  

PR libstdc++/48130
* src/future.cc: Guard definitions.
* libsupc++/nested_exception.cc: Same.


Index: src/future.cc
===
--- src/future.cc	(revision 170978)
+++ src/future.cc	(working copy)
@@ -79,11 +79,14 @@
   const char* 
   future_error::what() const throw() { return _M_code.message().c_str(); }
 
+#if defined(_GLIBCXX_HAS_GTHREADS) && defined(_GLIBCXX_USE_C99_STDINT_TR1) \
+  && defined(_GLIBCXX_ATOMIC_BUILTINS_4)
   __future_base::_Result_base::_Result_base() = default;
 
   __future_base::_Result_base::~_Result_base() = default;
 
   __future_base::_State_base::~_State_base() = default;
+#endif
 
 _GLIBCXX_END_NAMESPACE_VERSION
 } // namespace std
Index: libsupc++/nested_exception.cc
===
--- libsupc++/nested_exception.cc	(revision 170978)
+++ libsupc++/nested_exception.cc	(working copy)
@@ -25,5 +25,7 @@
 
 namespace std 
 {
+#ifdef _GLIBCXX_ATOMIC_BUILTINS_4
   nested_exception::~nested_exception() = default;
+#endif
 } // namespace std

Re: [PATCH, ARM] Fix PR 43872, incorrectly aligned VLAs

[Ramana Radhakrishnan]

On 17/02/11 10:01, Chung-Lin Tang wrote:

Hi,
this PR is a case where we have a leaf function with a zero-size frame,
that calls alloca() (here through a C99 VLA).

The ARM backend recognizes the leaf-and-no-frame opportunity to save an
unneeded stack alignment. But when calling alloca(), the allocated block
is of BIGGEST_ALIGNMENT, which is 8-bytes under current AAPCS. Thus a
stack align may still be needed to place the alloca() returned block
properly.

This patch adjusts the early return condition with !cfun->calls_alloca.
Tested without regressions on ARM-Linux, okay for trunk?


OK.



Also related, the BIGGEST_ALIGNMENT defined for ARM is currently
ABI-based; 64-bits for AAPCS targets, and 32 for old ABI.  Should this
also consider arch-level as well? i.e. anything>= ARMv5TE (with ldrd)
should have this set to 64.


I don't think it's that straightforward. The ABI specifies that an 8 
byte quantity must be aligned at 64 bit boundaries and this should be 
independent of architecture revisions. Think about pointers to 64 bit 
quantities passed from !(TARGET_LDRD) to TARGET_LDRD code or indeed 
creating structure layout issues between architecture revisions if you 
change this.


cheers
Ramana



2011-02-17  Chung-Lin Tang

PR target/43872
* config/arm/arm.c (arm_get_frame_offsets): Adjust early
return condition with !cfun->calls_alloca.