mark expected failures for ppc64 (issue6932046)

2012-12-10 Thread Jing Yu
Add powerpc64-grtev3-linux-gnu.xfail to mark expected failures for
powerpc64 toolchain. For google/gcc_4-7 branch.

Tested:
  ./buildit --build_type=symlinks  --keep_work_dir --run_tests 
gcc-4.7.x-grtev3-powerpc64


2012-12-10  Jing Yu  
* contrib/testsuite-management/powerpc64-grtev3-linux-gnu.xfail: New


Index: contrib/ChangeLog.google-4_7
===
--- contrib/ChangeLog.google-4_7(revision 194383)
+++ contrib/ChangeLog.google-4_7(working copy)
@@ -1,3 +1,8 @@
+2012-12-10  Jing Yu  
+
+   * contrib/testsuite-management/powerpc64-grtev3-linux-gnu.xfail:
+   New.
+
 2012-11-05  Paul Pluzhnikov  
 
* contrib/testsuite-management/powerpc-grtev3-linux-gnu.xfail:
Index: contrib/testsuite-management/powerpc64-grtev3-linux-gnu.xfail
===
--- contrib/testsuite-management/powerpc64-grtev3-linux-gnu.xfail   
(revision 0)
+++ contrib/testsuite-management/powerpc64-grtev3-linux-gnu.xfail   
(revision 0)
@@ -0,0 +1,149 @@
+# Marked test failures for v16-powerpc64 toolchain built from
+# v16 release branch @64346, and v16 dev branch @64533.
+# *** gcc:
+FAIL: gcc.c-torture/execute/20020226-1.c execution,  -O0 
+FAIL: gcc.c-torture/execute/20020226-1.c execution,  -O1 
+FAIL: gcc.c-torture/execute/20020226-1.c execution,  -O2 
+FAIL: gcc.c-torture/execute/20020226-1.c execution,  -O3 -fomit-frame-pointer 
+FAIL: gcc.c-torture/execute/20020226-1.c execution,  -O3 -g 
+FAIL: gcc.c-torture/execute/20020226-1.c execution,  -Os 
+FAIL: gcc.c-torture/execute/20020226-1.c execution,  -O2 -flto 
-fno-use-linker-plugin -flto-partition=none 
+FAIL: gcc.c-torture/execute/20020508-1.c execution,  -O0 
+FAIL: gcc.c-torture/execute/20020508-1.c execution,  -O1 
+FAIL: gcc.c-torture/execute/20020508-1.c execution,  -O2 
+FAIL: gcc.c-torture/execute/20020508-1.c execution,  -O3 -fomit-frame-pointer 
+FAIL: gcc.c-torture/execute/20020508-1.c execution,  -O3 -g 
+FAIL: gcc.c-torture/execute/20020508-1.c execution,  -Os 
+FAIL: gcc.c-torture/execute/20020508-1.c execution,  -O2 -flto 
-fno-use-linker-plugin -flto-partition=none 
+FAIL: gcc.dg/and-1.c scan-assembler-not nand
+FAIL: gcc.dg/cleanup-10.c execution test
+FAIL: gcc.dg/cleanup-11.c execution test
+FAIL: gcc.dg/cleanup-8.c execution test
+FAIL: gcc.dg/cleanup-9.c execution test
+FAIL: gcc.dg/pr44194-1.c scan-rtl-dump dse1 "global deletions = (2|3)"
+FAIL: gcc.dg/pr44194-1.c scan-rtl-dump-not final "set \\(mem"
+FAIL: gcc.dg/pr46728-6.c scan-assembler-not pow
+
+# These tests succeeded in v15-powerpc64. But they failed in v16-x86 too.
+FAIL: gcc.dg/thread_annot_lock-23.c  (test for warnings, line 10)
+FAIL: gcc.dg/thread_annot_lock-23.c  (test for warnings, line 13)
+FAIL: gcc.dg/thread_annot_lock-23.c  (test for warnings, line 15)
+FAIL: gcc.dg/thread_annot_lock-23.c  (test for warnings, line 18)
+FAIL: gcc.dg/thread_annot_lock-23.c  (test for warnings, line 19)
+FAIL: gcc.dg/thread_annot_lock-24.c  (test for warnings, line 8)
+FAIL: gcc.dg/thread_annot_lock-24.c  (test for warnings, line 9)
+FAIL: gcc.dg/thread_annot_lock-24.c  (test for warnings, line 10)
+FAIL: gcc.dg/thread_annot_lock-25.c  (test for warnings, line 8)
+FAIL: gcc.dg/thread_annot_lock-25.c  (test for warnings, line 9)
+FAIL: gcc.dg/thread_annot_lock-25.c  (test for warnings, line 10)
+FAIL: gcc.dg/thread_annot_lock-25.c  (test for warnings, line 22)
+FAIL: gcc.dg/thread_annot_lock-25.c  (test for warnings, line 30)
+FAIL: gcc.dg/thread_annot_lock-42.c  (test for warnings, line 9)
+
+FAIL: gcc.dg/torture/pr53589.c  -O3 -g  (internal compiler error)
+FAIL: gcc.dg/torture/pr53589.c  -O3 -g  (test for excess errors)
+flaky | FAIL: gcc.dg/torture/tls/tls-test.c  -O0  execution test
+flaky | FAIL: gcc.dg/torture/tls/tls-test.c  -O0  -fpic  execution test
+flaky | FAIL: gcc.dg/torture/tls/tls-test.c  -O0  -fPIC  execution test
+flaky | FAIL: gcc.dg/torture/tls/tls-test.c  -O0  -pie -fpie  execution test
+flaky | FAIL: gcc.dg/torture/tls/tls-test.c  -O0  -pie -fPIE  execution test
+flaky | FAIL: gcc.dg/torture/tls/tls-test.c  -O1  execution test
+flaky | FAIL: gcc.dg/torture/tls/tls-test.c  -O1  -fpic  execution test
+flaky | FAIL: gcc.dg/torture/tls/tls-test.c  -O1  -fPIC  execution test
+flaky | FAIL: gcc.dg/torture/tls/tls-test.c  -O1  -pie -fpie  execution test
+flaky | FAIL: gcc.dg/torture/tls/tls-test.c  -O1  -pie -fPIE  execution test
+flaky | FAIL: gcc.dg/torture/tls/tls-test.c  -O2  execution test
+flaky | FAIL: gcc.dg/torture/tls/tls-test.c  -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  execution test
+flaky | FAIL: gcc.dg/torture/tls/tls-test.c  -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  execution test
+flaky | FAIL: gcc.dg/torture/tls/tls-test.c  -O2  -fpic  execution test
+flaky | FAIL: gcc.dg/torture/tls/tls-test.c  -O2  -fPIC  execution test
+flaky | FAIL: gcc.dg/torture/tls/tls-test.c  -O2  -pie -fpie  execution tes

Re: application/xml mime-type in recent libstdc++ doc changes

2012-12-10 Thread Matthias Klose
Am 10.12.2012 18:52, schrieb Benjamin De Kosnik:
> 
>>> libstdc++-v3/doc/xsl/customization.xsl.in is marked as
>>>
>>>   svn:mime-type = application/xml
>>>
>>> at least on the 4.7 branch, having some unexpected outcome for svn
>>> diff. If this was unintended, could you change the svn:mime-type
>>> back to text?
> 
> This is unintentional, and frankly I don't know how the inital mime
> type was created or how to fix it. Any pointers? Can you do it and tell
> me how?

I did a 'svn propset svn:mime-type text/xml customization.xsl.in', both on the
branch and the trunk. text/xml is the default mime-type for *.xsl files. The
file now appears in svn diff output.

  Matthias



Re: [GOOGLE] disable streaming out TREE_BLOCK to cure lto-bootstrap

2012-12-10 Thread Dehao Chen
On Mon, Dec 10, 2012 at 9:30 PM, Andrew Pinski  wrote:
>
> On Mon, Dec 10, 2012 at 9:23 PM, Dehao Chen  wrote:
> > Hi,
> >
> > The location_block patch has failed lto-bootstrap. This is fixed by a
> > bunch of fixes in trunk. But we would rather not spend too much effort
> > to back-port those fixes. So for now, we would disable streaming out
> > TREE_BLOCK as a workaround to solve to lto-bootstrap.
> >
> > Bootstrapped and passed crosstool tests.
> >
> > Okay for google-4_7?
>
> Won't this break debugging information even more than it is already
> broken with LTO?

As you said, debug info in LTO is already broken (it can easily
overflow the 32bit integer space for location_t). And you are also
right that this patch will lose debug info (inline stack) for exprs in
google-4_7 branch. But as it just broke something that is already
broken, thus we think it is a reasonable workaround in order to make
lto actually work. When we upgrade to google-4_8, we will
automatically inherit from the trunk fixes.

Thanks,
Dehao

>
> Thanks,
> Andrew Pinski
>
>
> >
> > Thanks,
> > Dehao
> >
> > gcc/ChangeLog.google-4_7
> > 2012-12-10  Dehao Chen  
> >
> > * tree-streamer-out.c (write_ts_exp_tree_pointers): Disable
> > streaming out TREE_BLOCK.
> > Index: gcc/tree-streamer-out.c
> > ===
> > --- gcc/tree-streamer-out.c (revision 194378)
> > +++ gcc/tree-streamer-out.c (working copy)
> > @@ -667,7 +667,7 @@ write_ts_exp_tree_pointers (struct output_block *o
> >for (i = 0; i < TREE_OPERAND_LENGTH (expr); i++)
> >  stream_write_tree (ob, TREE_OPERAND (expr, i), ref_p);
> >lto_output_location (ob, LOCATION_LOCUS (EXPR_LOCATION (expr)));
> > -  stream_write_tree (ob, TREE_BLOCK (expr), ref_p);
> > +  stream_write_tree (ob, NULL_TREE, ref_p);
> >  }


Re: [GOOGLE] disable streaming out TREE_BLOCK to cure lto-bootstrap

2012-12-10 Thread Andrew Pinski
On Mon, Dec 10, 2012 at 9:23 PM, Dehao Chen  wrote:
> Hi,
>
> The location_block patch has failed lto-bootstrap. This is fixed by a
> bunch of fixes in trunk. But we would rather not spend too much effort
> to back-port those fixes. So for now, we would disable streaming out
> TREE_BLOCK as a workaround to solve to lto-bootstrap.
>
> Bootstrapped and passed crosstool tests.
>
> Okay for google-4_7?

Won't this break debugging information even more than it is already
broken with LTO?

Thanks,
Andrew Pinski


>
> Thanks,
> Dehao
>
> gcc/ChangeLog.google-4_7
> 2012-12-10  Dehao Chen  
>
> * tree-streamer-out.c (write_ts_exp_tree_pointers): Disable
> streaming out TREE_BLOCK.
> Index: gcc/tree-streamer-out.c
> ===
> --- gcc/tree-streamer-out.c (revision 194378)
> +++ gcc/tree-streamer-out.c (working copy)
> @@ -667,7 +667,7 @@ write_ts_exp_tree_pointers (struct output_block *o
>for (i = 0; i < TREE_OPERAND_LENGTH (expr); i++)
>  stream_write_tree (ob, TREE_OPERAND (expr, i), ref_p);
>lto_output_location (ob, LOCATION_LOCUS (EXPR_LOCATION (expr)));
> -  stream_write_tree (ob, TREE_BLOCK (expr), ref_p);
> +  stream_write_tree (ob, NULL_TREE, ref_p);
>  }


Re: [GOOGLE] disable streaming out TREE_BLOCK to cure lto-bootstrap

2012-12-10 Thread Xinliang David Li
ok.

David

On Mon, Dec 10, 2012 at 9:23 PM, Dehao Chen  wrote:
> Hi,
>
> The location_block patch has failed lto-bootstrap. This is fixed by a
> bunch of fixes in trunk. But we would rather not spend too much effort
> to back-port those fixes. So for now, we would disable streaming out
> TREE_BLOCK as a workaround to solve to lto-bootstrap.
>
> Bootstrapped and passed crosstool tests.
>
> Okay for google-4_7?
>
> Thanks,
> Dehao
>
> gcc/ChangeLog.google-4_7
> 2012-12-10  Dehao Chen  
>
> * tree-streamer-out.c (write_ts_exp_tree_pointers): Disable
> streaming out TREE_BLOCK.
> Index: gcc/tree-streamer-out.c
> ===
> --- gcc/tree-streamer-out.c (revision 194378)
> +++ gcc/tree-streamer-out.c (working copy)
> @@ -667,7 +667,7 @@ write_ts_exp_tree_pointers (struct output_block *o
>for (i = 0; i < TREE_OPERAND_LENGTH (expr); i++)
>  stream_write_tree (ob, TREE_OPERAND (expr, i), ref_p);
>lto_output_location (ob, LOCATION_LOCUS (EXPR_LOCATION (expr)));
> -  stream_write_tree (ob, TREE_BLOCK (expr), ref_p);
> +  stream_write_tree (ob, NULL_TREE, ref_p);
>  }


[GOOGLE] disable streaming out TREE_BLOCK to cure lto-bootstrap

2012-12-10 Thread Dehao Chen
Hi,

The location_block patch has failed lto-bootstrap. This is fixed by a
bunch of fixes in trunk. But we would rather not spend too much effort
to back-port those fixes. So for now, we would disable streaming out
TREE_BLOCK as a workaround to solve to lto-bootstrap.

Bootstrapped and passed crosstool tests.

Okay for google-4_7?

Thanks,
Dehao

gcc/ChangeLog.google-4_7
2012-12-10  Dehao Chen  

* tree-streamer-out.c (write_ts_exp_tree_pointers): Disable
streaming out TREE_BLOCK.
Index: gcc/tree-streamer-out.c
===
--- gcc/tree-streamer-out.c (revision 194378)
+++ gcc/tree-streamer-out.c (working copy)
@@ -667,7 +667,7 @@ write_ts_exp_tree_pointers (struct output_block *o
   for (i = 0; i < TREE_OPERAND_LENGTH (expr); i++)
 stream_write_tree (ob, TREE_OPERAND (expr, i), ref_p);
   lto_output_location (ob, LOCATION_LOCUS (EXPR_LOCATION (expr)));
-  stream_write_tree (ob, TREE_BLOCK (expr), ref_p);
+  stream_write_tree (ob, NULL_TREE, ref_p);
 }


[cxx-conversion] Fix hash_table build problems with checking enabled.

2012-12-10 Thread Lawrence Crowl
Fix some hash_table build errors when configured with
--enable-checking=yes.

tree-browser.c
   * Remove stale declaration of removed TB_parent_eq.
   * Fix template parameter for base class to match value_type.

gimple.h
   * Use gimplify_hasher::hash rather than gimple_tree_hash in the
   assertion check.
   * Change return values to match return type. (I.e. no conversions.)

Tested on x86-64.

Committing to branch as obvious.


Index: gcc/tree-browser.c
===
--- gcc/tree-browser.c  (revision 194227)
+++ gcc/tree-browser.c  (working copy)
@@ -96,14 +96,13 @@ static tree TB_next_expr (tree);
 static tree TB_up_expr (tree);
 static tree TB_first_in_bind (tree);
 static tree TB_last_in_bind (tree);
-static int  TB_parent_eq (const void *, const void *);
 static tree TB_history_prev (void);

 /* FIXME: To be declared in a .h file.  */
 void browse_tree (tree);

 /* Hashtable helpers.  */
-struct tree_upper_hasher : typed_noop_remove 
+struct tree_upper_hasher : typed_noop_remove 
 {
   typedef tree_node value_type;
   typedef tree_node compare_type;
Index: gcc/gimple.h
===
--- gcc/gimple.h(revision 194227)
+++ gcc/gimple.h(working copy)
@@ -972,18 +972,18 @@ gimplify_hasher::equal (const value_type

   if (TREE_CODE (t2) != code
   || TREE_TYPE (t1) != TREE_TYPE (t2))
-return 0;
+return false;

   if (!operand_equal_p (t1, t2, 0))
-return 0;
+return false;

 #ifdef ENABLE_CHECKING
   /* Only allow them to compare equal if they also hash equal; otherwise
  results are nondeterminate, and we fail bootstrap comparison.  */
-  gcc_assert (gimple_tree_hash (p1) == gimple_tree_hash (p2));
+  gcc_assert (hash (p1) == hash (p2));
 #endif

-  return 1;
+  return true;
 }

 struct gimplify_ctx

-- 
Lawrence Crowl


Re: [Patch, Fortran, F03] PR52909: Procedure pointers not private to modules

2012-12-10 Thread Janus Weil
Hi Tobias,

> I think the patch below is okay, especially in light of patch PR49110/51055
> which also contains a slight ABI breakage.

thanks, committed as r194375.


> Can you mention the potential ABI
> issue in the release notes (gfortran wiki).

Will do ...

Cheers,
Janus



> On 09.04.2012 18:31 Janus Weil wrote:
>>
>> Hi all,
>>
>> here is a simple patch for a problem recently reported by Andrew
>> Benson: Procedure pointers inside a module don't receive the proper
>> name mangling, which can lead to name collisions (as the test case
>> demonstrates).
>>
>> The patch fixes this and regtests cleanly on x86_64-unknown-linux-gnu.
>> I am aware that it will break the ABI, but only for programs involving
>> procedure pointers (which still is a 'relatively' new feature,
>> supported since gfortran 4.4). So, ok for trunk?
>>
>> Btw, speaking of ABI breaking: What are the chances of the array
>> descriptor update and ABI cleanup happening for the 4.8 release? I
>> know such an ABI breaking has been planned for some time, but I
>> haven't followed the gfortran mailing list in detail during the last
>> weeks and months, so I'm not sure what the current status is.
>>
>> Cheers,
>> Janus
>>
>>
>>
>> 2012-04-09  Janus Weil  
>>
>> PR fortran/52909
>> * trans-decl.c (get_proc_pointer_decl): Apply name mangling.
>>
>>
>> 2012-04-09  Janus Weil  
>>
>> PR fortran/52909
>> * gfortran.dg/proc_ptr_37.f90: New test case.
>
>


Re: [PATCH] Bugfix: Additional parameter for canonicalize comparison

2012-12-10 Thread Kaz Kojima
Andreas Krebbel  wrote:
> Index: gcc/config/sh/sh.c
> ===
> *** gcc/config/sh/sh.c.orig
> --- gcc/config/sh/sh.c
[snop]
> ! static void
>   sh_canonicalize_comparison (enum rtx_code& cmp, rtx& op0, rtx& op1,
> ! enum machine_mode mode,
> ! bool op0_preserve_value ATTRIBUTE_UNUSED)
>   {
> +   HOST_WIDE_INT val;
> + 

Please remove the last two lines which cause the warning:

gcc/config/sh/sh.c:1927:17: warning: unused variable 'val' [-Wunused-variable]

Regards,
kaz


Re: [patch, mips, debug] Fix PR 54061, mips compiler aborts in testsuite

2012-12-10 Thread Richard Henderson
On 12/10/2012 08:50 AM, Steve Ellcey wrote:
> 2012-12-07  Steve Ellcey  
> 
>   PR target/54061
>   rtl.h (IGNORED_DWARF_REGNUM): New.
>   * dwarf2out.c (reg_loc_descriptor): Check for IGNORED_DWARF_REGNUM.
>   (mem_loc_descriptor): Ditto.
>   * config/mips/mips.h (ALL_COP_REG_FIRST): New.
>   (ALL_COP_REG_LAST): New.
>   (ALL_COP_REG_NUM): Redefine using above macros.
>   * config/mips/mips.c (mips_option_override): Set mips_dbx_regno
>   coprocessor entries to IGNORED_DWARF_REGNUM.

Ok.


r~


Re: [PATCH] PR c++/53609 - Wrong argument deduction for pack expansion in argument pack

2012-12-10 Thread Jason Merrill

On 12/08/2012 05:12 PM, Dodji Seketeli wrote:

+  else if (arg_from_pack_level_to_prune || has_empty_arg)
+{
+  /* ... we just return a pack expansion which pattern is PATTERN
+into which ARGS has been substituted.  */
+  *instantiation_yields_no_list_p = true;
+}



Though I think it would still be appropriate to keep this 'if' just to
avoid going into the 'else' block for cases where we know that looping
over the parameter packs (and do the ARGUMENT_PACK_SELECT dance) is
unnecessary; all we want is to go straight to the point where we
substitute args into the pattern, build a pack expansion and return
it.  Or isn't what you meant?


I suppose we should keep this for has_empty_arg, but I'd like to do away 
with special handling of the arg_from_parm_pack case if possible, as 
it's a lot of extra complexity.



My understanding is that in practise, we never hit this point in the
previous code.  The reason why len would still be negative at this
point would be if we didn't find any (good) argument pack.  But in
that case, we would have considered that we have unsubstituted packs
and would have returned an unsubstituted pack expansion before we
reach this point.


I don't see that; in the old code, if there are unsubstituted packs we 
tsubst the args into the pattern.



+  /* We got some full packs, but we can't substitute them in until we
+have values for all the packs.  So remember these until then.  */


How can having this in gen_elem_of_pack_expansion_instantiation could 
work?  We don't want an expansion for each element of the packs that we 
have.


Jason



Re: [asan] Handle noreturn calls with __asan_handle_no_return ()

2012-12-10 Thread Jakub Jelinek
On Mon, Dec 10, 2012 at 10:44:49PM +0100, Dodji Seketeli wrote:
> Jakub Jelinek  writes:
> 
> > +++ gcc/asan.c  2012-12-05 15:30:56.069890542 +0100
> > @@ -1031,7 +1031,7 @@ instrument_builtin_call (gimple_stmt_ite
> >  {
> >gimple call = gsi_stmt (*iter);
> >  
> > -  gcc_assert (is_gimple_builtin_call (call));
> > +  gcc_checking_assert (is_gimple_builtin_call (call));
> 
> Why is this change necessary?

It is not necessary, just it isn't as low cost as it would be good for
an assertion, it does:
  if (is_gimple_call (stmt)
  && (callee = gimple_call_fndecl (stmt))
  && is_builtin_fn (callee)
  && DECL_BUILT_IN_CLASS (callee) == BUILT_IN_NORMAL)
return true;
and the caller calls that exact routine already:
  if (is_gimple_builtin_call (gsi_stmt (*iter)))
return instrument_builtin_call (iter);
and this is the second statement in instrument_builtin_call.

Jakub


Re: [asan] Handle noreturn calls with __asan_handle_no_return ()

2012-12-10 Thread Dodji Seketeli
Jakub Jelinek  writes:

> +++ gcc/asan.c2012-12-05 15:30:56.069890542 +0100
> @@ -1031,7 +1031,7 @@ instrument_builtin_call (gimple_stmt_ite
>  {
>gimple call = gsi_stmt (*iter);
>  
> -  gcc_assert (is_gimple_builtin_call (call));
> +  gcc_checking_assert (is_gimple_builtin_call (call));

Why is this change necessary?

The patch looks OK to me otherwise.

-- 
Dodji


Re: [PATCH i386]: Enable push/pop in pro/epilogue for modern CPUs

2012-12-10 Thread Mike Stump
On Dec 10, 2012, at 12:42 PM, Xinliang David Li  wrote:
> I have not measured the CFI size impact -- but conceivably it should
> be larger -- which is unfortunate.

Code speed and size are preferable to optimizing dwarf size…  :-)  I'd let 
dwarf 5 fix it!



Re: [PATCH i386]: Enable push/pop in pro/epilogue for modern CPUs

2012-12-10 Thread Xinliang David Li
I have not measured the CFI size impact -- but conceivably it should
be larger -- which is unfortunate.

David

On Mon, Dec 10, 2012 at 1:23 AM, Richard Biener
 wrote:
> On Sun, Dec 9, 2012 at 2:50 PM, Uros Bizjak  wrote:
>> Hello!
>>
>>> I noticed in prologue/epilogue, GCC prefers to use MOVs followed by a
>>> SP adjustment instead of a sequence of pushes/pops. The preference to
>>> the MOVs are good for old CPU micro-architectures (before pentium-4,
>>> K10), because it breaks the data dependency.  In modern
>>> micro-architecture, push/pop is implemented using a mechanism called
>>> stack engine. The data dependency is removed by the hardware, and
>>> push/pop becomes very cheap (1 uOp, 1 cycle latency), and they are
>>> smaller. There is no longer the need to avoid using them.   This is
>>> also what ICC does.
>>
>>> 2012-12-08  Xinliang David Li  
>>>* config/i386/i386.c: Eanble push/pop in pro/epilogue for 
>>> moderen CPUs.
>>
>> s/moderen/modern
>>
>> OK for mainline SVN.
>
> It's also more costly for unwind info in the prologue/epilogue.  Thus, did you
> measure the effect on CFI size?
>
> Thanks,
> Richard.
>
>> Thanks,
>> Uros.


Re: [patch, mips, testsuite] Fix gcc.target/mips/octeon-bbit-2.c for -Os

2012-12-10 Thread Richard Sandiford
Sorry for the extra-long delay on this one.

"Steve Ellcey "  writes:
> The gcc.target/octeon-bbit-2.c is failing with -Os because that optimization
> level does not do whichever optimization it is that results in a bbit instead
> of a bbit[01]l.  I would like to skip this test for -Os the way it already 
> gets
> skipped for -O0.

The point of the test is that BBIT[01]L doesn't exist; there aren't any
branch-likely variants of BBIT[01].  So we wanted to check that we could
still use branch-likely instructions for g(), but wouldn't ever generate
the invalid BBIT[01]L for the similarly-structured f().

The problem is that:

  int s = 0;
  for (; i & 1; i++)
s += i;
  return s;

isn't a very direct way of encouraging branch-likely instructions,
because it requires the i & 1 test to be duplicated.  As you say,
we legimately don't do that for -Os.  A sufficiently fancy gimple
optimiser could also figure out that the loop iterates at most once
and replace the loop with a non-iterating structure.

The patch below uses a form that doesn't require any code duplication
and which should be a bit more future-proof.  Tested on mips64-linux-gnu
and applied.

Richard


gcc/testsuite/
* gcc.target/mips/octeon-bbit-2.c: Restructure loops so that no
code duplication is required.  Allow BNE to appear.

Index: gcc/testsuite/gcc.target/mips/octeon-bbit-2.c
===
--- gcc/testsuite/gcc.target/mips/octeon-bbit-2.c   2012-08-27 
17:27:13.0 +0100
+++ gcc/testsuite/gcc.target/mips/octeon-bbit-2.c   2012-10-08 
21:23:53.416540290 +0100
@@ -4,22 +4,21 @@
 /* { dg-final { scan-assembler "\tbbit\[01\]\t" } } */
 /* { dg-final { scan-assembler-not "\tbbit\[01\]l\t" } } */
 /* { dg-final { scan-assembler "\tbnel\t" } } */
-/* { dg-final { scan-assembler-not "\tbne\t" } } */
 
 NOMIPS16 int
-f (int n, int i)
+f (int *a, int *b)
 {
-  int s = 0;
-  for (; i & 1; i++)
-s += i;
-  return s;
+  do
+if (__builtin_expect (*a & 1, 1))
+  *a = 0;
+  while (++a < b);
 }
 
 NOMIPS16 int
-g (int n, int i)
+g (int *a, int *b)
 {
-  int s = 0;
-  for (i = 0; i < n; i++)
-s += i;
-  return s;
+  do
+if (__builtin_expect (*a == 3, 1))
+  *a = 0;
+  while (++a < b);
 }


Re: [patch, mips, debug] Fix PR 54061, mips compiler aborts in testsuite

2012-12-10 Thread Cary Coutant
> 2012-12-07  Steve Ellcey  
>
> PR target/54061
> rtl.h (IGNORED_DWARF_REGNUM): New.
> * dwarf2out.c (reg_loc_descriptor): Check for IGNORED_DWARF_REGNUM.
> (mem_loc_descriptor): Ditto.
> * config/mips/mips.h (ALL_COP_REG_FIRST): New.
> (ALL_COP_REG_LAST): New.
> (ALL_COP_REG_NUM): Redefine using above macros.
> * config/mips/mips.c (mips_option_override): Set mips_dbx_regno
> coprocessor entries to IGNORED_DWARF_REGNUM.

The dwarf2out.c parts are OK.

-cary


[C++] Add missing dependency on $(PARAMS_H)

2012-12-10 Thread Eric Botcazou
When you add a new --param entry and rebuild an existing compiler, you get 
weird C++ regressions in the testsuite because of outdated object files.

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


2012-12-10  Eric Botcazou  

* Make-lang.in (cp/typeck.o): Add dependency on $(PARAMS_H).
(cp/name-lookup.o): Likewise.


-- 
Eric BotcazouIndex: Make-lang.in
===
--- Make-lang.in	(revision 194328)
+++ Make-lang.in	(working copy)
@@ -288,7 +288,7 @@ cp/cp-objcp-common.o : cp/cp-objcp-commo
   $(CXX_PRETTY_PRINT_H) cp/cp-objcp-common.h gt-cp-cp-objcp-common.h
 cp/typeck2.o: cp/typeck2.c $(CXX_TREE_H) $(TM_H) $(FLAGS_H) \
   $(TM_P_H) $(DIAGNOSTIC_CORE_H) gt-cp-typeck2.h $(REAL_H) intl.h
-cp/typeck.o: cp/typeck.c $(CXX_TREE_H) $(TM_H) $(FLAGS_H) \
+cp/typeck.o: cp/typeck.c $(CXX_TREE_H) $(TM_H) $(FLAGS_H) $(PARAMS_H) \
   toplev.h $(DIAGNOSTIC_H) convert.h $(C_COMMON_H) $(TARGET_H) \
   c-family/c-objc.h
 cp/class.o: cp/class.c $(CXX_TREE_H) $(TM_H) $(FLAGS_H) toplev.h \
@@ -342,7 +342,7 @@ cp/cp-gimplify.o: cp/cp-gimplify.c $(CXX
 	$(TM_H) coretypes.h pointer-set.h tree-iterator.h $(SPLAY_TREE_H)
 
 cp/name-lookup.o: cp/name-lookup.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \
-	$(TM_H) $(CXX_TREE_H) $(TIMEVAR_H) gt-cp-name-lookup.h \
+	$(TM_H) $(CXX_TREE_H) $(TIMEVAR_H) gt-cp-name-lookup.h $(PARAMS_H) \
 	$(DIAGNOSTIC_CORE_H) $(FLAGS_H) debug.h pointer-set.h
 
 cp/cxx-pretty-print.o: cp/cxx-pretty-print.c $(CXX_PRETTY_PRINT_H) \


Re: [patch, mips, testsuite] Fix scan on gcc.target/mips/ext-2.c

2012-12-10 Thread Richard Sandiford
"Steve Ellcey "  writes:
> In looking at the failure of gcc.target/mips/ext-2.c, it looks like the
> GCC compiler is now figuring out that it can use a 32 bit ext instruction
> instead of a 64 bit dext instruction and that this is why the test
> fails.  Here is a patch to look for 'ext' or 'dext', OK to checkin?
> It fixes the failure for me and I see no reason why GCC should not use
> the ext instruction instead of dext in this case.

Agreed, but it no longer matches the original intention of the test:

/* Turn the truncate,zero_extend,lshiftrt sequence before the or into a
   zero_extract.  The truncate is due to TARGET_PROMOTE_PROTOTYPES, the
   zero_extend to PROMOTE_MODE.  */

because we've lost the truncate.

I went for the patch below instead, after checking that the uncombined
sequence really was a truncate/zero_extend/lshiftft sequence.  Tested on
mips64-linux-gnu (where the test also failed for -mabi=n32 and -mabi=32,
but not for -mabi=64).  Applied.

Richard


gcc/testsuite/
* gcc.target/mips/ext-2.c: Require -mlong64.

Index: gcc/testsuite/gcc.target/mips/ext-2.c
===
--- gcc/testsuite/gcc.target/mips/ext-2.c   2012-08-27 17:31:22.0 
+0100
+++ gcc/testsuite/gcc.target/mips/ext-2.c   2012-12-10 19:50:25.159758211 
+
@@ -2,7 +2,7 @@
zero_extract.  The truncate is due to TARGET_PROMOTE_PROTOTYPES, the
zero_extend to PROMOTE_MODE.  */
 /* { dg-do compile } */
-/* { dg-options "isa_rev>=2 -mgp64" } */
+/* { dg-options "isa_rev>=2 -mgp64 -mlong64" } */
 /* { dg-skip-if "code quality test" { *-*-* } { "-O0" } { "" } } */
 /* { dg-final { scan-assembler "\tdext\t" } } */
 /* { dg-final { scan-assembler-not "\tand" } } */


Re: [PATCH] Bugfix: Additional parameter for canonicalize comparison

2012-12-10 Thread Oleg Endo
On Mon, 2012-12-10 at 11:22 -0800, Richard Henderson wrote:
> On 12/10/2012 01:50 AM, Andreas Krebbel wrote:
> > Ok. Here is an updated version trying to address the comments above.
> > 
> > 2012-12-10  Andreas Krebbel  
> > 
> > * target.def: Define canonicalize_comparison hook.
> > * targhooks.h (default_canonicalize_comparison): New prototype.
> > * targhooks.c (default_canonicalize_comparison): New function.
> > * doc/tm.texi: Add documentation for the new target hook.
> > * doc/tm.texi.in: Likewise.
> > * combine.c (try_combine): Adjust to use the target hook.
> > * config/alpha/alpha.h (CANONICALIZE_COMPARISON): Remove macro
> > definition.
> > * config/alpha/alpha.c (alpha_canonicalize_comparison): New
> > function.
> > (TARGET_CANONICALIZE_COMPARISON): New macro definition.
> > * config/arm/arm-protos.h (arm_canonicalize_comparison): Remove
> > prototype.
> > * config/arm/arm.c (arm_canonicalize_comparison): Add new
> > parameter.
> > (TARGET_CANONICALIZE_COMPARISON): New macro definition.
> > * config/arm/arm.h (CANONICALIZE_COMPARISON): Remove macro
> > definition.
> > * config/s390/s390-protos.h (s390_canonicalize_comparison): Remove
> > prototype.
> > * config/s390/s390.c (s390_canonicalize_comparison): Add new
> > parameter.
> > (TARGET_CANONICALIZE_COMPARISON): New macro definition.
> > * config/s390/s390.h (CANONICALIZE_COMPARISON): Remove macro
> > definition.
> > * config/sh/sh-protos.h (sh_canonicalize_comparison): Remove
> > prototype.
> > * config/sh/sh.c (sh_canonicalize_comparison): Add new prototype.  New
> > function overloading the old one.
> > (TARGET_CANONICALIZE_COMPARISON): New macro definition.
> > * config/sh/sh.h (CANONICALIZE_COMPARISON): Remove macro
> > definition.
> > * config/spu/spu.c (spu_canonicalize_comparison): New function.
> > (TARGET_CANONICALIZE_COMPARISON): New macro definition.
> > * config/spu/spu.h (CANONICALIZE_COMPARISON): Remove macro
> > definition.
> 
> Looks ok.  Although I thought Oleg was suggesting to not add a wrapper in sh,
> but to adjust the users...

No, I wasn't.  I was just mentioning the "_1" thing.  But yes, you're
right.  The users should be fixed instead.  However  

> > + /* Convenience wrapper for the canonicalize_comparison target hook.
> > +Targets hooks cannot use enum rtx_code.  */
> 
> Honestly, for 4.9 we should fix that.  Unlike machine_mode which really is
> target-specific, rtx_code is not.  It's just not defined in the right place.
> 

... I can do that in the SH code during 4.9 after the issue above has
been resolved.

Cheers,
Oleg



Re: [patch, mips] Fix -mno-shared option (gcc.target/mips/pr35802.c)

2012-12-10 Thread Andrew Pinski
On Mon, Dec 10, 2012 at 9:23 AM, Steve Ellcey  wrote:
>
> The test gcc.target/mips/pr35802.c is failing with the message:
>
> xgcc: error: unrecognized command line option '-mdsp-mno-shared'
>
> Obviously the -mdsp and -mno-shared flags got stuck together without
> a space between them.  This patch fixes the failure.  Ok to checkin?
> It was tested with no regressions.
>
> 2012-12-10  Steve Ellcey  
>
> * config/mips/gnu-user.h (NO_SHARED_SPECS): Add space before option.

I think the space should go before the %{ like most of the other SPECS
macros in that file.
So like:
# define NO_SHARED_SPECS \
  " %{mshared|mno-shared|fpic|fPIC|fpie|fPIE:;:-mno-shared}"

Thanks,
Andrew Pinski

>
>
> diff --git a/gcc/config/mips/gnu-user.h b/gcc/config/mips/gnu-user.h
> index d35ddac..55ca662 100644
> --- a/gcc/config/mips/gnu-user.h
> +++ b/gcc/config/mips/gnu-user.h
> @@ -97,7 +97,7 @@ along with GCC; see the file COPYING3.  If not see
>  #ifdef HAVE_AS_NO_SHARED
>  /* Default to -mno-shared for non-PIC.  */
>  # define NO_SHARED_SPECS \
> -  "%{mshared|mno-shared|fpic|fPIC|fpie|fPIE:;:-mno-shared}"
> +  "%{mshared|mno-shared|fpic|fPIC|fpie|fPIE:;: -mno-shared}"
>  #else
>  # define NO_SHARED_SPECS ""
>  #endif


Re: [patch, mips] Fix -mno-shared option (gcc.target/mips/pr35802.c)

2012-12-10 Thread Richard Sandiford
"Steve Ellcey "  writes:
> The test gcc.target/mips/pr35802.c is failing with the message:
>
>   xgcc: error: unrecognized command line option '-mdsp-mno-shared'
>
> Obviously the -mdsp and -mno-shared flags got stuck together without
> a space between them.  This patch fixes the failure.  Ok to checkin?
> It was tested with no regressions.

Ugh.

> diff --git a/gcc/config/mips/gnu-user.h b/gcc/config/mips/gnu-user.h
> index d35ddac..55ca662 100644
> --- a/gcc/config/mips/gnu-user.h
> +++ b/gcc/config/mips/gnu-user.h
> @@ -97,7 +97,7 @@ along with GCC; see the file COPYING3.  If not see
>  #ifdef HAVE_AS_NO_SHARED
>  /* Default to -mno-shared for non-PIC.  */
>  # define NO_SHARED_SPECS \
> -  "%{mshared|mno-shared|fpic|fPIC|fpie|fPIE:;:-mno-shared}"
> +  "%{mshared|mno-shared|fpic|fPIC|fpie|fPIE:;: -mno-shared}"
>  #else
>  # define NO_SHARED_SPECS ""
>  #endif

MARCH_MTUNE_NATIVE_SPECS puts the space after the opening quote,
so we might as well do the same here for consistency.  OK with that
change, thanks.

Richard


Ping^2: Synopsys DesignWare ARC Port

2012-12-10 Thread Joern Rennecke

This patch set hasn't been reviewed for more than two weeks:


libgcc:

2012-10-09  Joern Rennecke  

 * config.host (arc-*-elf*, arc*-*-linux-uclibc*): New configurations.
gcc:

2012-11-22  Joern Rennecke  
 Brendan Kehoe  

 * config.gcc (arc-*-elf*, arc*-*-linux-uclibc*): New configurations.
 * doc/install.texi (--with-cpu): Mention ARC.
 (arc-*-elf32): New paragraph.
 (arc-linux-uclibc): Likewise.
 * doc/md.texi (Machine Constraints): Add ARC part.
 * doc/invoke.texi: (menu): Add ARC Options.
 (Machine Dependent Options) : Add synopsis.
 (node ARC Options): Add.
 * doc/extend.texi (long_call / short_call attribute): Add ARC.

gcc/testsuite:

2012-11-22  Joern Rennecke  

 * gcc.c-torture/execute/20101011-1.c [__arc__] (DO_TEST):  
Define as 0.

 * gcc.dg/torture/pr37868.c: Also skip for arc*-*-*.
 * gcc.dg/stack-usage-1.c [__arc__] (SIZE): Define.

libstdc++-v3:

2012-08-16  Joern Rennecke  

 * acinclude.m4 (GLIBCXX_ENABLE_SJLJ_EXCEPTIONS): Also check for
 _Unwind_SjLj_Register when deciding if to set enable_sjlj_exceptions.
 * configure: Regenerate.

gcc:

2012-11-25  Saurabh Verma  
 Ramana Radhakrishnan  
 Joern Rennecke  
 Muhammad Khurram Riaz 
 Brendan Kehoe  
 Michael Eager  

 * config/arc, common/config/arc: New directories.

gcc/testsuite:

2012-08-28  Joern Rennecke  

 * gcc.target/arc: New directory.

libgcc:

2012-10-18  Joern Rennecke  
 Brendan Kehoe  

 * libgcc/config/arc: New directory.

contents of config/arc:
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg02051.html
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg02052.html
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg02055.html

Plus the other stuff from here:

http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01891.html


Re: [PATCH] Bugfix: Additional parameter for canonicalize comparison

2012-12-10 Thread Richard Henderson
On 12/10/2012 01:50 AM, Andreas Krebbel wrote:
> Ok. Here is an updated version trying to address the comments above.
> 
> 2012-12-10  Andreas Krebbel  
> 
>   * target.def: Define canonicalize_comparison hook.
>   * targhooks.h (default_canonicalize_comparison): New prototype.
>   * targhooks.c (default_canonicalize_comparison): New function.
>   * doc/tm.texi: Add documentation for the new target hook.
>   * doc/tm.texi.in: Likewise.
>   * combine.c (try_combine): Adjust to use the target hook.
>   * config/alpha/alpha.h (CANONICALIZE_COMPARISON): Remove macro
>   definition.
>   * config/alpha/alpha.c (alpha_canonicalize_comparison): New
>   function.
>   (TARGET_CANONICALIZE_COMPARISON): New macro definition.
>   * config/arm/arm-protos.h (arm_canonicalize_comparison): Remove
>   prototype.
>   * config/arm/arm.c (arm_canonicalize_comparison): Add new
>   parameter.
>   (TARGET_CANONICALIZE_COMPARISON): New macro definition.
>   * config/arm/arm.h (CANONICALIZE_COMPARISON): Remove macro
>   definition.
>   * config/s390/s390-protos.h (s390_canonicalize_comparison): Remove
>   prototype.
>   * config/s390/s390.c (s390_canonicalize_comparison): Add new
>   parameter.
>   (TARGET_CANONICALIZE_COMPARISON): New macro definition.
>   * config/s390/s390.h (CANONICALIZE_COMPARISON): Remove macro
>   definition.
>   * config/sh/sh-protos.h (sh_canonicalize_comparison): Remove
>   prototype.
>   * config/sh/sh.c (sh_canonicalize_comparison): Add new prototype.  New
>   function overloading the old one.
>   (TARGET_CANONICALIZE_COMPARISON): New macro definition.
>   * config/sh/sh.h (CANONICALIZE_COMPARISON): Remove macro
>   definition.
>   * config/spu/spu.c (spu_canonicalize_comparison): New function.
>   (TARGET_CANONICALIZE_COMPARISON): New macro definition.
>   * config/spu/spu.h (CANONICALIZE_COMPARISON): Remove macro
>   definition.

Looks ok.  Although I thought Oleg was suggesting to not add a wrapper in sh,
but to adjust the users...

> + /* Convenience wrapper for the canonicalize_comparison target hook.
> +Targets hooks cannot use enum rtx_code.  */

Honestly, for 4.9 we should fix that.  Unlike machine_mode which really is
target-specific, rtx_code is not.  It's just not defined in the right place.


r~



Re: [patch, testsuite] Fix pr35634 tests when char is unsigned.

2012-12-10 Thread Steve Ellcey
On Mon, 2012-12-10 at 20:01 +0100, Richard Biener wrote:

> 
> Ok minus the initialization.
> 
> Thanks,
> Richard.

Actually, it looks like you already fixed this last week.  I am not
seeing it in my git tree, but it is in the FSF subversion and
git trees so I think I have a local problem updating my tree.

Steve Ellcey
sell...@mips.com



Re: [patch] libgcc unwind-arm.h: mark arguments as unused

2012-12-10 Thread Ian Lance Taylor
On Sun, Dec 9, 2012 at 11:13 PM, Matthias Klose  wrote:
> This was seen and fixed on trunk building libbacktrace on arm:
> http://gcc.gnu.org/ml/gcc-patches/2012-10/msg00628.html
>
> I see this now cross building libgo targeting arm on the 4.7 branch. Ok to
> backport to the 4.7 branch?

It's fine with me.  You should technically get RM permission although
this seems safe enough.

Ian


Re: [patch, testsuite] Fix pr35634 tests when char is unsigned.

2012-12-10 Thread Richard Biener
On Mon, Dec 10, 2012 at 7:32 PM, Steve Ellcey  wrote:
> The tests gcc.dg/torture/pr35634.c and g++.dg/torture/pr35634.C fail for
> me on the mips-mti-elf target.  At first I thought it was because 'n'
> was not initialized but then I realized it was because 'char' on this
> target defaults to 'unsigned char', not 'signed char'.  Since I think
> initializing 'n' is still a good idea I made that change as well as making
> 'c' an explicitly signed char.  This now passes on mips-mti-elf.

statics are zero-initialized according to C89.

> OK for checkin?

Ok minus the initialization.

Thanks,
Richard.

> Steve Ellcey
> sell...@mips.com
>
>
> 2012-12-10  Steve Ellcey  
>
> * gcc.dg/torture/pr35634.c: Initialize n, make c signed.
> * g++.dg/torgure/pr35634.C: Ditto.
>
> diff --git a/gcc/testsuite/g++.dg/torture/pr35634.C 
> b/gcc/testsuite/g++.dg/torture/pr35634.C
> index 00848e3..1f03bb1 100644
> --- a/gcc/testsuite/g++.dg/torture/pr35634.C
> +++ b/gcc/testsuite/g++.dg/torture/pr35634.C
> @@ -5,7 +5,7 @@ extern "C" void exit (int);
>
>  void foo (int i)
>  {
> -static int n;
> +static int n = 0;
>  if (i < -128 || i > 127)
>  abort ();
>  if (++n > 1000)
> @@ -14,6 +14,6 @@ void foo (int i)
>
>  int main ()
>  {
> -char c;
> +signed char c;
>  for (c = 0; ; c++) foo (c);
>  }
> diff --git a/gcc/testsuite/gcc.dg/torture/pr35634.c 
> b/gcc/testsuite/gcc.dg/torture/pr35634.c
> index 32df7d4..f8876a4 100644
> --- a/gcc/testsuite/gcc.dg/torture/pr35634.c
> +++ b/gcc/testsuite/gcc.dg/torture/pr35634.c
> @@ -5,7 +5,7 @@ void exit (int);
>
>  void foo (int i)
>  {
> -static int n;
> +static int n = 0;
>  if (i < -128 || i > 127)
>  abort ();
>  if (++n > 1000)
> @@ -14,6 +14,6 @@ void foo (int i)
>
>  int main ()
>  {
> -char c;
> +signed char c;
>  for (c = 0; ; c++) foo (c);
>  }


[patch, testsuite] Fix pr35634 tests when char is unsigned.

2012-12-10 Thread Steve Ellcey
The tests gcc.dg/torture/pr35634.c and g++.dg/torture/pr35634.C fail for
me on the mips-mti-elf target.  At first I thought it was because 'n'
was not initialized but then I realized it was because 'char' on this
target defaults to 'unsigned char', not 'signed char'.  Since I think
initializing 'n' is still a good idea I made that change as well as making
'c' an explicitly signed char.  This now passes on mips-mti-elf.

OK for checkin?

Steve Ellcey
sell...@mips.com


2012-12-10  Steve Ellcey  

* gcc.dg/torture/pr35634.c: Initialize n, make c signed.
* g++.dg/torgure/pr35634.C: Ditto.

diff --git a/gcc/testsuite/g++.dg/torture/pr35634.C 
b/gcc/testsuite/g++.dg/torture/pr35634.C
index 00848e3..1f03bb1 100644
--- a/gcc/testsuite/g++.dg/torture/pr35634.C
+++ b/gcc/testsuite/g++.dg/torture/pr35634.C
@@ -5,7 +5,7 @@ extern "C" void exit (int);
 
 void foo (int i)
 {
-static int n;
+static int n = 0;
 if (i < -128 || i > 127)
 abort ();
 if (++n > 1000)
@@ -14,6 +14,6 @@ void foo (int i)
 
 int main ()
 {
-char c;
+signed char c;
 for (c = 0; ; c++) foo (c);
 }
diff --git a/gcc/testsuite/gcc.dg/torture/pr35634.c 
b/gcc/testsuite/gcc.dg/torture/pr35634.c
index 32df7d4..f8876a4 100644
--- a/gcc/testsuite/gcc.dg/torture/pr35634.c
+++ b/gcc/testsuite/gcc.dg/torture/pr35634.c
@@ -5,7 +5,7 @@ void exit (int);
 
 void foo (int i)
 {
-static int n;
+static int n = 0;
 if (i < -128 || i > 127)
 abort ();
 if (++n > 1000)
@@ -14,6 +14,6 @@ void foo (int i)
 
 int main ()
 {
-char c;
+signed char c;
 for (c = 0; ; c++) foo (c);
 }


Re: [patch][c++] Stop in cp_write_global_declarations after writing a PCH

2012-12-10 Thread Steven Bosscher
On Fri, Dec 7, 2012 at 3:13 PM, Richard Biener wrote:
> On Fri, Dec 7, 2012 at 10:52 AM, Steven Bosscher wrote:
>> Ping?
>
> Ok if C++ frontend maintainers don't complain over the weekend.

Committed now.
BTW I forgot to mention I also did a build+test with this patch and
with gcac checking enabled.

Ciao!
Steven


Re: application/xml mime-type in recent libstdc++ doc changes

2012-12-10 Thread Benjamin De Kosnik

> > libstdc++-v3/doc/xsl/customization.xsl.in is marked as
> > 
> >   svn:mime-type = application/xml
> > 
> > at least on the 4.7 branch, having some unexpected outcome for svn
> > diff. If this was unintended, could you change the svn:mime-type
> > back to text?

This is unintentional, and frankly I don't know how the inital mime
type was created or how to fix it. Any pointers? Can you do it and tell
me how?

best,
benjamin


[patch, mips] Fix -mno-shared option (gcc.target/mips/pr35802.c)

2012-12-10 Thread Steve Ellcey

The test gcc.target/mips/pr35802.c is failing with the message:

xgcc: error: unrecognized command line option '-mdsp-mno-shared'

Obviously the -mdsp and -mno-shared flags got stuck together without
a space between them.  This patch fixes the failure.  Ok to checkin?
It was tested with no regressions.

2012-12-10  Steve Ellcey  

* config/mips/gnu-user.h (NO_SHARED_SPECS): Add space before option.


diff --git a/gcc/config/mips/gnu-user.h b/gcc/config/mips/gnu-user.h
index d35ddac..55ca662 100644
--- a/gcc/config/mips/gnu-user.h
+++ b/gcc/config/mips/gnu-user.h
@@ -97,7 +97,7 @@ along with GCC; see the file COPYING3.  If not see
 #ifdef HAVE_AS_NO_SHARED
 /* Default to -mno-shared for non-PIC.  */
 # define NO_SHARED_SPECS \
-  "%{mshared|mno-shared|fpic|fPIC|fpie|fPIE:;:-mno-shared}"
+  "%{mshared|mno-shared|fpic|fPIC|fpie|fPIE:;: -mno-shared}"
 #else
 # define NO_SHARED_SPECS ""
 #endif


[patch, mips, testsuite] Fix scan on gcc.target/mips/ext-2.c

2012-12-10 Thread Steve Ellcey
In looking at the failure of gcc.target/mips/ext-2.c, it looks like the
GCC compiler is now figuring out that it can use a 32 bit ext instruction
instead of a 64 bit dext instruction and that this is why the test
fails.  Here is a patch to look for 'ext' or 'dext', OK to checkin?
It fixes the failure for me and I see no reason why GCC should not use
the ext instruction instead of dext in this case.

Steve Ellcey
sell...@mips.com


2012-12-10  Steve Ellcey  

* gcc.target/mips/ext-2.c: Scan for ext or dext.


diff --git a/gcc/testsuite/gcc.target/mips/ext-2.c 
b/gcc/testsuite/gcc.target/mips/ext-2.c
index 5d68bc5..6063d3b 100644
--- a/gcc/testsuite/gcc.target/mips/ext-2.c
+++ b/gcc/testsuite/gcc.target/mips/ext-2.c
@@ -4,7 +4,7 @@
 /* { dg-do compile } */
 /* { dg-options "isa_rev>=2 -mgp64" } */
 /* { dg-skip-if "code quality test" { *-*-* } { "-O0" } { "" } } */
-/* { dg-final { scan-assembler "\tdext\t" } } */
+/* { dg-final { scan-assembler "\t(dext|ext)\t" } } */
 /* { dg-final { scan-assembler-not "\tand" } } */
 /* { dg-final { scan-assembler-not "\td?srl" } } */
 


Re: [patch, mips, debug] Fix PR 54061, mips compiler aborts in testsuite

2012-12-10 Thread Steve Ellcey
On Mon, 2012-12-10 at 10:53 +, Richard Sandiford wrote:

> So please ignore that stupid suggestion.  The comments about the MIPS
> parts still stand of course.
> 
> Richard

Here is a new patch.  I made the MIPS changes and I also changed some
code in dwarf2out.c.  I was making some calls to dbx_reg_number too
early in the last patch and getting aborts during testing due to that.
I also used a variable to avoid calling it twice in a row now.  This
version passed the GCC testsuite with no regressions.

Steve Ellcey
sell...@mips.com


2012-12-07  Steve Ellcey  

PR target/54061
rtl.h (IGNORED_DWARF_REGNUM): New.
* dwarf2out.c (reg_loc_descriptor): Check for IGNORED_DWARF_REGNUM.
(mem_loc_descriptor): Ditto.
* config/mips/mips.h (ALL_COP_REG_FIRST): New.
(ALL_COP_REG_LAST): New.
(ALL_COP_REG_NUM): Redefine using above macros.
* config/mips/mips.c (mips_option_override): Set mips_dbx_regno
coprocessor entries to IGNORED_DWARF_REGNUM.

diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
index b6a2290..820b228 100644
--- a/gcc/config/mips/mips.c
+++ b/gcc/config/mips/mips.c
@@ -16757,6 +16757,9 @@ mips_option_override (void)
   for (i = FP_REG_FIRST; i <= FP_REG_LAST; i++)
 mips_dbx_regno[i] = i + start;
 
+  for (i = ALL_COP_REG_FIRST; i <= ALL_COP_REG_LAST; i++)
+mips_dbx_regno[i] = IGNORED_DWARF_REGNUM;
+
   /* Accumulator debug registers use big-endian ordering.  */
   mips_dbx_regno[HI_REGNUM] = MD_DBX_FIRST + 0;
   mips_dbx_regno[LO_REGNUM] = MD_DBX_FIRST + 1;
diff --git a/gcc/config/mips/mips.h b/gcc/config/mips/mips.h
index 308b59b..60b26cb 100644
--- a/gcc/config/mips/mips.h
+++ b/gcc/config/mips/mips.h
@@ -1641,8 +1641,11 @@ struct mips_cpu_info {
 #define COP3_REG_FIRST 144
 #define COP3_REG_LAST 175
 #define COP3_REG_NUM (COP3_REG_LAST - COP3_REG_FIRST + 1)
-/* ALL_COP_REG_NUM assumes that COP0,2,and 3 are numbered consecutively.  */
-#define ALL_COP_REG_NUM (COP3_REG_LAST - COP0_REG_FIRST + 1)
+
+/* These definitions assume that COP0, 2 and 3 are numbered consecutively.  */
+#define ALL_COP_REG_FIRST COP0_REG_FIRST
+#define ALL_COP_REG_LAST COP3_REG_LAST
+#define ALL_COP_REG_NUM (ALL_COP_REG_LAST - ALL_COP_REG_FIRST + 1)
 
 #define DSP_ACC_REG_FIRST 176
 #define DSP_ACC_REG_LAST 181
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index f0256ae..c92fa4b 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -10499,7 +10499,12 @@ reg_loc_descriptor (rtx rtl, enum var_init_status 
initialized)
   if (hard_regno_nregs[REGNO (rtl)][GET_MODE (rtl)] > 1 || regs)
 return multiple_reg_loc_descriptor (rtl, regs, initialized);
   else
-return one_reg_loc_descriptor (dbx_reg_number (rtl), initialized);
+{
+  unsigned int dbx_regnum = dbx_reg_number (rtl);
+  if (dbx_regnum == IGNORED_DWARF_REGNUM)
+   return 0;
+  return one_reg_loc_descriptor (dbx_regnum, initialized);
+}
 }
 
 /* Return a location descriptor that designates a machine register for
@@ -11926,6 +11931,7 @@ mem_loc_descriptor (rtx rtl, enum machine_mode mode,
  ))
{
  dw_die_ref type_die;
+ unsigned int dbx_regnum;
 
  if (dwarf_strict)
break;
@@ -11935,8 +11941,12 @@ mem_loc_descriptor (rtx rtl, enum machine_mode mode,
 GET_MODE_CLASS (mode) == MODE_INT);
  if (type_die == NULL)
break;
+
+ dbx_regnum = dbx_reg_number (rtl);
+ if (dbx_regnum == IGNORED_DWARF_REGNUM)
+   break;
  mem_loc_result = new_loc_descr (DW_OP_GNU_regval_type,
- dbx_reg_number (rtl), 0);
+ dbx_regnum, 0);
  mem_loc_result->dw_loc_oprnd2.val_class = dw_val_class_die_ref;
  mem_loc_result->dw_loc_oprnd2.v.val_die_ref.die = type_die;
  mem_loc_result->dw_loc_oprnd2.v.val_die_ref.external = 0;
@@ -12138,9 +12148,13 @@ mem_loc_descriptor (rtx rtl, enum machine_mode mode,
op0 = mem_loc_descriptor (ENTRY_VALUE_EXP (rtl), mode,
  VOIDmode, VAR_INIT_STATUS_INITIALIZED);
  else
-   op0
- = one_reg_loc_descriptor (dbx_reg_number (ENTRY_VALUE_EXP (rtl)),
-   VAR_INIT_STATUS_INITIALIZED);
+   {
+  unsigned int dbx_regnum = dbx_reg_number (ENTRY_VALUE_EXP (rtl));
+ if (dbx_regnum == IGNORED_DWARF_REGNUM)
+   return NULL;
+ op0 = one_reg_loc_descriptor (dbx_regnum,
+   VAR_INIT_STATUS_INITIALIZED);
+   }
}
   else if (MEM_P (ENTRY_VALUE_EXP (rtl))
   && REG_P (XEXP (ENTRY_VALUE_EXP (rtl), 0)))
diff --git a/gcc/rtl.h b/gcc/rtl.h
index a0fb4f7..5b9ceb8 100644
--- a/gcc/rtl.h
+++ b/gcc/rtl.h
@@ -2439,6 +2439,9 @@ extern rtx gen_rtx_MEM (enum machine_mode, rtx);
 /* REGNUM never really app

Re: [PING][PATCH][RFC] Bug handling SUBREG (MEM) - MEM having side-effects?

2012-12-10 Thread Tejas Belagod

PING.

Tejas Belagod wrote:

Richard Sandiford wrote:

After the discussions Richard Earnshaw had on IRC with Andrew Pinski, it was
felt that it was best to fix the standard predicate
'general_operand' to not allow SUBREG (MEM) with side-effects as it has known
issues associated with it - particularly reload not being able to deal with such
cases. 'general_operand' currently outlaws cases like paradoxical SUBREG (MEM)
on targets with insn scheduling and SUBREG (MEM) with non-zero SUBREG_BYTE. This
is another case it should not allow. Here is a patch that tightens
general_operands to not allow SUBREG (MEM) with MEM having side-effects.

I would like to hear some thoughts on this.

LGTM.

It would be good to get rid of subreg mem operands altogether at some point,
but that's a little too drastic for stage 3.  This patch looks like a strict
improvement.



Thanks for looking at this. Is this OK for 4.7 as well?

Tejas Belagod
ARM.







Re: [AARCH64-4.7, PATCH, committed] Fix race in parallel build.

2012-12-10 Thread Richard Earnshaw

On 21/11/12 13:31, Marcus Shawcroft wrote:

I've just committed the attached back port of:

http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01775.html

to the ARM/aarch64-4.7-branch.

/Marcus

2012-11-21  Marcus Shawcroft  

* Makefile.in (gengtype-lex.o): Add dependency on $(BCONFIG_H).


backport-aarch64-4.7-fix-parallel.patch


Index: gcc/Makefile.in
===
--- gcc/Makefile.in (revision 193692)
+++ gcc/Makefile.in (revision 193693)
@@ -3888,7 +3888,7 @@
$(SYSTEM_H) coretypes.h $(GTM_H) errors.h $(READ_MD_H) gensupport.h
  build/gengenrtl.o : gengenrtl.c $(BCONFIG_H) $(SYSTEM_H) rtl.def
  gengtype-lex.o build/gengtype-lex.o : gengtype-lex.c gengtype.h $(SYSTEM_H)
-gengtype-lex.o: $(CONFIG_H)
+gengtype-lex.o: $(CONFIG_H) $(BCONFIG_H)
  build/gengtype-lex.o: $(BCONFIG_H)
  gengtype-parse.o build/gengtype-parse.o : gengtype-parse.c gengtype.h \
$(SYSTEM_H)



Is this also needed on the other release branches?

R.



Re: [Fortran, (RFC) patch] PR49110/51055 Assignment to alloc. deferred-length character vars

2012-12-10 Thread David Edelsohn
On Mon, Dec 10, 2012 at 10:54 AM, Jakub Jelinek  wrote:
> On Mon, Dec 10, 2012 at 10:49:57AM -0500, David Edelsohn wrote:
>> On Mon, Dec 10, 2012 at 5:05 AM, Jakub Jelinek  wrote:
>> > On Mon, Dec 10, 2012 at 10:56:58AM +0100, Janus Weil wrote:
>> >> > For C and C++, identifiers beginning with underscore and upper case
>> >> > letter or with two underscores are reserve to the implementation.
>> >>
>> >> See the previous discussion in this thread ...
>> >
>> > That's true, but the implementation isn't just GCC, it is also C libraries
>> > which aren't provided by GCC.  Including a character (if possible) that
>> > will make it unaccessible from C/C++ is desirable.  And, not changing the
>> > names of non-TREE_STATIC vars is also desirable, those I'm afraid show up
>> > in the debug info from time to time, so making them unnecessarily larger
>> > results in .debug_info size increases.
>>
>> An earlier suggestion was "_F." .  Maybe gfortran.h should follow the
>> same logic as gcc/defaults.h and gcc/cp/cp-tree.h:
>>
>> #ifndef NO_DOT_IN_LABEL
>> "_F."
>> #else
>> #ifndef NO_DOLLAR_IN_LABEL
>> "_F$"
>> #else
>> "_F_"
>> #endif
>> #endif
>
> Sure, we my
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55636
> comment.

Yes, I agree with the intention. The remaining question is if this
concept should be applied to all of the mangling with the new macro in
gfortran.h.

- David


[google/gcc-4_7] Backport r193747 to using working set for bb hotness (issue6907063)

2012-12-10 Thread Teresa Johnson
This is a backport of r193747 to use the working set from the profile summary
to determine the bb hot count threshold.

Bootstrapped and tested on x86_64-unknown-linux-gnu. Ok for google 4_7 branch?

Thanks,
Teresa

2012-12-10  Teresa Johnson  

Backport r193747 from trunk:

2012-11-22  Teresa Johnson  
Jan Hubicka  

* predict.c (maybe_hot_count_p): Use threshold from profiled working
set instead of hard limit.
(cgraph_maybe_hot_edge_p): Invoke maybe_hot_count_p() instead of
directly checking limit.
* params.def (HOT_BB_COUNT_FRACTION): Remove.
(HOT_BB_COUNT_WS_PERMILLE): New parameter.
* doc/invoke.texi (hot-bb-count-fraction): Remove.
(hot-bb-count-ws-permille): Document.


Index: doc/invoke.texi
===
--- doc/invoke.texi (revision 194315)
+++ doc/invoke.texi (working copy)
@@ -9307,9 +9307,9 @@ ftree-vect-loop-version for more information.
 The maximum number of iterations of a loop the brute force algorithm
 for analysis of # of iterations of the loop tries to evaluate.
 
-@item hot-bb-count-fraction
-Select fraction of the maximal count of repetitions of basic block in program
-given basic block needs to have to be considered hot.
+@item hot-bb-count-ws-permille
+A basic block profile count is considered hot if it contributes to 
+the given permillage (i.e. 0...1000) of the entire profiled execution.
 
 @item hot-bb-frequency-fraction
 Select fraction of the entry block frequency of executions of basic block in
Index: predict.c
===
--- predict.c   (revision 194315)
+++ predict.c   (working copy)
@@ -137,13 +137,20 @@ maybe_hot_frequency_p (int freq)
 bool
 maybe_hot_count_p (gcov_type count)
 {
+  gcov_working_set_t *ws = NULL;
+  static gcov_type min_count = -1;
   if (!profile_info)
 return false;
   /* Code executed at most once is not hot.  */
   if (profile_info->runs >= count)
 return false;
-  return (count
- > profile_info->sum_max / PARAM_VALUE (HOT_BB_COUNT_FRACTION));
+  if (min_count == -1)
+{
+  ws = find_working_set (PARAM_VALUE (HOT_BB_COUNT_WS_PERMILLE));
+  gcc_assert (ws);
+  min_count = ws->min_counter;
+}
+  return (count >= min_count);
 }
 
 /* Return true in case BB can be CPU intensive and should be optimized
@@ -163,8 +170,7 @@ bool
 cgraph_maybe_hot_edge_p (struct cgraph_edge *edge)
 {
   if (profile_info && flag_branch_probabilities
-  && (edge->count
- <= profile_info->sum_max / PARAM_VALUE (HOT_BB_COUNT_FRACTION)))
+  && !maybe_hot_count_p (edge->count))
 return false;
   if (edge->caller->frequency == NODE_FREQUENCY_UNLIKELY_EXECUTED
   || edge->callee->frequency == NODE_FREQUENCY_UNLIKELY_EXECUTED)
Index: params.def
===
--- params.def  (revision 194315)
+++ params.def  (working copy)
@@ -424,10 +424,11 @@ DEFPARAM(PARAM_SMS_LOOP_AVERAGE_COUNT_THRESHOLD,
 "A threshold on the average loop count considered by the swing modulo 
scheduler",
 0, 0, 0)
 
-DEFPARAM(HOT_BB_COUNT_FRACTION,
-"hot-bb-count-fraction",
-"Select fraction of the maximal count of repetitions of basic block in 
program given basic block needs to have to be considered hot",
-6, 0, 0)
+DEFPARAM(HOT_BB_COUNT_WS_PERMILLE,
+"hot-bb-count-ws-permille",
+ "A basic block profile count is considered hot if it contributes to "
+ "the given permillage of the entire profiled execution",
+999, 0, 1000)
 DEFPARAM(HOT_BB_FREQUENCY_FRACTION,
 "hot-bb-frequency-fraction",
 "Select fraction of the maximal frequency of executions of basic block 
in function given basic block needs to have to be considered hot",
@@ -451,7 +452,7 @@ DEFPARAM (PARAM_ALIGN_LOOP_ITERATIONS,
flatten the profile.
 
We need to cut the maximal predicted iterations to large enough iterations
-   so the loop appears important, but safely within HOT_BB_COUNT_FRACTION
+   so the loop appears important, but safely within maximum hotness
range.  */
 
 DEFPARAM(PARAM_MAX_PREDICTED_ITERATIONS,

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


Re: [Fortran, (RFC) patch] PR49110/51055 Assignment to alloc. deferred-length character vars

2012-12-10 Thread Jakub Jelinek
On Mon, Dec 10, 2012 at 10:49:57AM -0500, David Edelsohn wrote:
> On Mon, Dec 10, 2012 at 5:05 AM, Jakub Jelinek  wrote:
> > On Mon, Dec 10, 2012 at 10:56:58AM +0100, Janus Weil wrote:
> >> > For C and C++, identifiers beginning with underscore and upper case
> >> > letter or with two underscores are reserve to the implementation.
> >>
> >> See the previous discussion in this thread ...
> >
> > That's true, but the implementation isn't just GCC, it is also C libraries
> > which aren't provided by GCC.  Including a character (if possible) that
> > will make it unaccessible from C/C++ is desirable.  And, not changing the
> > names of non-TREE_STATIC vars is also desirable, those I'm afraid show up
> > in the debug info from time to time, so making them unnecessarily larger
> > results in .debug_info size increases.
> 
> An earlier suggestion was "_F." .  Maybe gfortran.h should follow the
> same logic as gcc/defaults.h and gcc/cp/cp-tree.h:
> 
> #ifndef NO_DOT_IN_LABEL
> "_F."
> #else
> #ifndef NO_DOLLAR_IN_LABEL
> "_F$"
> #else
> "_F_"
> #endif
> #endif

Sure, we my
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55636
comment.

Jakub


Re: [Fortran, (RFC) patch] PR49110/51055 Assignment to alloc. deferred-length character vars

2012-12-10 Thread David Edelsohn
On Mon, Dec 10, 2012 at 5:05 AM, Jakub Jelinek  wrote:
> On Mon, Dec 10, 2012 at 10:56:58AM +0100, Janus Weil wrote:
>> > For C and C++, identifiers beginning with underscore and upper case
>> > letter or with two underscores are reserve to the implementation.
>>
>> See the previous discussion in this thread ...
>
> That's true, but the implementation isn't just GCC, it is also C libraries
> which aren't provided by GCC.  Including a character (if possible) that
> will make it unaccessible from C/C++ is desirable.  And, not changing the
> names of non-TREE_STATIC vars is also desirable, those I'm afraid show up
> in the debug info from time to time, so making them unnecessarily larger
> results in .debug_info size increases.

An earlier suggestion was "_F." .  Maybe gfortran.h should follow the
same logic as gcc/defaults.h and gcc/cp/cp-tree.h:

#ifndef NO_DOT_IN_LABEL
"_F."
#else
#ifndef NO_DOLLAR_IN_LABEL
"_F$"
#else
"_F_"
#endif
#endif

Thanks, David


Re: [Fortran, (RFC) patch] PR49110/51055 Assignment to alloc. deferred-length character vars

2012-12-10 Thread David Edelsohn
On Mon, Dec 10, 2012 at 4:22 AM, Janus Weil  wrote:
> 2012/12/10 David Edelsohn :
>> There has been no progress on this bug for over two months.  I have
>> opened PR fortran/55636.  This must be fixed before GCC 4.8 ships.
>
> Thanks for pinging, David. I almost forgot about it ...
>
> Here is a re-diffed version of my previous patch. I'd be grateful for
> comments. In particular: Does it fix all the problems on AIX? (For
> more open questions, see below.)

Janus,

Anything that changes the mangling of the symbols referenced in
fortran/trans-decl.c will fix the problem on AIX.

Thanks, David


[PATCH] Fix PR55079

2012-12-10 Thread Richard Biener

This improves VRP so that two of the three (the remaining one invalid
IMHO) spurious array-bound warnings in PR55079 no longer appear.
With the patch we now properly handle

  MIN_EXPR <[1, 6], VARYING>

and register asserts for i_2 in

  i_2 = i_1 + 1;
  if (i_1 != 0)

which is a common pattern from tests of post-modify expressions.

For gcc.dg/tree-ssa/ssa-pre-1.c this is too fancy and thus I needed
to adjust the testcase to avoid VRP being too clever.

Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.

Richard.

2012-12-10  Richard Biener  

PR tree-optimization/55079
* tree-vrp.c (extract_range_from_binary_expr_1): Handle MAX/MIN_EXPR
for more cases.
(register_edge_assert_for_2): Register asserts for post-in/decrement
tests.
(check_array_ref): Dump what expression we emit array bound
warnings for.
(search_for_addr_array): Likewise.

* gcc.dg/Warray-bounds-9.c: New testcase.
* gcc.dg/Warray-bounds-10.c: Likewise.
* gcc.dg/tree-ssa/ssa-pre-1.c: Adjust.

Index: gcc/tree-vrp.c
===
*** gcc/tree-vrp.c  (revision 194358)
--- gcc/tree-vrp.c  (working copy)
*** extract_range_from_binary_expr_1 (value_
*** 2349,2354 
--- 2349,2356 
&& code != EXACT_DIV_EXPR
&& code != ROUND_DIV_EXPR
&& code != TRUNC_MOD_EXPR
+   && code != MIN_EXPR
+   && code != MAX_EXPR
&& (vr0.type == VR_VARYING
  || vr1.type == VR_VARYING
  || vr0.type != vr1.type
*** extract_range_from_binary_expr_1 (value_
*** 2602,2622 
else if (code == MIN_EXPR
   || code == MAX_EXPR)
  {
!   if (vr0.type == VR_ANTI_RANGE)
{
! /* For MIN_EXPR and MAX_EXPR with two VR_ANTI_RANGEs,
!the resulting VR_ANTI_RANGE is the same - intersection
!of the two ranges.  */
! min = vrp_int_const_binop (MAX_EXPR, vr0.min, vr1.min);
! max = vrp_int_const_binop (MIN_EXPR, vr0.max, vr1.max);
}
else
{
! /* For operations that make the resulting range directly
!proportional to the original ranges, apply the operation to
!the same end of each range.  */
! min = vrp_int_const_binop (code, vr0.min, vr1.min);
! max = vrp_int_const_binop (code, vr0.max, vr1.max);
}
  }
else if (code == MULT_EXPR)
--- 2604,2652 
else if (code == MIN_EXPR
   || code == MAX_EXPR)
  {
!   if (vr0.type == VR_RANGE
! && !symbolic_range_p (&vr0))
{
! type = VR_RANGE;
! if (vr1.type == VR_RANGE
! && !symbolic_range_p (&vr1))
!   {
! /* For operations that make the resulting range directly
!proportional to the original ranges, apply the operation to
!the same end of each range.  */
! min = vrp_int_const_binop (code, vr0.min, vr1.min);
! max = vrp_int_const_binop (code, vr0.max, vr1.max);
!   }
! else if (code == MIN_EXPR)
!   {
! min = vrp_val_min (expr_type);
! max = vr0.max;
!   }
! else if (code == MAX_EXPR)
!   {
! min = vr0.min;
! max = vrp_val_max (expr_type);
!   }
!   }
!   else if (vr1.type == VR_RANGE
!  && !symbolic_range_p (&vr1))
!   {
! type = VR_RANGE;
! if (code == MIN_EXPR)
!   {
! min = vrp_val_min (expr_type);
! max = vr1.max;
!   }
! else if (code == MAX_EXPR)
!   {
! min = vr1.min;
! max = vrp_val_max (expr_type);
!   }
}
else
{
! set_value_range_to_varying (vr);
! return;
}
  }
else if (code == MULT_EXPR)
*** register_edge_assert_for_2 (tree name, e
*** 4707,4712 
--- 4737,4781 
}
  }
  
+   /* In the case of post-in/decrement tests like if (i++) ... and uses
+  of the in/decremented value on the edge the extra name we want to
+  assert for is not on the def chain of the name compared.  Instead
+  it is in the set of use stmts.  */
+   if ((comp_code == NE_EXPR
+|| comp_code == EQ_EXPR)
+   && TREE_CODE (val) == INTEGER_CST)
+ {
+   imm_use_iterator ui;
+   gimple use_stmt;
+   FOR_EACH_IMM_USE_STMT (use_stmt, ui, name)
+   {
+ /* Cut off to use-stmts that are in the predecessor.  */
+ if (gimple_bb (use_stmt) != e->src)
+   continue;
+ 
+ if (!is_gimple_assign (use_stmt))
+   continue;
+ 
+ enum tree_code code = gimple_assign_rhs_code (use_stmt);
+ if (code != PLUS_EXPR
+ && code != MINUS_EXPR)
+   continue;
+ 
+ tree cst = gimple_assign_rhs2 (use_stmt);
+ if (TREE_CODE (cs

Re: PATCH: PR lto/55466: Revision 191466 destroyed DWARF debug info

2012-12-10 Thread H.J. Lu
On Mon, Dec 10, 2012 at 1:09 AM, Richard Biener
 wrote:
> On Fri, Dec 7, 2012 at 11:59 PM, H.J. Lu  wrote:
>> Hi,
>>
>> Since revision 191466, LTO no longer maintains its own symbol table and
>> it uses varpool for variables instead.  As the result, debug info on
>> variables is lost when GCC is configured with
>>
>> --enable-bootstrap --with-build-config=bootstrap-lto
>>
>> This patch record the global variables if WPA isn't enabled.  It
>> works when GCC is configured with
>>
>> --enable-bootstrap --with-build-config=bootstrap-lto 
>> --enable-languages=c,c++,fortran,java,lto,objc,obj-c++
>>
>> However, when go is added, I got
>>
>> lto1: internal compiler error: in add_AT_specification, at
>> dwarf2out.c:3985
>> 0x629ad9 add_AT_specification
>> /export/gnu/import/git/gcc/gcc/dwarf2out.c:3985
>> 0x64dabb gen_variable_die
>> /export/gnu/import/git/gcc/gcc/dwarf2out.c:18327
>> 0x65336b gen_decl_die
>> /export/gnu/import/git/gcc/gcc/dwarf2out.c:20033
>> 0x653fcd dwarf2out_decl(tree_node*)
>> /export/gnu/import/git/gcc/gcc/dwarf2out.c:20348
>> 0x6535f9 dwarf2out_global_decl
>> /export/gnu/import/git/gcc/gcc/dwarf2out.c:20083
>> 0x997703 emit_debug_global_declarations(tree_node**, int)
>> /export/gnu/import/git/gcc/gcc/toplev.c:530
>> 0x521aaa lto_write_globals
>> /export/gnu/import/git/gcc/gcc/lto/lto-lang.c:1067
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> Please include the complete backtrace with any bug report.
>> See  for instructions.
>> make[6]: *** [/tmp/cc3yYR7d.ltrans4.ltrans.o] Error 1
>> lto-wrapper: make returned 2 exit status
>> /usr/local/x86_64-unknown-linux-gnu/bin/ld: lto-wrapper failed
>> collect2: error: ld returned 1 exit status
>> make[5]: *** [go1] Error 1
>>
>> This is latent without my patch since no DWARF info on varaibles are
>>  generated.  OK to install?
>>
>> Thanks.
>>
>>
>> H.J.
>> ---
>> 2012-12-07  H.J. Lu  
>>
>> PR lto/55466
>> * lto-symtab.c (lto_symtab_merge_decls_1): Don't record
>> the prevailing variable.
>> * lto.c (lto_main): Record the global variables if WPA isn't
>> enabled.
>>
>> diff --git a/gcc/lto-symtab.c b/gcc/lto-symtab.c
>> index 0b0cdac..295fd37 100644
>> --- a/gcc/lto-symtab.c
>> +++ b/gcc/lto-symtab.c
>> @@ -443,10 +443,6 @@ lto_symtab_merge_decls_1 (symtab_node first)
>>
>>symtab_prevail_in_asm_name_hash (prevailing);
>>
>> -  /* Record the prevailing variable.  */
>> -  if (TREE_CODE (prevailing->symbol.decl) == VAR_DECL)
>> -vec_safe_push (lto_global_var_decls, prevailing->symbol.decl);
>> -
>
> As this is not necessary, the push in lto.c:lto_register_var_decl_in_symtab
> for statics should not be necessary either (we even call
> rest_of_decl_compilation
> there).
>
> Ok with that push removed as well.

Done.

> Please make sure to file a bugreport for the go LTO bootstrap issue.
>

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

-- 
H.J.


Re: [patch] don't build multilib libraries during bootstrap, and disable some libstdc++ features

2012-12-10 Thread H.J. Lu
On Mon, Dec 10, 2012 at 5:53 AM, Matthias Klose  wrote:
> Am 10.12.2012 13:16, schrieb Matthias Klose:
>> During bootstrap some things are built which are not required for the 
>> bootstrap:
>>
>>  - multilib libraries
>>  - libstdc++ debug library, when configured with --enable-libstdcxx-debug
>>  - libstdc++ precompiled header files
>>
>> The attached patch disables building these during the bootstrap stages. The
>> additional dependencies on all-target-libgcc are necessary for multilib'd
>> builds, or else the configury bails out finding the wrong libgcc. I can't 
>> see a
>> way to add these dependencies for the multilib enabled build only.
>
> Here is a reduced version which keeps building the multilibs, maybe better
> suited for stage3.
>

Can I still use -m32 with stage1 and stage2 compilers on
Linux/x86-64?


-- 
H.J.


[PATCH] Fix PR55107

2012-12-10 Thread Richard Biener

This fixes PR55107 - the way we dealt with fully redundant values
found by PRE phi-translation breaks existing SETs, so don't special
case it in a hacky way but instead create a simple assignment.

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

Richard.

2012-12-10  Richard Biener  

PR tree-optimization/55107
* tree-ssa-pre.c (struct pre_stats): Remove constified field.
(bitmap_set_replace_value): Add gcc_unreachable.
(do_regular_insertion): Re-write all_same handling.  Insert
an assignment instead of a PHI in this case.
(eliminate_bb): Record availability also for SSA names defined
by a constant.
(do_pre): Do not record constified events.
(execute_fre): Likewise.

* gcc.dg/torture/pr55107.c: New testcase.
* gcc.dg/tree-ssa/ssa-pre-5.c: Adjust.

Index: gcc/tree-ssa-pre.c
===
*** gcc/tree-ssa-pre.c  (revision 194345)
--- gcc/tree-ssa-pre.c  (working copy)
*** static struct
*** 446,455 
  
/* The number of new PHI nodes added by PRE.  */
int phis;
- 
-   /* The number of values found constant.  */
-   int constified;
- 
  } pre_stats;
  
  static bool do_partial_partial;
--- 446,451 
*** bitmap_set_replace_value (bitmap_set_t s
*** 867,872 
--- 863,870 
  return;
}
  }
+ 
+   gcc_unreachable ();
  }
  
  /* Return true if two bitmap sets are equal.  */
*** do_regular_insertion (basic_block block,
*** 3325,3331 
  
FOR_EACH_VEC_ELT (exprs, i, expr)
  {
!   if (expr->kind != NAME)
{
  unsigned int val;
  bool by_some = false;
--- 3323,3330 
  
FOR_EACH_VEC_ELT (exprs, i, expr)
  {
!   if (expr->kind == NARY
! || expr->kind == REFERENCE)
{
  unsigned int val;
  bool by_some = false;
*** do_regular_insertion (basic_block block,
*** 3435,3469 
  /* If all edges produce the same value and that value is
 an invariant, then the PHI has the same value on all
 edges.  Note this.  */
! else if (!cant_insert && all_same && eprime
!  && (edoubleprime->kind == CONSTANT
!  || edoubleprime->kind == NAME)
!  && !value_id_constant_p (val))
{
! unsigned int j;
! bitmap_iterator bi;
! bitmap exprset = value_expressions[val];
! 
! unsigned int new_val = get_expr_value_id (edoubleprime);
! EXECUTE_IF_SET_IN_BITMAP (exprset, 0, j, bi)
!   {
! pre_expr expr = expression_for_id (j);
  
! if (expr->kind == NAME)
!   {
! vn_ssa_aux_t info = VN_INFO (PRE_EXPR_NAME (expr));
! /* Just reset the value id and valnum so it is
!the same as the constant we have discovered.  */
! if (edoubleprime->kind == CONSTANT)
!   {
! info->valnum = PRE_EXPR_CONSTANT (edoubleprime);
! pre_stats.constified++;
!   }
! else
!   info->valnum = VN_INFO (PRE_EXPR_NAME 
(edoubleprime))->valnum;
! info->value_id = new_val;
!   }
!   }
}
}
  }
--- 3434,3461 
  /* If all edges produce the same value and that value is
 an invariant, then the PHI has the same value on all
 edges.  Note this.  */
! else if (!cant_insert && all_same)
{
! gcc_assert (edoubleprime->kind == CONSTANT
! || edoubleprime->kind == NAME);
  
! tree temp = make_temp_ssa_name (get_expr_type (expr),
! NULL, "pretmp");
! gimple assign = gimple_build_assign (temp,
!  edoubleprime->kind == 
CONSTANT ? PRE_EXPR_CONSTANT (edoubleprime) : PRE_EXPR_NAME (edoubleprime));
! gimple_stmt_iterator gsi = gsi_after_labels (block);
! gsi_insert_before (&gsi, assign, GSI_NEW_STMT);
! 
! gimple_set_plf (assign, NECESSARY, false);
! VN_INFO_GET (temp)->value_id = val;
! VN_INFO (temp)->valnum = sccvn_valnum_from_value_id (val);
! if (VN_INFO (temp)->valnum == NULL_TREE)
!   VN_INFO (temp)->valnum = temp;
! bitmap_set_bit (inserted_exprs, SSA_NAME_VERSION (temp));
! pre_expr newe = get_or_alloc_expr_for_name (temp);
! add_to_value (val, newe);
! bitmap_value_replace_in_set (AVAIL_OUT (block), newe);
! bitmap_insert_into_set (NEW_SETS (block), newe);
}
}
  }
*** do_partial_partial_i

Re: [patch] don't build multilib libraries during bootstrap, and disable some libstdc++ features

2012-12-10 Thread Matthias Klose
Am 10.12.2012 13:16, schrieb Matthias Klose:
> During bootstrap some things are built which are not required for the 
> bootstrap:
> 
>  - multilib libraries
>  - libstdc++ debug library, when configured with --enable-libstdcxx-debug
>  - libstdc++ precompiled header files
> 
> The attached patch disables building these during the bootstrap stages. The
> additional dependencies on all-target-libgcc are necessary for multilib'd
> builds, or else the configury bails out finding the wrong libgcc. I can't see 
> a
> way to add these dependencies for the multilib enabled build only.

Here is a reduced version which keeps building the multilibs, maybe better
suited for stage3.

  Matthias


Index: Makefile.tpl
===
--- Makefile.tpl	(Revision 194357)
+++ Makefile.tpl	(Arbeitskopie)
@@ -1060,7 +1060,9 @@
 	  --target=[+target_alias+] $${srcdiroption} [+ IF prev +]\
 	  --with-build-libsubdir=$(HOST_SUBDIR) [+ ENDIF prev +]\
 	  $(STAGE[+id+]_CONFIGURE_FLAGS)[+ IF extra_configure_flags +] \
-	  [+extra_configure_flags+][+ ENDIF extra_configure_flags +]
+	  [+extra_configure_flags+][+ ENDIF extra_configure_flags +] \
+	  [+ IF bootstrap_configure_flags +][+bootstrap_configure_flags+] \
+	  [+ ENDIF bootstrap_configure_flags +]
 @endif [+prefix+][+module+]-bootstrap
 [+ ENDFOR bootstrap_stage +]
 [+ ENDIF bootstrap +]
Index: Makefile.def
===
--- Makefile.def	(Revision 194357)
+++ Makefile.def	(Arbeitskopie)
@@ -117,7 +117,8 @@
 target_modules = { module= libstdc++-v3;
 		   bootstrap=true;
 		   lib_path=src/.libs;
-		   raw_cxx=true; };
+		   raw_cxx=true;
+		   bootstrap_configure_flags='--disable-libstdcxx-debug --disable-libstdcxx-pch'; };
 target_modules = { module= libmudflap; lib_path=.libs; };
 target_modules = { module= libsanitizer; lib_path=.libs; };
 target_modules = { module= libssp; lib_path=.libs; };


Re: [patch] don't build multilib libraries during bootstrap, and disable some libstdc++ features

2012-12-10 Thread Richard Biener
On Mon, Dec 10, 2012 at 1:18 PM, Andrew Pinski  wrote:
> On Mon, Dec 10, 2012 at 4:16 AM, Matthias Klose  wrote:
>> During bootstrap some things are built which are not required for the 
>> bootstrap:
>>
>>  - multilib libraries
>>  - libstdc++ debug library, when configured with --enable-libstdcxx-debug
>>  - libstdc++ precompiled header files
>>
>> The attached patch disables building these during the bootstrap stages. The
>> additional dependencies on all-target-libgcc are necessary for multilib'd
>> builds, or else the configury bails out finding the wrong libgcc. I can't 
>> see a
>> way to add these dependencies for the multilib enabled build only.
>>
>> Ok for the trunk?
>
> Does this work when someone supplies BOOT_CFLAGS a multlib option like
> say -m32 ?

I don't think that was ever supported without adjusting the target/host triplet
to i686-linux for example.  Was it?

Richard.

> Thanks,
> Andrew Pinski


Re: [PATCH] SPU: Fix build failure on 64 bit hosts

2012-12-10 Thread Richard Biener
On Mon, Dec 10, 2012 at 12:31 PM, Andreas Krebbel
 wrote:
> Hi,
>
> building an SPU compiler on a 64 bit host system currently fails with:
>
> spu.md:4394: error: cast from ‘rtx_def**’ to ‘int’ loses precision
>
> In the SPU backend several patterns mention the operands array in the
> insn condition in order to prevent a warning about missing modes to be
> issued.  Interpreting the term "operands" as condition fails when it
> is evaluated on a 64 bit host.  Turning it into a comparison fixes
> this for me.
>
> Ok to apply?

Looks obvious to me.  It even looks less weird this way.

Thanks,
Richard.

> Bye,
>
> -Andreas-
>
>
> 2012-12-10  Andreas Krebbel  
>
> * config/spu/spu.md: Replace "operands" with "operands != NULL" in
> insn conditions.
>
> ---
>  gcc/config/spu/spu.md |   16 
>  1 file changed, 16 modifications(!)
>
> Index: gcc/config/spu/spu.md
> ===
> *** gcc/config/spu/spu.md.orig
> --- gcc/config/spu/spu.md
> ***
> *** 1066,1072 
> [(set (match_operand:CBOP 0 "spu_reg_operand" "=r")
> (unspec:CBOP [(match_operand 1 "spu_reg_operand" "r")
>   (match_operand 2 "spu_reg_operand" "r")] UNSPEC_CG))]
> !   "operands"
> "cg\t%0,%1,%2")
>
>   (define_insn "cgx_"
> --- 1066,1072 
> [(set (match_operand:CBOP 0 "spu_reg_operand" "=r")
> (unspec:CBOP [(match_operand 1 "spu_reg_operand" "r")
>   (match_operand 2 "spu_reg_operand" "r")] UNSPEC_CG))]
> !   "operands != NULL"
> "cg\t%0,%1,%2")
>
>   (define_insn "cgx_"
> ***
> *** 1074,1080 
> (unspec:CBOP [(match_operand 1 "spu_reg_operand" "r")
>   (match_operand 2 "spu_reg_operand" "r")
>   (match_operand 3 "spu_reg_operand" "0")] UNSPEC_CGX))]
> !   "operands"
> "cgx\t%0,%1,%2")
>
>   (define_insn "addx_"
> --- 1074,1080 
> (unspec:CBOP [(match_operand 1 "spu_reg_operand" "r")
>   (match_operand 2 "spu_reg_operand" "r")
>   (match_operand 3 "spu_reg_operand" "0")] UNSPEC_CGX))]
> !   "operands != NULL"
> "cgx\t%0,%1,%2")
>
>   (define_insn "addx_"
> ***
> *** 1082,1088 
> (unspec:CBOP [(match_operand 1 "spu_reg_operand" "r")
>   (match_operand 2 "spu_reg_operand" "r")
>   (match_operand 3 "spu_reg_operand" "0")] UNSPEC_ADDX))]
> !   "operands"
> "addx\t%0,%1,%2")
>
>
> --- 1082,1088 
> (unspec:CBOP [(match_operand 1 "spu_reg_operand" "r")
>   (match_operand 2 "spu_reg_operand" "r")
>   (match_operand 3 "spu_reg_operand" "0")] UNSPEC_ADDX))]
> !   "operands != NULL"
> "addx\t%0,%1,%2")
>
>
> ***
> *** 1189,1195 
> [(set (match_operand:CBOP 0 "spu_reg_operand" "=r")
> (unspec:CBOP [(match_operand 1 "spu_reg_operand" "r")
>   (match_operand 2 "spu_reg_operand" "r")] UNSPEC_BG))]
> !   "operands"
> "bg\t%0,%2,%1")
>
>   (define_insn "bgx_"
> --- 1189,1195 
> [(set (match_operand:CBOP 0 "spu_reg_operand" "=r")
> (unspec:CBOP [(match_operand 1 "spu_reg_operand" "r")
>   (match_operand 2 "spu_reg_operand" "r")] UNSPEC_BG))]
> !   "operands != NULL"
> "bg\t%0,%2,%1")
>
>   (define_insn "bgx_"
> ***
> *** 1197,1203 
> (unspec:CBOP [(match_operand 1 "spu_reg_operand" "r")
>   (match_operand 2 "spu_reg_operand" "r")
>   (match_operand 3 "spu_reg_operand" "0")] UNSPEC_BGX))]
> !   "operands"
> "bgx\t%0,%2,%1")
>
>   (define_insn "sfx_"
> --- 1197,1203 
> (unspec:CBOP [(match_operand 1 "spu_reg_operand" "r")
>   (match_operand 2 "spu_reg_operand" "r")
>   (match_operand 3 "spu_reg_operand" "0")] UNSPEC_BGX))]
> !   "operands != NULL"
> "bgx\t%0,%2,%1")
>
>   (define_insn "sfx_"
> ***
> *** 1205,1211 
> (unspec:CBOP [(match_operand 1 "spu_reg_operand" "r")
>   (match_operand 2 "spu_reg_operand" "r")
>   (match_operand 3 "spu_reg_operand" "0")] UNSPEC_SFX))]
> !   "operands"
> "sfx\t%0,%2,%1")
>
>   (define_insn "subti3"
> --- 1205,1211 
> (unspec:CBOP [(match_operand 1 "spu_reg_operand" "r")
>   (match_operand 2 "spu_reg_operand" "r")
>   (match_operand 3 "spu_reg_operand" "0")] UNSPEC_SFX))]
> !   "operands != NULL"
> "sfx\t%0,%2,%1")
>
>   (define_insn "subti3"
> *** selb\t%0,%4,%0,%3"
> *** 4018,4024 
>   (define_insn "extend_compare"
> [(set (match_operand:ALL 0 "spu_reg_operand" "=r")
> (unspec:ALL [(match_operand 1 "spu_reg_operand" "r")] 
> UNSPEC_EXTEND_CMP))]
> !   "operands"
> "fsm\t%0,%1"
> [(set_attr "type" "shuf")])
>
> --- 4018,4024 
>   (define_insn "exte

Re: Fix ICE on loop over constant vector at -O

2012-12-10 Thread Richard Biener
On Mon, Dec 10, 2012 at 10:55 AM, Eric Botcazou  wrote:
>> Well ... I would have expected that we'd have folded the CONST_DECL to
>> its DECL_INITIAL.  At least that is what we do for all other CONST_DECLs.
>> The only way CONST_DECLs should appear in the IL (after some optimization
>> of course) is when you take their address.
>
> That's what (essentially) happens here.  The CONST_DECL is wrapped up in a
> VIEW_CONVERT_EXPR to array type and a component with non-constant index is
> extracted from it.

Ah, ok ...

>> So - if you can burn some extra cycles to figure out why it's not
>> replaced by its DECL_INITIAL ...?
>
> We specifically prevent that in gigi because it will need to be spilled to
> memory given the above access pattern, so I don't really see the problem.
> Here's the access in .optimized:
>
> _38 = MEM[symbol: pkg__zero_unit, index: ivtmp.38_27, step: 4, offset: -4B];

... so if would really be a pessimization doing that.  Of course handling
CONST_DECL in for_each_index is indeed obvious - I just was curios if
it was a missed-optimization opportunity as well.

Thanks for clarifying,
Richard.

> --
> Eric Botcazou


[asan, committed] Sync asan_test.cc from upstream

2012-12-10 Thread Jakub Jelinek
Hi!

I've committed as obvious this change to sync the test from upstream
to avoid one unnecessary FAIL.

2012-12-10  Jakub Jelinek  

* g++.dg/asan/asan_test.cc: Sync from upstream.
* g++.dg/asan/asan_test_utils.h: Likewise.

--- gcc/testsuite/g++.dg/asan/asan_test.cc  2012-12-03 12:44:13.828811869 
+0100
+++ gcc/testsuite/g++.dg/asan/asan_test.cc  2012-12-05 19:06:52.288213731 
+0100
@@ -1604,7 +1606,7 @@ NOINLINE static int LargeFunction(bool d
 TEST(AddressSanitizer, DISABLED_LargeFunctionSymbolizeTest) {
   int failing_line = LargeFunction(false);
   char expected_warning[128];
-  sprintf(expected_warning, "LargeFunction.*asan_test.cc:%d", failing_line);
+  sprintf(expected_warning, "LargeFunction.*asan_test.*:%d", failing_line);
   EXPECT_DEATH(LargeFunction(true), expected_warning);
 }
 
@@ -1748,7 +1750,7 @@ TEST(AddressSanitizer, FileNameInGlobalR
   static char zoo[10];
   const char *p = Ident(zoo);
   // The file name should be present in the report.
-  EXPECT_DEATH(Ident(p[15]), "zoo.*asan_test.cc");
+  EXPECT_DEATH(Ident(p[15]), "zoo.*asan_test.");
 }
 
 int *ReturnsPointerToALocalObject() {
--- gcc/testsuite/g++.dg/asan/asan_test_utils.h 2012-12-03 12:44:48.868608115 
+0100
+++ gcc/testsuite/g++.dg/asan/asan_test_utils.h 2012-12-05 19:06:52.308213631 
+0100
@@ -53,7 +55,7 @@ typedef __int64  int64_t;
 
 // Make the compiler thinks that something is going on there.
 inline void break_optimization(void *arg) {
-  __asm__ __volatile__ ("" : : "r" (arg) : "memory");
+  __asm__ __volatile__("" : : "r" (arg) : "memory");
 }
 
 // This function returns its parameter but in such a way that compiler

Jakub


Re: [patch] don't build multilib libraries during bootstrap, and disable some libstdc++ features

2012-12-10 Thread Andrew Pinski
On Mon, Dec 10, 2012 at 4:16 AM, Matthias Klose  wrote:
> During bootstrap some things are built which are not required for the 
> bootstrap:
>
>  - multilib libraries
>  - libstdc++ debug library, when configured with --enable-libstdcxx-debug
>  - libstdc++ precompiled header files
>
> The attached patch disables building these during the bootstrap stages. The
> additional dependencies on all-target-libgcc are necessary for multilib'd
> builds, or else the configury bails out finding the wrong libgcc. I can't see 
> a
> way to add these dependencies for the multilib enabled build only.
>
> Ok for the trunk?

Does this work when someone supplies BOOT_CFLAGS a multlib option like
say -m32 ?

Thanks,
Andrew Pinski


[patch] don't build multilib libraries during bootstrap, and disable some libstdc++ features

2012-12-10 Thread Matthias Klose
During bootstrap some things are built which are not required for the bootstrap:

 - multilib libraries
 - libstdc++ debug library, when configured with --enable-libstdcxx-debug
 - libstdc++ precompiled header files

The attached patch disables building these during the bootstrap stages. The
additional dependencies on all-target-libgcc are necessary for multilib'd
builds, or else the configury bails out finding the wrong libgcc. I can't see a
way to add these dependencies for the multilib enabled build only.

Ok for the trunk?

  Matthias
	* Makefile.tpl (configure-stage[+id+]-[+prefix+][+module+]): Pass
	bootstrap_configure_flags.
	* Makefile.def (target_modules): Pass bootstrap_configure_flags
	for libgcc, libgomp, libstdc++-v3.
	(dependencies): For all target libraries, depend on all-target-libgcc.
	
--- Makefile.tpl~	2012-11-29 17:44:18.0 +0100
+++ Makefile.tpl	2012-12-10 12:03:00.716683469 +0100
@@ -1060,7 +1060,9 @@
 	  --target=[+target_alias+] $${srcdiroption} [+ IF prev +]\
 	  --with-build-libsubdir=$(HOST_SUBDIR) [+ ENDIF prev +]\
 	  $(STAGE[+id+]_CONFIGURE_FLAGS)[+ IF extra_configure_flags +] \
-	  [+extra_configure_flags+][+ ENDIF extra_configure_flags +]
+	  [+extra_configure_flags+][+ ENDIF extra_configure_flags +] \
+	  [+ IF bootstrap_configure_flags +][+bootstrap_configure_flags+] \
+	  [+ ENDIF bootstrap_configure_flags +]
 @endif [+prefix+][+module+]-bootstrap
 [+ ENDFOR bootstrap_stage +]
 [+ ENDIF bootstrap +]
--- Makefile.def~	2012-12-01 22:34:06.0 +0100
+++ Makefile.def	2012-12-10 12:51:08.444647333 +0100
@@ -117,12 +117,14 @@
 target_modules = { module= libstdc++-v3;
 		   bootstrap=true;
 		   lib_path=src/.libs;
-		   raw_cxx=true; };
+		   raw_cxx=true;
+		   bootstrap_configure_flags='--disable-multilib --disable-libstdcxx-debug --disable-libstdcxx-pch'; };
 target_modules = { module= libmudflap; lib_path=.libs; };
 target_modules = { module= libsanitizer; lib_path=.libs; };
 target_modules = { module= libssp; lib_path=.libs; };
 target_modules = { module= newlib; };
-target_modules = { module= libgcc; bootstrap=true; no_check=true; };
+target_modules = { module= libgcc; bootstrap=true; no_check=true;
+	   	   bootstrap_configure_flags='--disable-multilib'; };
 target_modules = { module= libbacktrace; };
 target_modules = { module= libquadmath; };
 target_modules = { module= libgfortran; };
@@ -142,7 +144,8 @@
 target_modules = { module= boehm-gc; };
 target_modules = { module= rda; };
 target_modules = { module= libada; };
-target_modules = { module= libgomp; bootstrap= true; lib_path=.libs; };
+target_modules = { module= libgomp; bootstrap= true; lib_path=.libs;
+	   	   bootstrap_configure_flags='--disable-multilib'; };
 target_modules = { module= libitm; lib_path=.libs; };
 target_modules = { module= libatomic; lib_path=.libs; };
 
@@ -504,6 +507,19 @@
 dependencies = { module=configure-target-libobjc; on=configure-target-boehm-gc; };
 dependencies = { module=all-target-libobjc; on=all-target-boehm-gc; };
 dependencies = { module=configure-target-libstdc++-v3; on=configure-target-libgomp; };
+dependencies = { module=configure-target-libada; on=all-target-libgcc; };
+dependencies = { module=configure-target-libatomic; on=all-target-libgcc; };
+dependencies = { module=configure-target-libbacktrace; on=all-target-libgcc; };
+dependencies = { module=configure-target-libdecnumber; on=all-target-libgcc; };
+dependencies = { module=configure-target-libffi; on=all-target-libgcc; };
+dependencies = { module=configure-target-libgfortran; on=all-target-libgcc; };
+dependencies = { module=configure-target-libgomp; on=all-target-libgcc; };
+dependencies = { module=configure-target-libitm; on=all-target-libgcc; };
+dependencies = { module=configure-target-libmudflap; on=all-target-libgcc; };
+dependencies = { module=configure-target-libquadmath; on=all-target-libgcc; };
+dependencies = { module=configure-target-libssp; on=all-target-libgcc; };
+dependencies = { module=configure-target-libstdc++-v3; on=all-target-libgcc; };
+dependencies = { module=configure-target-zlib; on=all-target-libgcc; };
 dependencies = { module=configure-target-libsanitizer; on=all-target-libstdc++-v3; };
 // parallel_list.o and parallel_settings.o depend on omp.h, which is
 // generated by the libgomp configure.  Unfortunately, due to the use of


Re: [asan] Instrument STRING_CSTs

2012-12-10 Thread Dodji Seketeli
Jakub Jelinek  writes:

> 2012-12-05  Jakub Jelinek  
>
>   * asan.c (asan_init_shadow_ptr_types): Move earlier in the file.
>   Call initialize_sanitizer_builtins at the end.
>   (asan_pp_string): Use TREE_TYPE (shadow_ptr_types[0])
>   as character type instead of char_type_node.
>   (asan_emit_stack_protection): Call asan_init_shadow_ptr_types
>   if shadow_ptr_types isn't initialized.
>   (asan_protect_global): Return true for STRING_CSTs except those
>   created by asan_pp_string.
>   (count_string_csts, add_string_csts): New functions.
>   (struct asan_add_string_csts_data): New type.
>   (asan_finish_file): Clear flag_asan at the beginning, restore at the
>   end.  Traverse constant_pool_htab () to look for protected
>   STRING_CSTs.  Don't call initialize_sanitizer_builtins,
>   instead call asan_init_shadow_ptr_types if shadow_ptr_types isn't
>   initialized yet.
>   (asan_instrument): Don't call initialize_sanitizer_builtins.
>   * varasm.c (output_constant_def_contents): If STRING_CST should be
>   asan protected, align it sufficiently and emit padding after it.
>   (categorize_decl_for_section): If flag_asan, don't put STRING_CSTs
>   that should be asan protected into mergeable sections.  For
>   -fmerge-all-constants, ignore it for -fmudflap or if decl is
>   asan protected.

This seems OK to me, thanks.

-- 
Dodji


[PATCH] SPU: Fix build failure on 64 bit hosts

2012-12-10 Thread Andreas Krebbel
Hi,

building an SPU compiler on a 64 bit host system currently fails with:

spu.md:4394: error: cast from ‘rtx_def**’ to ‘int’ loses precision

In the SPU backend several patterns mention the operands array in the
insn condition in order to prevent a warning about missing modes to be
issued.  Interpreting the term "operands" as condition fails when it
is evaluated on a 64 bit host.  Turning it into a comparison fixes
this for me.

Ok to apply?

Bye,

-Andreas-


2012-12-10  Andreas Krebbel  

* config/spu/spu.md: Replace "operands" with "operands != NULL" in
insn conditions.

---
 gcc/config/spu/spu.md |   16 
 1 file changed, 16 modifications(!)

Index: gcc/config/spu/spu.md
===
*** gcc/config/spu/spu.md.orig
--- gcc/config/spu/spu.md
***
*** 1066,1072 
[(set (match_operand:CBOP 0 "spu_reg_operand" "=r")
(unspec:CBOP [(match_operand 1 "spu_reg_operand" "r")
  (match_operand 2 "spu_reg_operand" "r")] UNSPEC_CG))]
!   "operands"
"cg\t%0,%1,%2")
  
  (define_insn "cgx_"
--- 1066,1072 
[(set (match_operand:CBOP 0 "spu_reg_operand" "=r")
(unspec:CBOP [(match_operand 1 "spu_reg_operand" "r")
  (match_operand 2 "spu_reg_operand" "r")] UNSPEC_CG))]
!   "operands != NULL"
"cg\t%0,%1,%2")
  
  (define_insn "cgx_"
***
*** 1074,1080 
(unspec:CBOP [(match_operand 1 "spu_reg_operand" "r")
  (match_operand 2 "spu_reg_operand" "r")
  (match_operand 3 "spu_reg_operand" "0")] UNSPEC_CGX))]
!   "operands"
"cgx\t%0,%1,%2")
  
  (define_insn "addx_"
--- 1074,1080 
(unspec:CBOP [(match_operand 1 "spu_reg_operand" "r")
  (match_operand 2 "spu_reg_operand" "r")
  (match_operand 3 "spu_reg_operand" "0")] UNSPEC_CGX))]
!   "operands != NULL"
"cgx\t%0,%1,%2")
  
  (define_insn "addx_"
***
*** 1082,1088 
(unspec:CBOP [(match_operand 1 "spu_reg_operand" "r")
  (match_operand 2 "spu_reg_operand" "r")
  (match_operand 3 "spu_reg_operand" "0")] UNSPEC_ADDX))]
!   "operands"
"addx\t%0,%1,%2")
  
  
--- 1082,1088 
(unspec:CBOP [(match_operand 1 "spu_reg_operand" "r")
  (match_operand 2 "spu_reg_operand" "r")
  (match_operand 3 "spu_reg_operand" "0")] UNSPEC_ADDX))]
!   "operands != NULL"
"addx\t%0,%1,%2")
  
  
***
*** 1189,1195 
[(set (match_operand:CBOP 0 "spu_reg_operand" "=r")
(unspec:CBOP [(match_operand 1 "spu_reg_operand" "r")
  (match_operand 2 "spu_reg_operand" "r")] UNSPEC_BG))]
!   "operands"
"bg\t%0,%2,%1")
  
  (define_insn "bgx_"
--- 1189,1195 
[(set (match_operand:CBOP 0 "spu_reg_operand" "=r")
(unspec:CBOP [(match_operand 1 "spu_reg_operand" "r")
  (match_operand 2 "spu_reg_operand" "r")] UNSPEC_BG))]
!   "operands != NULL"
"bg\t%0,%2,%1")
  
  (define_insn "bgx_"
***
*** 1197,1203 
(unspec:CBOP [(match_operand 1 "spu_reg_operand" "r")
  (match_operand 2 "spu_reg_operand" "r")
  (match_operand 3 "spu_reg_operand" "0")] UNSPEC_BGX))]
!   "operands"
"bgx\t%0,%2,%1")
  
  (define_insn "sfx_"
--- 1197,1203 
(unspec:CBOP [(match_operand 1 "spu_reg_operand" "r")
  (match_operand 2 "spu_reg_operand" "r")
  (match_operand 3 "spu_reg_operand" "0")] UNSPEC_BGX))]
!   "operands != NULL"
"bgx\t%0,%2,%1")
  
  (define_insn "sfx_"
***
*** 1205,1211 
(unspec:CBOP [(match_operand 1 "spu_reg_operand" "r")
  (match_operand 2 "spu_reg_operand" "r")
  (match_operand 3 "spu_reg_operand" "0")] UNSPEC_SFX))]
!   "operands"
"sfx\t%0,%2,%1")
  
  (define_insn "subti3"
--- 1205,1211 
(unspec:CBOP [(match_operand 1 "spu_reg_operand" "r")
  (match_operand 2 "spu_reg_operand" "r")
  (match_operand 3 "spu_reg_operand" "0")] UNSPEC_SFX))]
!   "operands != NULL"
"sfx\t%0,%2,%1")
  
  (define_insn "subti3"
*** selb\t%0,%4,%0,%3"
*** 4018,4024 
  (define_insn "extend_compare"
[(set (match_operand:ALL 0 "spu_reg_operand" "=r")
(unspec:ALL [(match_operand 1 "spu_reg_operand" "r")] 
UNSPEC_EXTEND_CMP))]
!   "operands"
"fsm\t%0,%1"
[(set_attr "type" "shuf")])
  
--- 4018,4024 
  (define_insn "extend_compare"
[(set (match_operand:ALL 0 "spu_reg_operand" "=r")
(unspec:ALL [(match_operand 1 "spu_reg_operand" "r")] 
UNSPEC_EXTEND_CMP))]
!   "operands != NULL"
"fsm\t%0,%1"
[(set_attr "type" "shuf")])
  
*** selb\t%0,%4,%0,%3"
*** 4391,4397 
(unspec [(match_operand 1 "spu_reg_operand" "r")
 (match_operand 

Re: [patch, mips, debug] Fix PR 54061, mips compiler aborts in testsuite

2012-12-10 Thread Richard Sandiford
"H.J. Lu"  writes:
> On Sat, Dec 8, 2012 at 2:14 AM, Richard Sandiford
>  wrote:
>>
>> As far as the dwarf2out.c bits go, I think the original dbx_reg_number 
>> assert:
>>
>>   gcc_assert (regno != INVALID_REGNUM);
>>
>> should become:
>>
>>   gcc_assert (regno != INVALID_REGNUM && regno != IGNORED_DWARF_REGNUM);
>>
>> since it's the caller's job to handle this case.
>>
>
> I don't think if it will work since dbx_reg_number is called
> to get debug register number and the register is ignored
> if its return value is IGNORED_DWARF_REGNUM.

Er, quite.  What was I thinking?

So please ignore that stupid suggestion.  The comments about the MIPS
parts still stand of course.

Richard


Re: [RFC] Remove TLS symbols from section anchor blocks

2012-12-10 Thread Richard Sandiford
David Edelsohn  writes:
> [Sorry, I forgot to copy GCC Patches before]
>
> Some of the libgomp testcases fail on AIX when using native TLS
> because variables annotated with
>
> #pragma omp threadprivate(thr)
>
> sometimes are placed in section anchor blocks.  Variables declared
> with "__thread" create decls with the correct TLS model from the
> beginning, but OpenMP sometimes creates a decl with TLS_MODEL_NONE and
> later tries to make the decl again. make_decl_rtl() is called again
> and it calls ENCODE_SECTION_INFO and then change_symbol_block().
> However ENCODE_SECTION_INFO explicitly preserves
> SYMBOL_FLAG_HAS_BLOCK_INFO and change_symbol_block() place the symbol
> in a different block but never re-assesses if the new attributes of
> the symbol make it in appropriate for section anchor blocks.
>
> The following patch adds an ENCODE_SECTION_INFO hook for AIX that
> removes the SYMBOL_FLAG_HAS_BLOCK_INFO flag if the symbol is
> DECL_THREAD_LOCAL_P. This prevents the symbol from being emitted in a
> section anchor block and it correctly is emitted in its own section;
> it does not remove it from the section anchor blocks data structures.
> This fixes some of the libgomp failures.
>
> Is this a reasonable approach?  Or should change_symbol_block re-test
> use_blocks_for_symbol_p()?

TBH I don't really know.  The original idea was that use_blocks_for_decl_p
checks invariants and get_block_for_decl checks things that could conceivably
change between calls to make_decl_rtl (including changes that make the decl
suitable for object blocks, e.g. because we now have a definition of something
that used to be extern).

So perhaps we should check the use_blocks_for_decl_p target hook in
get_block_for_decl instead of varasm.c:use_blocks_for_decl_p.
I.e. something like:

/* Return the block into which object_block DECL should be placed.  */

static struct object_block *
get_block_for_decl (tree decl)
{
  section *sect;

  ...

  if (!targetm.use_blocks_for_decl_p (decl))
return NULL;

  /* Find out which section should contain DECL.  We cannot put it into
 an object block if it requires a standalone definition.  */
  if (TREE_CODE (decl) == VAR_DECL)
  align_variable (decl, 0);
  sect = get_variable_section (decl, true);
  if (SECTION_STYLE (sect) == SECTION_NOSWITCH)
return NULL;

  return get_block_for_section (sect);
}

Although it's not exactly ideal having a hook called use_blocks_for_decl_p
and a function called use_blocks_for_decl_p that do different things...

Richard


Re: [PATCH][ARM][3/3] AArch32 NEON vrint builtins and intrinsics

2012-12-10 Thread Ramana Radhakrishnan

On 11/29/12 14:27, Kyrylo Tkachov wrote:

Hi all,
This patch adds the intrinsics support for the vrnd intrinsics that are
implemented by the vrint instructions.
The .ml scripts contain the new information and should used to regenerate
the arm_neon.h header file, tests and documentation.
In particular:
* config/arm/arm_neon.h should be regenerated using config/arm/neon-gen.ml.
* doc/arm-neon-intrinsics.texi should be regenerated using
config/arm/neon-docgen.ml.
* The tests in testsuite/gcc.target/arm/neon/ should be generated using
config/arm/neon-testgen.ml.
All three of these scripts should be linked against the compiled neon.ml
file i.e:
$ ocamlc -c neon.ml
$ ocamlc -o neon-gen neon.cmo neon-gen.ml


The following intrinsics are defined:
vrnd_f32 (float32x2_t a)   (generating a vrintz instruction)
vrndq_f32 (float32x4_t a)  (generating a vrintz instruction)
vrnda_f32 (float32x2_t a)  (generating a vrinta instruction)
vrndqa_f32 (float32x4_t a) (generating a vrinta instruction)
vrndm_f32 (float32x2_t a)  (generating a vrintm instruction)
vrndqm_f32 (float32x4_t a) (generating a vrintm instruction)
vrndn_f32 (float32x2_t a)  (generating a vrintn instruction)
vrndqn_f32 (float32x4_t a) (generating a vrintn instruction)
vrndp_f32 (float32x2_t a)  (generating a vrintp instruction)
vrndqp_f32 (float32x4_t a) (generating a vrintp instruction)

Note that AArch32 NEON does not support double precision floats, so we don't
have _f64 versions.

Tested on arm-none-eabi. New tests pass, no regressions (once the effective
target checks patch is added).

Ok for trunk?


Please add 2012 as a copyright year for arm_neon.h in the generator program.

When I regenerated the documents, it did look like there were more 
changes in arm-neon-intrinsics.texi but my suspicion is this is because 
the document hasn't been regenerated in some time. The main change here 
is the order in which some of the intrinsics are listed which has 
changed over time.


Ok with that change.


regards,
Ramana





Re: [Fortran, (RFC) patch] PR49110/51055 Assignment to alloc. deferred-length character vars

2012-12-10 Thread Jakub Jelinek
On Mon, Dec 10, 2012 at 10:56:58AM +0100, Janus Weil wrote:
> > For C and C++, identifiers beginning with underscore and upper case
> > letter or with two underscores are reserve to the implementation.
> 
> See the previous discussion in this thread ...

That's true, but the implementation isn't just GCC, it is also C libraries
which aren't provided by GCC.  Including a character (if possible) that
will make it unaccessible from C/C++ is desirable.  And, not changing the
names of non-TREE_STATIC vars is also desirable, those I'm afraid show up
in the debug info from time to time, so making them unnecessarily larger
results in .debug_info size increases.

Jakub


Re: Fix ICE on loop over constant vector at -O

2012-12-10 Thread Eric Botcazou
> Well ... I would have expected that we'd have folded the CONST_DECL to
> its DECL_INITIAL.  At least that is what we do for all other CONST_DECLs.
> The only way CONST_DECLs should appear in the IL (after some optimization
> of course) is when you take their address.

That's what (essentially) happens here.  The CONST_DECL is wrapped up in a 
VIEW_CONVERT_EXPR to array type and a component with non-constant index is 
extracted from it.

> So - if you can burn some extra cycles to figure out why it's not
> replaced by its DECL_INITIAL ...?

We specifically prevent that in gigi because it will need to be spilled to 
memory given the above access pattern, so I don't really see the problem.
Here's the access in .optimized:

_38 = MEM[symbol: pkg__zero_unit, index: ivtmp.38_27, step: 4, offset: -4B];

-- 
Eric Botcazou


Re: [Fortran, (RFC) patch] PR49110/51055 Assignment to alloc. deferred-length character vars

2012-12-10 Thread Janus Weil
>> Here is a re-diffed version of my previous patch. I'd be grateful for
>> comments. In particular: Does it fix all the problems on AIX? (For
>> more open questions, see below.)
>
> IMHO there is no point to mangle automatic vars or PARM_DECLs that way,
> i.e. anything that won't be TREE_STATIC.  And, what will be TREE_STATIC
> should have dot or $ character in the symbol name if the target allows it,
> to avoid unnecessary clashes with e.g. the C library etc.

well, I'm not an expert for C/C++ name mangling, but this patch was
motivated by David's earlier statement:

> For C and C++, identifiers beginning with underscore and upper case
> letter or with two underscores are reserve to the implementation.

See the previous discussion in this thread ...

Cheers,
Janus


Re: [PATCH] Bugfix: Additional parameter for canonicalize comparison

2012-12-10 Thread Andreas Krebbel
On Sat, Dec 08, 2012 at 01:16:16AM +0100, Oleg Endo wrote:
> On Fri, 2012-12-07 at 13:37 -0600, Richard Henderson wrote:
> > On 2012-12-06 02:25, Andreas Krebbel wrote:
> > > !   targetm.canonicalize_comparison ((int*)&compare_code, &op0, 
> > > &op1, 1);
> > 
> > The basic approach seems sound.  But this cast is distinctly uncool.
> > 
> > And why the unused return value?  If you didn't need it, why add it?
> > 
> > 
> > r~
> 
> For the SH part, can't the 'sh_canonicalize_comparison_1' just be named
> 'sh_canonicalize_comparison' and have it overload the target hook
> function?

Ok. Here is an updated version trying to address the comments above.

2012-12-10  Andreas Krebbel  

* target.def: Define canonicalize_comparison hook.
* targhooks.h (default_canonicalize_comparison): New prototype.
* targhooks.c (default_canonicalize_comparison): New function.
* doc/tm.texi: Add documentation for the new target hook.
* doc/tm.texi.in: Likewise.
* combine.c (try_combine): Adjust to use the target hook.
* config/alpha/alpha.h (CANONICALIZE_COMPARISON): Remove macro
definition.
* config/alpha/alpha.c (alpha_canonicalize_comparison): New
function.
(TARGET_CANONICALIZE_COMPARISON): New macro definition.
* config/arm/arm-protos.h (arm_canonicalize_comparison): Remove
prototype.
* config/arm/arm.c (arm_canonicalize_comparison): Add new
parameter.
(TARGET_CANONICALIZE_COMPARISON): New macro definition.
* config/arm/arm.h (CANONICALIZE_COMPARISON): Remove macro
definition.
* config/s390/s390-protos.h (s390_canonicalize_comparison): Remove
prototype.
* config/s390/s390.c (s390_canonicalize_comparison): Add new
parameter.
(TARGET_CANONICALIZE_COMPARISON): New macro definition.
* config/s390/s390.h (CANONICALIZE_COMPARISON): Remove macro
definition.
* config/sh/sh-protos.h (sh_canonicalize_comparison): Remove
prototype.
* config/sh/sh.c (sh_canonicalize_comparison): Add new prototype.  New
function overloading the old one.
(TARGET_CANONICALIZE_COMPARISON): New macro definition.
* config/sh/sh.h (CANONICALIZE_COMPARISON): Remove macro
definition.
* config/spu/spu.c (spu_canonicalize_comparison): New function.
(TARGET_CANONICALIZE_COMPARISON): New macro definition.
* config/spu/spu.h (CANONICALIZE_COMPARISON): Remove macro
definition.

---
 gcc/combine.c |   19 ++-!!!
 gcc/config/alpha/alpha.c  |   27 
 gcc/config/alpha/alpha.h  |   20 
 gcc/config/arm/arm-protos.h   |1 
 gcc/config/arm/arm.c  |   68 ++-!!
 gcc/config/arm/arm.h  |3 -
 gcc/config/s390/s390-protos.h |1 
 gcc/config/s390/s390.c|   13 +++!
 gcc/config/s390/s390.h|4 --
 gcc/config/sh/sh-protos.h |2 -
 gcc/config/sh/sh.c|   36 !!
 gcc/config/sh/sh.h|4 --
 gcc/config/spu/spu.c  |   17 ++
 gcc/config/spu/spu.h  |   12 ---
 gcc/doc/tm.texi   |   20 
 gcc/doc/tm.texi.in|   20 
 gcc/target.def|8 
 gcc/targhooks.h   |2 +
 18 files changed, 96 insertions(+), 50 deletions(-), 131 modifications(!)

Index: gcc/combine.c
===
*** gcc/combine.c.orig
--- gcc/combine.c
*** static rtx gen_lowpart_or_truncate (enum
*** 494,499 
--- 494,510 
  static const struct rtl_hooks combine_rtl_hooks = RTL_HOOKS_INITIALIZER;
  
  
+ /* Convenience wrapper for the canonicalize_comparison target hook.
+Targets hooks cannot use enum rtx_code.  */
+ static inline void
+ target_canonicalize_comparison (enum rtx_code *code, rtx *op0, rtx *op1,
+   bool op0_preserve_value)
+ {
+   int code_int = (int)*code;
+   targetm.canonicalize_comparison (&code_int, op0, op1, op0_preserve_value);
+   *code = (enum rtx_code)code_int;
+ }
+ 
  /* Try to split PATTERN found in INSN.  This returns NULL_RTX if
 PATTERN can not be split.  Otherwise, it returns an insn sequence.
 This is a wrapper around split_insns which ensures that the
*** try_combine (rtx i3, rtx i2, rtx i1, rtx
*** 2944,2952 
  compare_code = orig_compare_code = GET_CODE (*cc_use_loc);
  compare_code = simplify_compare_const (compare_code,
 op0, &op1);
! #ifdef CANONICALIZE_COMPARISON
! CANONICALIZE_COMPARISON (compare_code, op0, op1);
! #endif
}
  
/* Do the rest only if op1 is const0_rtx, which may be the
--- 2955,2961 
  compare_code = orig_compare_code = GET_CODE (*cc_use_loc);
  compare_code = simp

Re: [Fortran, (RFC) patch] PR49110/51055 Assignment to alloc. deferred-length character vars

2012-12-10 Thread Jakub Jelinek
On Mon, Dec 10, 2012 at 10:22:30AM +0100, Janus Weil wrote:
> 2012/12/10 David Edelsohn :
> > There has been no progress on this bug for over two months.  I have
> > opened PR fortran/55636.  This must be fixed before GCC 4.8 ships.
> 
> Thanks for pinging, David. I almost forgot about it ...
> 
> Here is a re-diffed version of my previous patch. I'd be grateful for
> comments. In particular: Does it fix all the problems on AIX? (For
> more open questions, see below.)

IMHO there is no point to mangle automatic vars or PARM_DECLs that way,
i.e. anything that won't be TREE_STATIC.  And, what will be TREE_STATIC
should have dot or $ character in the symbol name if the target allows it,
to avoid unnecessary clashes with e.g. the C library etc.

Jakub


Re: [Patch, Fortran, F03] PR52909: Procedure pointers not private to modules

2012-12-10 Thread Tobias Burnus

Hi Janus,

I think the patch below is okay, especially in light of patch 
PR49110/51055 which also contains a slight ABI breakage. Can you mention 
the potential ABI issue in the release notes (gfortran wiki).


Tobias

On 09.04.2012 18:31 Janus Weil wrote:

Hi all,

here is a simple patch for a problem recently reported by Andrew
Benson: Procedure pointers inside a module don't receive the proper
name mangling, which can lead to name collisions (as the test case
demonstrates).

The patch fixes this and regtests cleanly on x86_64-unknown-linux-gnu.
I am aware that it will break the ABI, but only for programs involving
procedure pointers (which still is a 'relatively' new feature,
supported since gfortran 4.4). So, ok for trunk?

Btw, speaking of ABI breaking: What are the chances of the array
descriptor update and ABI cleanup happening for the 4.8 release? I
know such an ABI breaking has been planned for some time, but I
haven't followed the gfortran mailing list in detail during the last
weeks and months, so I'm not sure what the current status is.

Cheers,
Janus



2012-04-09  Janus Weil  

PR fortran/52909
* trans-decl.c (get_proc_pointer_decl): Apply name mangling.


2012-04-09  Janus Weil  

PR fortran/52909
* gfortran.dg/proc_ptr_37.f90: New test case.




Re: [PATCH i386]: Enable push/pop in pro/epilogue for modern CPUs

2012-12-10 Thread Richard Biener
On Sun, Dec 9, 2012 at 2:50 PM, Uros Bizjak  wrote:
> Hello!
>
>> I noticed in prologue/epilogue, GCC prefers to use MOVs followed by a
>> SP adjustment instead of a sequence of pushes/pops. The preference to
>> the MOVs are good for old CPU micro-architectures (before pentium-4,
>> K10), because it breaks the data dependency.  In modern
>> micro-architecture, push/pop is implemented using a mechanism called
>> stack engine. The data dependency is removed by the hardware, and
>> push/pop becomes very cheap (1 uOp, 1 cycle latency), and they are
>> smaller. There is no longer the need to avoid using them.   This is
>> also what ICC does.
>
>> 2012-12-08  Xinliang David Li  
>>* config/i386/i386.c: Eanble push/pop in pro/epilogue for moderen 
>> CPUs.
>
> s/moderen/modern
>
> OK for mainline SVN.

It's also more costly for unwind info in the prologue/epilogue.  Thus, did you
measure the effect on CFI size?

Thanks,
Richard.

> Thanks,
> Uros.


Re: [Fortran, (RFC) patch] PR49110/51055 Assignment to alloc. deferred-length character vars

2012-12-10 Thread Janus Weil
2012/12/10 David Edelsohn :
> There has been no progress on this bug for over two months.  I have
> opened PR fortran/55636.  This must be fixed before GCC 4.8 ships.

Thanks for pinging, David. I almost forgot about it ...

Here is a re-diffed version of my previous patch. I'd be grateful for
comments. In particular: Does it fix all the problems on AIX? (For
more open questions, see below.)

Cheers,
Janus



> On Thu, Oct 4, 2012 at 5:04 PM, Janus Weil  wrote:
>>
>> unfortunately my previous patch regressed on the proc_ptr_result test
>> cases (due to problems with implicit typing of symbols with leading
>> underscores, which also were the reason for using a suffix instead of
>> a prefix for proc-ptr results in the first place). So I have taken out
>> the 'ppr' parts, leaving only Tobias' original cases and the OOP
>> stuff, which at least should be regression-free now.
>>
>> There are some more double-underscore cases which one could also
>> change into the new _F convention. Should I keep going in this
>> direction, or should we rather restrict this to the "leading dot"
>> cases for now? I guess this is a question of how much ABI breaking we
>> are willing to take. Opinions?
>>
>> Cheers,
>> Janus


mangling_v3.diff
Description: Binary data


Re: [patch print-tree.c]: 5 of 7 Fix of PR target/53912 bootstrap fails using default c++ mode in stage 2 and 3 for native x86_64-w64-mingw32

2012-12-10 Thread Richard Biener
On Sun, Dec 9, 2012 at 5:18 PM, NightStrike  wrote:
> On Sat, Dec 1, 2012 at 11:12 PM, Kai Tietz  wrote:
>> Ping
>>
>> 2012/11/29 Kai Tietz :
>>> Hello,
>>>
>>> this trivial patch fixes a bootstrap issue on LLP64 hosts.
>>>
>>> ChangeLog
>>>
>>> 2012-11-29 Kai Tietz
>>>
>>> PR target/53912
>>> * print-tree.c (print_node): Cast from pointer via uintptr_t.
>>>
>>> Tested for i686-w64-mingw32, x86_64-w64-mingw32, and
>>> x86_64-unknown-gnu-linux. Ok for apply?
>>>
>>> Regards,
>>> Kai
>>>
>>> Index: print-tree.c
>>> ===
>>> --- print-tree.c(Revision 193925)
>>> +++ print-tree.c(Arbeitskopie)
>>> @@ -255,7 +255,7 @@ print_node (FILE *file, const char *prefix, tree n
>>>/* Allow this function to be called if the table is not there.  */
>>>if (table)
>>>  {
>>> -  hash = ((unsigned long) node) % HASH_SIZE;
>>> +  hash = ((uintptr_t) node) % HASH_SIZE;
>>>
>>>/* If node is in the table, just mention its address.  */
>>>for (b = table[hash]; b; b = b->next)
>
> Ping.

Ok.

Thanks,
Richard.


Re: [patch stmt.c]: Fix SjLj exception handling

2012-12-10 Thread Richard Biener
On Sun, Dec 9, 2012 at 5:17 PM, NightStrike  wrote:
> On Sat, Dec 1, 2012 at 12:28 PM, Steven Bosscher  
> wrote:
>> On Sat, Dec 1, 2012 at 10:59 PM, Kai Tietz wrote:
>>> Hi,
>>>
>>> recent 4,8 has regressions in g++.old-deja/g++.eh for the catch*.C
>>> tests, if exception-mechanism is SjLj.  This is due an off by one
>>> failure in an decreasing loop.
>>>
>>> ChangeLog
>>>
>>> 2012-12-01  Kai Tietz
>>>
>>> * stmt.c (expand_sjlj_dispatch_table): Fix off by one.
>>>
>>> Tested for i686-w64-mingw32, x86_64-unknown-linux-gnu.  Ok for apply?
>>>
>>> Regards,
>>> Kai
>>>
>>>
>>> Index: stmt.c
>>> ===
>>> --- stmt.c  (Revision 193985)
>>> +++ stmt.c  (Arbeitskopie)
>>> @@ -2282,7 +2282,7 @@ expand_sjlj_dispatch_table (rtx dispatch_index,
>>>tree range = maxval;
>>>rtx default_label = gen_label_rtx ();
>>>
>>> -  for (int i = ncases - 1; i > 0; --i)
>>> +  for (int i = ncases - 1; i >= 0; --i)
>>> {
>>>   tree elt = dispatch_table[i];
>>>   tree low = CASE_LOW (elt);
>>
>>
>> I can't approve this, but it's obvious. The "normal" switch expander
>> (expand_case) expects the default case in slot 0, but the SJLJ
>> dispatch table doesn't have a default case.
>>
>> Ciao!
>> Steven
>
> Ping.

Ok.

Thanks,
Richard.


Re: [patch stmt.c]: 6 of 7 Fix of PR target/53912 bootstrap fails using default c++ mode in stage 2 and 3 for native x86_64-w64-mingw32

2012-12-10 Thread Richard Biener
On Sun, Dec 9, 2012 at 4:58 PM, NightStrike  wrote:
> On Sat, Dec 1, 2012 at 11:13 PM, Kai Tietz  wrote:
>> Ping
>>
>> 2012/11/29 Kai Tietz :
>>> Hello,
>>>
>>> this trivial patch fixes a bootstrap issue on LLP64 hosts.
>>>
>>> ChangeLog
>>>
>>> 2012-11-29 Kai Tietz
>>>
>>> PR target/53912
>>> * stmt.c (compute_cases_per_edge): Cast from pointer via intptr_t.
>>> (expand_case): Likewise.
>>>
>>> Tested for i686-w64-mingw32, x86_64-w64-mingw32, and
>>> x86_64-unknown-gnu-linux. Ok for apply?
>>>
>>> Regards,
>>> Kai
>>>
>>> Index: stmt.c
>>> ===
>>> --- stmt.c  (Revision 193925)
>>> +++ stmt.c  (Arbeitskopie)
>>> @@ -2061,7 +2061,7 @@ compute_cases_per_edge (gimple stmt)
>>>tree lab = CASE_LABEL (elt);
>>>basic_block case_bb = label_to_block_fn (cfun, lab);
>>>edge case_edge = find_edge (bb, case_bb);
>>> -  case_edge->aux = (void *)((long)(case_edge->aux) + 1);
>>> +  case_edge->aux = (void *)((intptr_t)(case_edge->aux) + 1);
>>>  }
>>>  }
>>>
>>> @@ -2176,7 +2176,7 @@ expand_case (gimple stmt)
>>>edge case_edge = find_edge (bb, case_bb);
>>>case_list = add_case_node (
>>>case_list, low, high, lab,
>>> -  case_edge->probability / (long)(case_edge->aux),
>>> +  case_edge->probability / (intptr_t)(case_edge->aux),
>>>case_node_pool);
>>>  }
>>>pointer_set_destroy (seen_labels);
>
> Ping x2

Ok.

Thanks,
Richard.


Re: Fix ICE on loop over constant vector at -O

2012-12-10 Thread Richard Biener
On Sat, Dec 8, 2012 at 12:42 PM, Eric Botcazou  wrote:
> This is an internal error in for_each_index at -O:
>
> +===GNAT BUG DETECTED==+
> | 4.8.0 20121208 (experimental) [trunk revision 194319] (x86_64-suse-linux)
> GCC error:|
> | in for_each_index, at tree-ssa-loop-im.c:324 |
> | Error detected around vect9.adb:45:1|
>
> The callback is invoked on a vector CONST_DECL and stops.  That's an unusual
> situation (the CONST_DECL is wrapped up in a VIEW_CONVERT_EXPR to array type)
> but IMO there is no reason to accept other DECLs and stop on CONST_DECLs.
>
> Tested on x86_64-suse-linux, applied on the mainline as obvious.

Well ... I would have expected that we'd have folded the CONST_DECL to
its DECL_INITIAL.  At least that is what we do for all other CONST_DECLs.
The only way CONST_DECLs should appear in the IL (after some optimization
of course) is when you take their address.

So - if you can burn some extra cycles to figure out why it's not
replaced by its DECL_INITIAL ...?

Richard.

> 2012-12-08  Eric Botcazou  
>
> * tree-ssa-loop-im.c (for_each_index) : New case.
>
>
> 2012-12-08  Eric Botcazou  
>
> * gnat.dg/vect9.ad[sb]: New test.
> * gnat.dg/vect9_pkg.ads: New helper.
>
>
> --
> Eric Botcazou


Re: PATCH: PR lto/55466: Revision 191466 destroyed DWARF debug info

2012-12-10 Thread Richard Biener
On Fri, Dec 7, 2012 at 11:59 PM, H.J. Lu  wrote:
> Hi,
>
> Since revision 191466, LTO no longer maintains its own symbol table and
> it uses varpool for variables instead.  As the result, debug info on
> variables is lost when GCC is configured with
>
> --enable-bootstrap --with-build-config=bootstrap-lto
>
> This patch record the global variables if WPA isn't enabled.  It
> works when GCC is configured with
>
> --enable-bootstrap --with-build-config=bootstrap-lto 
> --enable-languages=c,c++,fortran,java,lto,objc,obj-c++
>
> However, when go is added, I got
>
> lto1: internal compiler error: in add_AT_specification, at
> dwarf2out.c:3985
> 0x629ad9 add_AT_specification
> /export/gnu/import/git/gcc/gcc/dwarf2out.c:3985
> 0x64dabb gen_variable_die
> /export/gnu/import/git/gcc/gcc/dwarf2out.c:18327
> 0x65336b gen_decl_die
> /export/gnu/import/git/gcc/gcc/dwarf2out.c:20033
> 0x653fcd dwarf2out_decl(tree_node*)
> /export/gnu/import/git/gcc/gcc/dwarf2out.c:20348
> 0x6535f9 dwarf2out_global_decl
> /export/gnu/import/git/gcc/gcc/dwarf2out.c:20083
> 0x997703 emit_debug_global_declarations(tree_node**, int)
> /export/gnu/import/git/gcc/gcc/toplev.c:530
> 0x521aaa lto_write_globals
> /export/gnu/import/git/gcc/gcc/lto/lto-lang.c:1067
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.
> make[6]: *** [/tmp/cc3yYR7d.ltrans4.ltrans.o] Error 1
> lto-wrapper: make returned 2 exit status
> /usr/local/x86_64-unknown-linux-gnu/bin/ld: lto-wrapper failed
> collect2: error: ld returned 1 exit status
> make[5]: *** [go1] Error 1
>
> This is latent without my patch since no DWARF info on varaibles are
>  generated.  OK to install?
>
> Thanks.
>
>
> H.J.
> ---
> 2012-12-07  H.J. Lu  
>
> PR lto/55466
> * lto-symtab.c (lto_symtab_merge_decls_1): Don't record
> the prevailing variable.
> * lto.c (lto_main): Record the global variables if WPA isn't
> enabled.
>
> diff --git a/gcc/lto-symtab.c b/gcc/lto-symtab.c
> index 0b0cdac..295fd37 100644
> --- a/gcc/lto-symtab.c
> +++ b/gcc/lto-symtab.c
> @@ -443,10 +443,6 @@ lto_symtab_merge_decls_1 (symtab_node first)
>
>symtab_prevail_in_asm_name_hash (prevailing);
>
> -  /* Record the prevailing variable.  */
> -  if (TREE_CODE (prevailing->symbol.decl) == VAR_DECL)
> -vec_safe_push (lto_global_var_decls, prevailing->symbol.decl);
> -

As this is not necessary, the push in lto.c:lto_register_var_decl_in_symtab
for statics should not be necessary either (we even call
rest_of_decl_compilation
there).

Ok with that push removed as well.

Please make sure to file a bugreport for the go LTO bootstrap issue.

Thanks,
Richard.

>/* Diagnose mismatched objects.  */
>for (e = prevailing->symbol.next_sharing_asm_name;
> e; e = e->symbol.next_sharing_asm_name)
> diff --git a/gcc/lto/lto.c b/gcc/lto/lto.c
> index 376af85..e567cb0 100644
> --- a/gcc/lto/lto.c
> +++ b/gcc/lto/lto.c
> @@ -3380,6 +3380,8 @@ lto_main (void)
> do_whole_program_analysis ();
>else
> {
> + struct varpool_node *vnode;
> +
>   timevar_start (TV_PHASE_OPT_GEN);
>
>   materialize_cgraph ();
> @@ -3397,6 +3399,10 @@ lto_main (void)
>  this.  */
>   if (flag_lto_report)
> print_lto_report_1 ();
> +
> + /* Record the global variables.  */
> + FOR_EACH_DEFINED_VARIABLE (vnode)
> +   vec_safe_push (lto_global_var_decls, vnode->symbol.decl);
> }
>  }
>


Re: [patch] [libstdc++] Fix build failure with --enable-libstdcxx-debug

2012-12-10 Thread Jonathan Wakely
On 10 December 2012 08:22, Matthias Klose  wrote:
> Am 10.12.2012 08:19, schrieb Matthias Klose:
>> Seen with a x86_64 x arm x arm cross build and --enable-libstdcxx-debug. The
>> ../config.h should not be hard-coded. Using the macro guarantees that the
>> rewritten macros for the debug builds are used. However I fail to see why the
>> unpatched version does work for the native build.
>>
>> Ok for the trunk and the 4.7 branch?

OK, thanks

> and attaching the patch ...
>
>


Re: [patch] [libstdc++] Fix build failure with --enable-libstdcxx-debug

2012-12-10 Thread Matthias Klose
Am 10.12.2012 08:19, schrieb Matthias Klose:
> Seen with a x86_64 x arm x arm cross build and --enable-libstdcxx-debug. The
> ../config.h should not be hard-coded. Using the macro guarantees that the
> rewritten macros for the debug builds are used. However I fail to see why the
> unpatched version does work for the native build.
> 
> Ok for the trunk and the 4.7 branch?

and attaching the patch ...


# DP: Fix cross build failure with --enable-libstdcxx-debug.

	* src/Makefile.am (libstdc++-symbols.ver): Use CONFIG_HEADER.
	* src/Makefile.in: Regenerate.

--- libstdc++-v3/src/Makefile.am~	2012-12-09 11:55:15.357516806 +0100
+++ libstdc++-v3/src/Makefile.am	2012-12-09 14:48:31.545377728 +0100
@@ -213,7 +213,7 @@
 	  fi; \
 	fi
 	$(EGREP) -v '^[ 	]*#(#| |$$)' $@.tmp | \
-	  $(CC) -E -P -include ../config.h - > $@ || (rm -f $@ ; exit 1)
+	  $(CC) -E -P -include $(CONFIG_HEADER) - > $@ || (rm -f $@ ; exit 1)
 	rm -f $@.tmp
 
 CLEANFILES = libstdc++-symbols.ver