[PATCH, 4.7 testsuite]: Move stack_check3.ad[sb] to gnat.dg directory ...

[Uros Bizjak]

Hello!

... where they belong according to ChangeLog.

2012-12-07  Uros Bizjak  

* stack_check3.ad[sb]: Move to gnat.dg.

[Patch omitted, since it is just trivial move.]

Committed to 4.7 branch.

Uros.

Re: [ARM] Turning off 64bits ops in Neon and gfortran/modulo-scheduling problem

[Christophe Lyon]

Ping?
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg02558.html

Thanks,

Christophe.

On 30 November 2012 17:34, Christophe Lyon  wrote:
> On 29 November 2012 21:59, Joseph S. Myers  wrote:
>> On Thu, 29 Nov 2012, Christophe Lyon wrote:
>>
>>> 2012-11-28  Christophe Lyon  
>>>
>>> gcc/
>>> * config/arm/arm-protos.h (tune_params): Add
>>> prefer_neon_for_64bits field.
>>> * config/arm/arm.c (prefer_neon_for_64bits): New variable.
>>> (arm_slowmul_tune): Default prefer_neon_for_64bits to false.
>>> (arm_fastmul_tune, arm_strongarm_tune, arm_xscale_tune): Ditto.
>>> (arm_9e_tune, arm_v6t2_tune, arm_cortex_tune): Ditto.
>>> (arm_cortex_a5_tune, arm_cortex_a15_tune): Ditto.
>>> (arm_cortex_a9_tune, arm_fa726te_tune): Ditto.
>>> (arm_option_override): Handle -mneon-for-64bits new option.
>>> * config/arm/arm.h (TARGET_PREFER_NEON_64BITS): New macro.
>>> (prefer_neon_for_64bits): Declare new variable.
>>> * config/arm/arm.md (arch): Rename neon_onlya8 and neon_nota8 to
>>> avoid_neon_for_64bits and neon_for_64bits.
>>> (arch_enabled): Handle new arch types.
>>> (one_cmpldi2): Use new arch names.
>>> * config/arm/neon.md (adddi3_neon, subdi3_neon, iordi3_neon)
>>> (anddi3_neon, xordi3_neon, ashldi3_neon, di3_neon): Use
>>> neon_for_64bits instead of nota8 and avoid_neon_for_64bits instead
>>> of onlya8.
>>
>> This ChangeLog entry doesn't appear to mention the arm.opt change.
>> Furthermore, the patch seems to be missing any .texi change to document
>> the option; any new option needs documentation.  You are also missing
>> testcases for the testsuite to verify that both enabled and disabled
>> states of the option work properly.
>>
> Indeed, I forgot about the documentation; here is an updated patch.
>
> Regarding the testcases, as this patch disables transformations
> recently introduced, I would have appreciated if testcases had been
> associated with them in the 1st place This requirement should be
> enforced :-)
>
> Tested with qemu on target arm-none-linux-gnueabi.
>
>
> 2012-11-30  Christophe Lyon  
>
> gcc/
> * config/arm/arm-protos.h (tune_params): Add
> prefer_neon_for_64bits field.
> * config/arm/arm.c (prefer_neon_for_64bits): New variable.
> (arm_slowmul_tune): Default prefer_neon_for_64bits to false.
> (arm_fastmul_tune, arm_strongarm_tune, arm_xscale_tune): Ditto.
> (arm_9e_tune, arm_v6t2_tune, arm_cortex_tune): Ditto.
> (arm_cortex_a5_tune, arm_cortex_a15_tune): Ditto.
> (arm_cortex_a9_tune, arm_fa726te_tune): Ditto.
> (arm_option_override): Handle -mneon-for-64bits new option.
> * config/arm/arm.h (TARGET_PREFER_NEON_64BITS): New macro.
> (prefer_neon_for_64bits): Declare new variable.
> * config/arm/arm.md (arch): Rename neon_onlya8 and neon_nota8 to
> avoid_neon_for_64bits and neon_for_64bits.
> (arch_enabled): Handle new arch types.
> (one_cmpldi2): Use new arch names.
> * config/arm/arm.opt (mneon-for-64bits): Add option.
> * config/arm/neon.md (adddi3_neon, subdi3_neon, iordi3_neon)
> (anddi3_neon, xordi3_neon, ashldi3_neon, di3_neon): Use
> neon_for_64bits instead of nota8 and avoid_neon_for_64bits instead
> of onlya8.
> * doc/invoke.texi (-mneon-for-64bits): Document.
>
> gcc/testsuite/
> * gcc.target/arm/neon-for-64bits-1.c: New tests.
> * gcc.target/arm/neon-for-64bits-2.c: Likewise.

Re: [PATCH, PR 55078] Let indirect inlining look at ipa-cp lattices

[Richard Biener]

On Thu, 6 Dec 2012, Jan Hubicka wrote:

> > Hi,
> > 
> > the patch below re-stores a check in the inlining machinery that makes
> > sure growth estimates match the reality after inlining.  However, in
> > order to do that, I had to teach indirect inlining to look at IPA-CP
> > data because that's what the inlining estimates do.  Even though this
> > makes indirect inlining slightly more powerful, the change is not big
> > and so I hope it qualifies even though we are in stage 3 now.
> > 
> > The patch has passed bootstrap and testing on x86_64-linux.  OK for
> > trunk?
> > 
> > Thanks,
> > 
> > Martin
> > 
> > 
> > 2012-12-05  Martin Jambor  
> > 
> > PR middle-end/55078
> > * ipa-inline-transform.c (inline_call): Turn #if 0 to #ifdef
> > ENABLE_CHECKING.
> > * ipa-prop.c (try_make_edge_direct_simple_call): Use
> > ipa_value_from_jfunc.
> > (try_make_edge_direct_virtual_call): Likewise.
> > (update_indirect_edges_after_inlining): Lookup new_root_info and pass
> > it to the functions above.
> 
> The patch is OK.
> I think it would make sense to have it in stage3, Richi/Jakub can you comment
> from RM perspective?

It fixes a bug and thus is appropriate for stage3 by the rulebook.

Thanks,
Richard.

Re: [PATCH] Don't drop DECL_INITIAL if -g for DWARF2+ (PR fortran/55395)

[Richard Biener]

On Thu, 6 Dec 2012, Jakub Jelinek wrote:

> Hi!
> 
> This patch fixes both a correctness problem (bootstrap failure in
> libgfortran for a couple of targets) and debug info quality issue.
> The correctness issue is about the fact that clearing DECL_INITIAL
> (well, setting it to error_mark_node is the same) in varpool_remove_node
> is changing the decl's bss_initializer_p (decl) status, thus can affect
> section flags of it for DWARF2 if an unused decl has
> e.g. make_decl_rtl_for_debug called from implicit pointer expansion
> before varpool_remove_node and then e.g. during dwarf2out_finish after it.
> This function intentionally doesn't remember the RTL, that could affect
> code generation.
> And for the debug info quality issue see the next patch that actually
> improves use of DECL_INITIAL for debug info generation.
> 
> Even if we add some param to limit the size of the initializers we want to
> emit into debug info, still the varpool_remove_node clearing of the
> initializer would need to be done (if we want to try hard to save compile
> time memory) in a way to keep the bss_initializer_p the same as before,
> so call it before clearing, if it was set, setting it to error_mark_node
> is perhaps fine, if it was set, it needs to be set to some other magic
> value and everything that uses DECL_INITIAL afterwards need to be taught
> about that (including bss_initializer_p not to treat that other magic value
> as bss initializer).
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> 2012-12-06  Jakub Jelinek  
> 
>   PR fortran/55395
>   * varpool.c (varpool_remove_node): Don't drop DECL_INITIAL
>   if -g and emitting DWARF2+.
> 
> --- gcc/varpool.c.jj  2012-11-19 14:41:27.0 +0100
> +++ gcc/varpool.c 2012-12-04 17:42:41.228752645 +0100
> @@ -65,7 +65,10 @@ varpool_remove_node (struct varpool_node
>&& !DECL_VIRTUAL_P (node->symbol.decl)
>/* dbxout output constant initializers for readonly vars.  */
>&& (!host_integerp (DECL_INITIAL (node->symbol.decl), 0)
> -   || !TREE_READONLY (node->symbol.decl)))
> +   || !TREE_READONLY (node->symbol.decl))
> +  /* dwarf2out can use most of the initializers.  */
> +  && write_symbols != DWARF2_DEBUG
> +  && write_symbols != VMS_AND_DWARF2_DEBUG)

Eh, shouldn't we "abstract" this properly?  Like with a bool
flag in debug_hooks?  Or with a hook?  I see now we special-case
dbxout and dwarf2out ... (can all dwarf versions express the
initializers?)

Thanks,
Richard.

Re: [i386] scalar ops that preserve the high part of a vector

[Uros Bizjak]

On Fri, Dec 7, 2012 at 7:49 AM, Michael Zolotukhin
 wrote:
> Hi guys,
> Could I ask several questions just to clarify the things up?
>
> 1) Does the root problem lay in the fact that even for scalar
> additions we perform the addition on the whole vector and only then
> drop the higher parts of the vector? I.e. to fix the test from the PR
> we need to replace plus on vector mode with plus on scalar mode?

Yes, existing pattern is used to implement intrinsics, and it is
modelled with vector operand 2. But we in fact emit scalar operation,
so we would like to model the pattern with a scalar operand 2. This
way, the same pattern can be used to emit intrinsics _and_ can be used
to optimize the code from the testcase at the same time. Also, please
note that alignment requirements for vector operand and scalar
operands are different.

> 2) Is one of the main requirements having the same pattern for V4SF
> and V2DF version?

It is not required, but having macroized pattern avoids pattern
explosion, eases maintenance (it is easier to understand similar
functionality if it is described in some uniform way), and in some
cases, macroization opportunities force author to rethink the RTL
description, making the patterns more "universal".

Uros.

Re: [i386] scalar ops that preserve the high part of a vector

[Marc Glisse]

On Fri, 7 Dec 2012, Michael Zolotukhin wrote:


1) Does the root problem lay in the fact that even for scalar
additions we perform the addition on the whole vector and only then
drop the higher parts of the vector? I.e. to fix the test from the PR
we need to replace plus on vector mode with plus on scalar mode?


The root problem is that we model the subs[sd] instructions as taking a 
128-bit second operand, when Intel's documentation says they take a 
32/64-bit operand, which is an important difference for memory operands 
(and constants). Writing a pattern that reconstructs the result from a 
scalar operation also seems more natural than pretending we are doing a 
parallel operation and dropping most of it (easier for recog and friends).


(note: I think the insn was written to support the intrinsic, which does 
take a 128-bit argument, so it did a good job for that)



2) Is one of the main requirements having the same pattern for V4SF
and V2DF version?


Uros seems to think that would be best.


3) I don't see vec_concat in patterns from your patches, is it
explicitly generated by some x86-expander?


It is generated by ix86_expand_vector_set.


Anyway, I really like the idea of having some uniformity in describing
patterns for scalar instructions, so thank you for the work!


For 2-element vectors, vec_concat does seem more natural than vec_merge. 
If we chose vec_merge as the canonical representation, we should chose it 
for setting an element in a vector (ix86_expand_vector_set) everywhere, 
not just those scalarish operations.


So it would be good to have rth's opinion on this (svn blame seems to 
indicate he is the one who chose to use vec_concat specifically for V2DF 
instead of vec_merge).


--
Marc Glisse

Re: [PATCH, rs6000] Update default loop peel limits

[Richard Biener]

On Thu, Dec 6, 2012 at 10:43 PM, Jan Hubicka  wrote:
>> The following patch restores the old default limits for loop peeling
>> that were recently changed to 100 and caused a 20% degradation in
>> 454.calculix.
>>
>> Bootstrap/regtest on powerpc64-linux with no new regressions. Ok for trunk?
>>
>> -Pat
>>
>>
>> 2012-12-06  Pat Haugen 
>> * config/rs6000/rs6000.c (rs6000_option_override_internal): Set
>> default loop peeling limits.
>
> Actually the calculix regression is also seen on core.
> Igor was looking into what loops got slower and why. Either we can fix that 
> partiuclar
> loop or revert to the old default (that sadly causes quite a lot of code 
> bloat)

Well, as the patch regressed the testcase in put in the testsuite for calculix
that is no surprise... gfortran.dg/reassoc_4.f.  The fix for the testcase was to
increase the limit with a --param :/

Note that it is even beneficial to unroll two more levels of the nest
completely.
It's just an insane testcase (and I spent quite some time on it trying to
somehow autodetect the simplification opportunities - see the unrolling
heuristic rewrite patch I dumped on you a few weeks ago).

No advice from me on how to "fix" this ... but eventually the rewrite restores
the old behavior with the new limits (I did the rewrite to try to somehow make
it do two extra levels of nest unrolling ...).

Richard.

> Honza

Re: [patch] ree.c: don't abuse GTY

[Richard Biener]

On Fri, Dec 7, 2012 at 1:05 AM, Steven Bosscher  wrote:
> Hello,
>
> ree.c's data structures are not GC-allocated, so its GTY markers and
> its TODO_ggc_collect are unnecessary.
>
> Will commit as obvious after the usual testing on my favourite platforms :-)

IMHO TODO_ggc_collect should go and we should collect after each pass run.

Richard.

> * ree.c (struct ext_cand): Remove GTY markers.
> (pass_ree): Remove TODO_ggc_collect.
>
> Index: ree.c
> ===
> --- ree.c   (revision 194247)
> +++ ree.c   (working copy)
> @@ -243,7 +243,7 @@
>
>  /* This structure represents a candidate for elimination.  */
>
> -typedef struct GTY(()) ext_cand
> +typedef struct ext_cand
>  {
>/* The expression.  */
>const_rtx expr;
> @@ -958,7 +958,6 @@
>0,/* properties_provided */
>0,/* properties_destroyed */
>0,/* todo_flags_start */
> -  TODO_ggc_collect |
>TODO_verify_rtl_sharing,  /* todo_flags_finish */
>   }
>  };

Re: C++ PATCH for c++/54325 (wrong error initializing abstract base class)

[Matthias Klose]

Am 07.12.2012 06:05, schrieb Jason Merrill:
> It's perfectly OK to initialize a base class of abstract type; it's only an
> error to create a full object of such a type.  So this patch moves the check
> from more generic initialization code out into a function that's definitely
> creating a new object.
> 
> Tested x86_64-pc-linux-gnu, applying to trunk and 4.7.

this doesn't build on the branch:

../gcc/cp/tree.c: In function 'build_aggr_init_expr':
../gcc/cp/tree.c:399:1: error: parameter name omitted

this fixes the bootstrap, currently running the testsuite.

--- cp/tree.c~  2012-12-07 10:01:16.665415647 +0100
+++ cp/tree.c   2012-12-07 10:11:01.373410862 +0100
@@ -396,7 +396,8 @@
callable.  */

 tree
-build_aggr_init_expr (tree type, tree init, tsubst_flags_t /*complain*/)
+build_aggr_init_expr (tree type, tree init,
+ tsubst_flags_t complain ATTRIBUTE_UNUSED)
 {
   tree fn;
   tree slot;

Re: C++ PATCH for c++/54325 (wrong error initializing abstract base class)

[Jakub Jelinek]

On Fri, Dec 07, 2012 at 10:13:11AM +0100, Matthias Klose wrote:
> Am 07.12.2012 06:05, schrieb Jason Merrill:
> > It's perfectly OK to initialize a base class of abstract type; it's only an
> > error to create a full object of such a type.  So this patch moves the check
> > from more generic initialization code out into a function that's definitely
> > creating a new object.
> > 
> > Tested x86_64-pc-linux-gnu, applying to trunk and 4.7.
> 
> this doesn't build on the branch:
> 
> ../gcc/cp/tree.c: In function 'build_aggr_init_expr':
> ../gcc/cp/tree.c:399:1: error: parameter name omitted
> 
> this fixes the bootstrap, currently running the testsuite.

Please commit as obvious with appropriate ChangeLog entry.

> --- cp/tree.c~2012-12-07 10:01:16.665415647 +0100
> +++ cp/tree.c 2012-12-07 10:11:01.373410862 +0100
> @@ -396,7 +396,8 @@
> callable.  */
> 
>  tree
> -build_aggr_init_expr (tree type, tree init, tsubst_flags_t /*complain*/)
> +build_aggr_init_expr (tree type, tree init,
> +   tsubst_flags_t complain ATTRIBUTE_UNUSED)
>  {
>tree fn;
>tree slot;

Jakub

Re: C++ PATCH for c++/54325 (wrong error initializing abstract base class)

[Matthias Klose]

Am 07.12.2012 10:17, schrieb Jakub Jelinek:
> On Fri, Dec 07, 2012 at 10:13:11AM +0100, Matthias Klose wrote:
>> Am 07.12.2012 06:05, schrieb Jason Merrill:
>>> It's perfectly OK to initialize a base class of abstract type; it's only an
>>> error to create a full object of such a type.  So this patch moves the check
>>> from more generic initialization code out into a function that's definitely
>>> creating a new object.
>>>
>>> Tested x86_64-pc-linux-gnu, applying to trunk and 4.7.
>>
>> this doesn't build on the branch:
>>
>> ../gcc/cp/tree.c: In function 'build_aggr_init_expr':
>> ../gcc/cp/tree.c:399:1: error: parameter name omitted
>>
>> this fixes the bootstrap, currently running the testsuite.
> 
> Please commit as obvious with appropriate ChangeLog entry.
> 
>> --- cp/tree.c~   2012-12-07 10:01:16.665415647 +0100
>> +++ cp/tree.c2012-12-07 10:11:01.373410862 +0100
>> @@ -396,7 +396,8 @@
>> callable.  */
>>
>>  tree
>> -build_aggr_init_expr (tree type, tree init, tsubst_flags_t /*complain*/)
>> +build_aggr_init_expr (tree type, tree init,
>> +  tsubst_flags_t complain ATTRIBUTE_UNUSED)
>>  {
>>tree fn;
>>tree slot;
> 
>   Jakub
> 

comitted.

  Matthias

2012-12-07  Matthias Klose  

* tree.c (build_aggr_init_expr): Add parameter name, mark as unused.

Re: C++ PATCH for c++/55058 (lost cv-quals with typedef in template)

[Paolo Carlini]

On 12/06/2012 11:14 PM, Jason Merrill wrote:
When we look through a typedef, we need to keep any cv-quals that were 
added to it.
Thanks! Patch fixes also c++/54975, but it didn't look (to me ;) as an 
obvious duplicate, thus before closing it, I'm also going to add the 
testcase.


Thanks again,
Paolo.

Re: [PATCH, 4.7 testsuite]: Move stack_check3.ad[sb] to gnat.dg directory ...

[Eric Botcazou]

> 2012-12-07  Uros Bizjak  
> 
>   * stack_check3.ad[sb]: Move to gnat.dg.
> 
> [Patch omitted, since it is just trivial move.]

Thanks for fixing this!

-- 
Eric Botcazou

[RFA] .gitignore: Ignore *.pyc files.

[Joel Brobecker]

Hello,

The GDB sources contain some python files, and executing them
causes these .pyc files to appear.  We could ignore them in GDB
only, but I think this is the type of extension (compilation
artifact) which can be shared amoung all projects.

ChangeLog:

* .gitignore: Ignore *.pyc file.

Ok to apply?
Thanks,
-- 
Joel

---
 .gitignore |1 +
 1 file changed, 1 insertion(+)

diff --git a/.gitignore b/.gitignore
index dc1bf3f..8e2e1e9 100644
--- a/.gitignore
+++ b/.gitignore
@@ -12,6 +12,7 @@
 *.la
 *.lo
 *.o
+*.pyc
 *.tmp
 
 .deps
-- 
1.7.10.4

Re: [patch] ree.c: don't abuse GTY

[Steven Bosscher]

On Fri, Dec 7, 2012 at 10:08 AM, Richard Biener
 wrote:
> On Fri, Dec 7, 2012 at 1:05 AM, Steven Bosscher  wrote:
>> Hello,
>>
>> ree.c's data structures are not GC-allocated, so its GTY markers and
>> its TODO_ggc_collect are unnecessary.
>>
>> Will commit as obvious after the usual testing on my favourite platforms :-)
>
> IMHO TODO_ggc_collect should go and we should collect after each pass run.

IOPEHO (*) ggc_collect should go, period. I don't think that running
it after each pass would be a good start: It would make any serious
test with GCAC checking enabled almost impossible.

In the mean time -- comments on my patch?

Ciao!
Steven




(* In Other Peope's Equally Humble Opinions :-) )

Re: [patch] ree.c: don't abuse GTY

[Steven Bosscher]

On Fri, Dec 7, 2012 at 10:42 AM, Steven Bosscher wrote:
> In the mean time -- comments on my patch?

Oh, never mind, I forgot I was going to commit this as obvious :-)

Ciao!
Steven

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

[Steven Bosscher]

Ping?

On Sun, Dec 2, 2012 at 9:27 PM, Steven Bosscher wrote:
> Hello,
>
> The C++ front end pushes everything through the compiler queue after
> writing a PCH. This is pointless: After the PCH is written nothing the
> compiler does has any effect on it anymore.
>
> This patch makes the C++ front end stop after writing the PCH,
> speeding up PCH creation
>
> The C front end has behaved this way since 2004
> (http://gcc.gnu.org/ml/gcc-patches/2004-07/msg00738.html).
>
> Bootstrapped&tested on powerpc64-unknown-linux-gnu and 
> x86_64-unknown-linux-gnu.
> OK for trunk?
>
> Ciao!
> Steven
>
>
>
> * decl2.c (cp_write_global_declarations): Return after writing a PCH.
>
> Index: decl2.c
> ===
> --- decl2.c (revision 194052)
> +++ decl2.c (working copy)
> @@ -3944,8 +3944,13 @@ cp_write_global_declarations (void)
>|| !vec_safe_is_empty (decl_namespace_list))
>  return;
>
> +  /* This is the point to write out a PCH if we're doing that.
> + In that case we do not want to do anything else.  */
>if (pch_file)
> -c_common_write_pch ();
> +{
> +  c_common_write_pch ();
> +  return;
> +}
>
>cgraph_process_same_body_aliases ();
>
>
>
>
> Compile time at -O2 (test = patched, orig = unpatched):
> $ for i in 1 2 3 ; do time ~/devel/build-test/gcc/xg++
> -B../devel/build-test/gcc/ -w -O2 slow.h ; done ; ls -ltr
>
> real0m8.577s
> user0m8.037s
> sys 0m0.540s
>
> real0m8.580s
> user0m8.093s
> sys 0m0.484s
>
> real0m8.595s
> user0m8.093s
> sys 0m0.500s
> total 100440
> -rw-r--r-- 1 stevenb stevenb  4017783 2012-12-02 21:16 slow.h
> -rw-r--r-- 1 stevenb stevenb 98722192 2012-12-02 21:20 slow.h.gch
> $ for i in 1 2 3 ; do time ~/devel/build-orig/gcc/xg++
> -B../devel/build-orig/gcc/ -w -O2 slow.h ; done ; ls -ltr
>
> real0m10.795s
> user0m10.273s
> sys 0m0.520s
>
> real0m10.876s
> user0m10.365s
> sys 0m0.544s
>
> real0m10.767s
> user0m10.245s
> sys 0m0.520s
> total 100440
> -rw-r--r-- 1 stevenb stevenb  4017783 2012-12-02 21:16 slow.h
> -rw-r--r-- 1 stevenb stevenb 98722192 2012-12-02 21:20 slow.h.gch

Re: [patch] ree.c: don't abuse GTY

[Jakub Jelinek]

On Fri, Dec 07, 2012 at 10:51:39AM +0100, Steven Bosscher wrote:
> On Fri, Dec 7, 2012 at 10:42 AM, Steven Bosscher wrote:
> > In the mean time -- comments on my patch?
> 
> Oh, never mind, I forgot I was going to commit this as obvious :-)

I'd say removing the GTY(()) on a struct that is never GC allocated
nor interesting to PCH is obvious, the removal of TODO_ggc_collect is not
so.  Right now it is set by passes that expect to potentially
create enough GC garbage that a collection might be desirable.
You haven't explained why you think it is the case of ree.c.

Jakub

Re: C++ PATCH for c++/54325 (wrong error initializing abstract base class)

[Paolo Carlini]

Hi,

On 12/07/2012 10:24 AM, Matthias Klose wrote:

committed.

   Matthias

2012-12-07  Matthias Klose  

 * tree.c (build_aggr_init_expr): Add parameter name, mark as unused.

Thanks.

I was wondering if in mainline we could just do the below. It seems 
straightforward enough...


Thanks!
Paolo.

///



2012-12-07  Paolo Carlini  

* tree.c (build_aggr_init_expr): Remove tsubst_flags_t parameter.
(build_cplus_new): Adjust.
* cp-tree.h: Adjust declaration.
* init.c (build_value_init): Adjust.
Index: cp-tree.h
===
--- cp-tree.h   (revision 194296)
+++ cp-tree.h   (working copy)
@@ -5762,7 +5762,7 @@ extern tree build_min_nt_loc  
(location_t, enum t
 extern tree build_min_non_dep  (enum tree_code, tree, ...);
 extern tree build_min_non_dep_call_vec (tree, tree, vec 
*);
 extern tree build_cplus_new(tree, tree, tsubst_flags_t);
-extern tree build_aggr_init_expr   (tree, tree, tsubst_flags_t);
+extern tree build_aggr_init_expr   (tree, tree);
 extern tree get_target_expr(tree);
 extern tree get_target_expr_sfinae (tree, tsubst_flags_t);
 extern tree build_cplus_array_type (tree, tree);
Index: init.c
===
--- init.c  (revision 194296)
+++ init.c  (working copy)
@@ -350,8 +350,7 @@ build_value_init (tree type, tsubst_flags_t compla
  (type,
   build_special_member_call (NULL_TREE, complete_ctor_identifier,
  NULL, type, LOOKUP_NORMAL,
- complain),
-  complain);
+ complain));
   else if (TYPE_HAS_COMPLEX_DFLT (type))
{
  /* This is a class that needs constructing, but doesn't have
@@ -361,7 +360,7 @@ build_value_init (tree type, tsubst_flags_t compla
  tree ctor = build_special_member_call
(NULL_TREE, complete_ctor_identifier,
 NULL, type, LOOKUP_NORMAL, complain);
- ctor = build_aggr_init_expr (type, ctor, complain);
+ ctor = build_aggr_init_expr (type, ctor);
  if (ctor != error_mark_node)
AGGR_INIT_ZERO_FIRST (ctor) = 1;
  return ctor;
Index: tree.c
===
--- tree.c  (revision 194296)
+++ tree.c  (working copy)
@@ -407,7 +407,7 @@ build_aggr_init_array (tree return_type, tree fn,
callable.  */
 
 tree
-build_aggr_init_expr (tree type, tree init, tsubst_flags_t /*complain*/)
+build_aggr_init_expr (tree type, tree init)
 {
   tree fn;
   tree slot;
@@ -469,7 +469,7 @@ tree
 tree
 build_cplus_new (tree type, tree init, tsubst_flags_t complain)
 {
-  tree rval = build_aggr_init_expr (type, init, complain);
+  tree rval = build_aggr_init_expr (type, init);
   tree slot;
 
   /* Make sure that we're not trying to create an instance of an

Re: [patch] ree.c: don't abuse GTY

[Steven Bosscher]

On Fri, Dec 7, 2012 at 10:57 AM, Jakub Jelinek wrote:
> I'd say removing the GTY(()) on a struct that is never GC allocated
> nor interesting to PCH is obvious, the removal of TODO_ggc_collect is not
> so.  Right now it is set by passes that expect to potentially
> create enough GC garbage that a collection might be desirable.
> You haven't explained why you think it is the case of ree.c.

You're right, I should have explained it.

Perhaps somewhere during the development of ree.c struct ext_cand was
GGC-allocated, in which case TODO_ggc_collect would make sense, to
collect the ext_cands (there can be many of them). But since ext_cands
are not GGC-allocated, the only garbage "produced" by ree.c is when it
removes redundant extensions (via delete_insn). This is typically only
a very small percentage of the instructions, so there isn't a lot of
garbage produced.

I'll leave the TODO in place, and only remove the GTY marker from
struct ext_cand.

Ciao!
Steven

Re: [PATCH] Don't drop DECL_INITIAL if -g for DWARF2+ (PR fortran/55395)

[Jakub Jelinek]

On Fri, Dec 07, 2012 at 09:38:06AM +0100, Richard Biener wrote:
> > 2012-12-06  Jakub Jelinek  
> > 
> > PR fortran/55395
> > * varpool.c (varpool_remove_node): Don't drop DECL_INITIAL
> > if -g and emitting DWARF2+.
> > 
> > --- gcc/varpool.c.jj2012-11-19 14:41:27.0 +0100
> > +++ gcc/varpool.c   2012-12-04 17:42:41.228752645 +0100
> > @@ -65,7 +65,10 @@ varpool_remove_node (struct varpool_node
> >&& !DECL_VIRTUAL_P (node->symbol.decl)
> >/* dbxout output constant initializers for readonly vars.  */
> >&& (!host_integerp (DECL_INITIAL (node->symbol.decl), 0)
> > - || !TREE_READONLY (node->symbol.decl)))
> > + || !TREE_READONLY (node->symbol.decl))
> > +  /* dwarf2out can use most of the initializers.  */
> > +  && write_symbols != DWARF2_DEBUG
> > +  && write_symbols != VMS_AND_DWARF2_DEBUG)
> 
> Eh, shouldn't we "abstract" this properly?  Like with a bool
> flag in debug_hooks?  Or with a hook?  I see now we special-case
> dbxout and dwarf2out ... (can all dwarf versions express the
> initializers?)

Debug hook for this sounds like overkill.  If you prefer, as debug info
formats other than dwarf2 are just legacy anyway, we could drop the dbxout
special case and just do && write_symbols == NO_DEBUG or
&& debug_info_level == DINFO_LEVEL_NONE.

And yes, all dwarf versions can express at least some of the initializers.

Jakub

Re: [patch] ree.c: don't abuse GTY

[Jakub Jelinek]

On Fri, Dec 07, 2012 at 11:25:38AM +0100, Steven Bosscher wrote:
> Perhaps somewhere during the development of ree.c struct ext_cand was
> GGC-allocated, in which case TODO_ggc_collect would make sense, to
> collect the ext_cands (there can be many of them). But since ext_cands
> are not GGC-allocated, the only garbage "produced" by ree.c is when it
> removes redundant extensions (via delete_insn). This is typically only
> a very small percentage of the instructions, so there isn't a lot of
> garbage produced.

That isn't the only garbage produced, it also updates the PATTERNs of
various instructions with something different.  Have you done any
measurement on what kind of percentage of the instructions is modified,
or is "very small percentage" just a guess?  E.g. on x86_64 it changes quite
a lot of instructions if I remember well.  I'm not saying we can't live
without GC collection after REE, just saying it isn't at all obvious.

Jakub

Re: [PATCH] Don't drop DECL_INITIAL if -g for DWARF2+ (PR fortran/55395)

[Richard Biener]

On Fri, 7 Dec 2012, Jakub Jelinek wrote:

> On Fri, Dec 07, 2012 at 09:38:06AM +0100, Richard Biener wrote:
> > > 2012-12-06  Jakub Jelinek  
> > > 
> > >   PR fortran/55395
> > >   * varpool.c (varpool_remove_node): Don't drop DECL_INITIAL
> > >   if -g and emitting DWARF2+.
> > > 
> > > --- gcc/varpool.c.jj  2012-11-19 14:41:27.0 +0100
> > > +++ gcc/varpool.c 2012-12-04 17:42:41.228752645 +0100
> > > @@ -65,7 +65,10 @@ varpool_remove_node (struct varpool_node
> > >&& !DECL_VIRTUAL_P (node->symbol.decl)
> > >/* dbxout output constant initializers for readonly vars.  */
> > >&& (!host_integerp (DECL_INITIAL (node->symbol.decl), 0)
> > > -   || !TREE_READONLY (node->symbol.decl)))
> > > +   || !TREE_READONLY (node->symbol.decl))
> > > +  /* dwarf2out can use most of the initializers.  */
> > > +  && write_symbols != DWARF2_DEBUG
> > > +  && write_symbols != VMS_AND_DWARF2_DEBUG)
> > 
> > Eh, shouldn't we "abstract" this properly?  Like with a bool
> > flag in debug_hooks?  Or with a hook?  I see now we special-case
> > dbxout and dwarf2out ... (can all dwarf versions express the
> > initializers?)
> 
> Debug hook for this sounds like overkill.  If you prefer, as debug info
> formats other than dwarf2 are just legacy anyway, we could drop the dbxout
> special case and just do && write_symbols == NO_DEBUG or
> && debug_info_level == DINFO_LEVEL_NONE.
> 
> And yes, all dwarf versions can express at least some of the initializers.

Then I'd say do && debug_info_level <= DINFO_LEVEL_TERSE.

Richard.

Re: [i386] scalar ops that preserve the high part of a vector

[Michael Zolotukhin]

Thanks for the explanation!

By the way, if we decide to have one pattern for V4SF instructions and
another for V2DF, we could try to use recently introduced define_subst
here. It won't reduce number of actual patterns (I mean number of
patterns after iterators and subst expanding), but it could help to
make sse.md more compact.

On 7 December 2012 12:49, Marc Glisse  wrote:
> On Fri, 7 Dec 2012, Michael Zolotukhin wrote:
>
>> 1) Does the root problem lay in the fact that even for scalar
>> additions we perform the addition on the whole vector and only then
>> drop the higher parts of the vector? I.e. to fix the test from the PR
>> we need to replace plus on vector mode with plus on scalar mode?
>
>
> The root problem is that we model the subs[sd] instructions as taking a
> 128-bit second operand, when Intel's documentation says they take a
> 32/64-bit operand, which is an important difference for memory operands (and
> constants). Writing a pattern that reconstructs the result from a scalar
> operation also seems more natural than pretending we are doing a parallel
> operation and dropping most of it (easier for recog and friends).
>
> (note: I think the insn was written to support the intrinsic, which does
> take a 128-bit argument, so it did a good job for that)
>
>
>> 2) Is one of the main requirements having the same pattern for V4SF
>> and V2DF version?
>
>
> Uros seems to think that would be best.
>
>
>> 3) I don't see vec_concat in patterns from your patches, is it
>> explicitly generated by some x86-expander?
>
>
> It is generated by ix86_expand_vector_set.
>
>
>> Anyway, I really like the idea of having some uniformity in describing
>> patterns for scalar instructions, so thank you for the work!
>
>
> For 2-element vectors, vec_concat does seem more natural than vec_merge. If
> we chose vec_merge as the canonical representation, we should chose it for
> setting an element in a vector (ix86_expand_vector_set) everywhere, not just
> those scalarish operations.
>
> So it would be good to have rth's opinion on this (svn blame seems to
> indicate he is the one who chose to use vec_concat specifically for V2DF
> instead of vec_merge).
>
> --
> Marc Glisse



-- 
---
Best regards,
Michael V. Zolotukhin,
Software Engineer
Intel Corporation.

Re: [PATCH] Don't drop DECL_INITIAL if -g for DWARF2+ (PR fortran/55395)

[Jakub Jelinek]

On Fri, Dec 07, 2012 at 11:39:42AM +0100, Richard Biener wrote:
> > > > --- gcc/varpool.c.jj2012-11-19 14:41:27.0 +0100
> > > > +++ gcc/varpool.c   2012-12-04 17:42:41.228752645 +0100
> > > > @@ -65,7 +65,10 @@ varpool_remove_node (struct varpool_node
> > > >&& !DECL_VIRTUAL_P (node->symbol.decl)
> > > >/* dbxout output constant initializers for readonly vars.  */
> > > >&& (!host_integerp (DECL_INITIAL (node->symbol.decl), 0)
> > > > - || !TREE_READONLY (node->symbol.decl)))
> > > > + || !TREE_READONLY (node->symbol.decl))
> > > > +  /* dwarf2out can use most of the initializers.  */
> > > > +  && write_symbols != DWARF2_DEBUG
> > > > +  && write_symbols != VMS_AND_DWARF2_DEBUG)
> > > 
> > > Eh, shouldn't we "abstract" this properly?  Like with a bool
> > > flag in debug_hooks?  Or with a hook?  I see now we special-case
> > > dbxout and dwarf2out ... (can all dwarf versions express the
> > > initializers?)
> > 
> > Debug hook for this sounds like overkill.  If you prefer, as debug info
> > formats other than dwarf2 are just legacy anyway, we could drop the dbxout
> > special case and just do && write_symbols == NO_DEBUG or
> > && debug_info_level == DINFO_LEVEL_NONE.
> > 
> > And yes, all dwarf versions can express at least some of the initializers.
> 
> Then I'd say do && debug_info_level <= DINFO_LEVEL_TERSE.

That would still mean we can fail bootstrap with -O2 -g1, if there is a
DEBUG_IMPLICIT_PTR created during RTL expansion to some unused var, then
that var's varpool node is varpool_remove_node removed and initializer
cleared, and dwarf2out_finish would want to make_decl_rtl_for_debug again.

Jakub

Re: [PATCH] Don't drop DECL_INITIAL if -g for DWARF2+ (PR fortran/55395)

[Richard Biener]

On Fri, 7 Dec 2012, Jakub Jelinek wrote:

> On Fri, Dec 07, 2012 at 11:39:42AM +0100, Richard Biener wrote:
> > > > > --- gcc/varpool.c.jj  2012-11-19 14:41:27.0 +0100
> > > > > +++ gcc/varpool.c 2012-12-04 17:42:41.228752645 +0100
> > > > > @@ -65,7 +65,10 @@ varpool_remove_node (struct varpool_node
> > > > >&& !DECL_VIRTUAL_P (node->symbol.decl)
> > > > >/* dbxout output constant initializers for readonly vars.  */
> > > > >&& (!host_integerp (DECL_INITIAL (node->symbol.decl), 0)
> > > > > -   || !TREE_READONLY (node->symbol.decl)))
> > > > > +   || !TREE_READONLY (node->symbol.decl))
> > > > > +  /* dwarf2out can use most of the initializers.  */
> > > > > +  && write_symbols != DWARF2_DEBUG
> > > > > +  && write_symbols != VMS_AND_DWARF2_DEBUG)
> > > > 
> > > > Eh, shouldn't we "abstract" this properly?  Like with a bool
> > > > flag in debug_hooks?  Or with a hook?  I see now we special-case
> > > > dbxout and dwarf2out ... (can all dwarf versions express the
> > > > initializers?)
> > > 
> > > Debug hook for this sounds like overkill.  If you prefer, as debug info
> > > formats other than dwarf2 are just legacy anyway, we could drop the dbxout
> > > special case and just do && write_symbols == NO_DEBUG or
> > > && debug_info_level == DINFO_LEVEL_NONE.
> > > 
> > > And yes, all dwarf versions can express at least some of the initializers.
> > 
> > Then I'd say do && debug_info_level <= DINFO_LEVEL_TERSE.
> 
> That would still mean we can fail bootstrap with -O2 -g1, if there is a
> DEBUG_IMPLICIT_PTR created during RTL expansion to some unused var, then
> that var's varpool node is varpool_remove_node removed and initializer
> cleared, and dwarf2out_finish would want to make_decl_rtl_for_debug again.

"fail"?  Well, dwarf2out_finish definitely has to care for no initializer
being in-place.  Does it somehow record that it was present somewhen
early and is confused later when it got dropped?  If so, why not always
decide late if there is an initializer?

Richard.

Ping[3]: [PATCH v2] PR tree-optimization/55079: Don't remove all exits of a loop during loop unroll

[Siddhesh Poyarekar]

Ping!

On Tue, Nov 27, 2012 at 03:32:46PM +0530, Siddhesh Poyarekar wrote:
> Ping!
> 
> Siddhesh
> 
> On Wed, Nov 21, 2012 at 12:42:13PM +0530, Siddhesh Poyarekar wrote:
> > Hi,
> > 
> > Ping!
> > 
> > 
> > Siddhesh
> > 
> > On Thu, 15 Nov 2012 19:05:38 +0530, Siddhesh wrote:
> > 
> > > Hi,
> > > 
> > > Here's an updated version of the patch which warns the user if the
> > > removing of redundant exits results in an infinite loop.  I have added
> > > an additional flag in struct loop called external_exits to record if
> > > an exit edge is moved outside the loop body.  This currently happens
> > > in the loop-unswitch pass and was the root cause of the regression in
> > > torture/pr49518.c that I talked about earlier.  The patch now passes
> > > all regression tests except a mudflap case (fail37-frag).  The test is
> > > already broken due to removal of all exits so I haven't attempted to
> > > fix it as part of this patch.  How does this version look?
> > > 
> > > Regards,
> > > Siddhesh
> > > 
> > > gcc/ChangeLog:
> > > 
> > >   * cfgloop.h (struct loop): New member EXTERNAL_EXITS.
> > >   * tree-ssa-loop-ivcanon.c (remove_redundant_iv_tests) Warn
> > > when loop is left without any exits.
> > >   * tree-ssa-loop-unswitch.c (tree_unswitch_single_loop): Set
> > >   EXTERNAL_EXITS when moving a statement with an exit edge out
> > > of the loop body.
> > 

Re: [PATCH] Don't drop DECL_INITIAL if -g for DWARF2+ (PR fortran/55395)

[Jakub Jelinek]

On Fri, Dec 07, 2012 at 12:23:03PM +0100, Richard Biener wrote:
> > That would still mean we can fail bootstrap with -O2 -g1, if there is a
> > DEBUG_IMPLICIT_PTR created during RTL expansion to some unused var, then
> > that var's varpool node is varpool_remove_node removed and initializer
> > cleared, and dwarf2out_finish would want to make_decl_rtl_for_debug again.
> 
> "fail"?  Well, dwarf2out_finish definitely has to care for no initializer
> being in-place.  Does it somehow record that it was present somewhen
> early and is confused later when it got dropped?  If so, why not always
> decide late if there is an initializer?

How?  During expansion to create DEBUG_IMPLICIT_PTR argument, we need some
RTL for the vars (and can't make it using make_decl_rtl, as that would
affect code generation).  So, we use make_decl_rtl_for_debug that doesn't
remember the RTL, but still it does all the processing make_decl_rtl
normally does.  bss_initializer_p is called deeply from that somewhere.
As I said in the PR/initial mail, the other option would be to come up with
some other special value for this DECL_INITIAL has been forgotten, but
it wasn't bss_initializer_p.  But that seems to be lots of work for very
little gain (rarely used -g1).

Jakub

Re: [patch] ree.c: don't abuse GTY

[Steven Bosscher]

On Fri, Dec 7, 2012 at 11:34 AM, Jakub Jelinek wrote:
> On Fri, Dec 07, 2012 at 11:25:38AM +0100, Steven Bosscher wrote:
>> Perhaps somewhere during the development of ree.c struct ext_cand was
>> GGC-allocated, in which case TODO_ggc_collect would make sense, to
>> collect the ext_cands (there can be many of them). But since ext_cands
>> are not GGC-allocated, the only garbage "produced" by ree.c is when it
>> removes redundant extensions (via delete_insn). This is typically only
>> a very small percentage of the instructions, so there isn't a lot of
>> garbage produced.
>
> That isn't the only garbage produced, it also updates the PATTERNs of
> various instructions with something different.  Have you done any
> measurement on what kind of percentage of the instructions is modified,
> or is "very small percentage" just a guess?

I almost never guess, and try to measure the impact of my patches.

In this case, I couldn't even get the garbage collector to trigger
without bringing the collection threshold down by a factor 10 or so.

Ciao!
Steven

Re: [PATCH] Don't drop DECL_INITIAL if -g for DWARF2+ (PR fortran/55395)

[Richard Biener]

On Fri, 7 Dec 2012, Jakub Jelinek wrote:

> On Fri, Dec 07, 2012 at 12:23:03PM +0100, Richard Biener wrote:
> > > That would still mean we can fail bootstrap with -O2 -g1, if there is a
> > > DEBUG_IMPLICIT_PTR created during RTL expansion to some unused var, then
> > > that var's varpool node is varpool_remove_node removed and initializer
> > > cleared, and dwarf2out_finish would want to make_decl_rtl_for_debug again.
> > 
> > "fail"?  Well, dwarf2out_finish definitely has to care for no initializer
> > being in-place.  Does it somehow record that it was present somewhen
> > early and is confused later when it got dropped?  If so, why not always
> > decide late if there is an initializer?
> 
> How?  During expansion to create DEBUG_IMPLICIT_PTR argument, we need some
> RTL for the vars (and can't make it using make_decl_rtl, as that would
> affect code generation).  So, we use make_decl_rtl_for_debug that doesn't
> remember the RTL, but still it does all the processing make_decl_rtl
> normally does.  bss_initializer_p is called deeply from that somewhere.
> As I said in the PR/initial mail, the other option would be to come up with
> some other special value for this DECL_INITIAL has been forgotten, but
> it wasn't bss_initializer_p.  But that seems to be lots of work for very
> little gain (rarely used -g1).

Hmm.  Then make it DINFO_LEVEL_NONE and put in a fixme comment refering
to the bugreport.

Richard.

[PATCH] Fix PR54886

[Richard Biener]

This fixes PR54886 - ISL is anal about freeing all its memory.

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

Richard.

2012-12-07  Richard Biener  

PR tree-optimization/54886
* graphite-sese-to-poly.c (build_loop_iteration_domains): Properly
free all memory.

Index: gcc/graphite-sese-to-poly.c
===
--- gcc/graphite-sese-to-poly.c (revision 194296)
+++ gcc/graphite-sese-to-poly.c (working copy)
@@ -1058,6 +1058,8 @@ build_loop_iteration_domains (scop_p sco
  c = isl_constraint_set_constant (c, v);
  inner = isl_set_add_constraint (inner, c);
}
+  else
+   isl_pw_aff_free (aff);
 }
   else
 gcc_unreachable ();

PING: [PATCH] Support -fuse-ld=bfd and -fuse-ld=gold

[H.J. Lu]

On Wed, Nov 28, 2012 at 8:18 PM, H.J. Lu  wrote:
>
> Binutils supports 2 linkers, ld.gold and ld.bfd.  One of them is
> configured as the default linker, ld, which is used by GCC.  Sometimes,
> we want to use the alternate linker with GCC at run-time.  This patch
> adds -fuse-ld=bfd and -fuse-ld=gold options to GCC driver.  It changes
> collect2.c to pick either ld.bfd or ld.gold.  It also adds
> ORIGINAL_LD_BFD_FOR_TARGET and ORIGINAL_LD_GOLD_FOR_TARGET to
> exec-tool.in to add -fuse-ld=bfd and -fuse-ld=gold support to
> collect-ld.  Since ld.bfd nor ld.gold know the new options, you
> will get
>
> # ./xgcc -B./  /tmp/x.c -fuse-ld=gold -v
> ...
> ./collect-ld --eh-frame-hdr -m elf_x86_64 -dynamic-linker 
> /lib64/ld-linux-x86-64.so.2 -fuse-ld=gold /lib/../lib64/crt1.o 
> /lib/../lib64/crti.o ./crtbegin.o -L. -L/lib/../lib64 -L/usr/lib/../lib64 
> /tmp/cclVWcGz.o -v -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc 
> --as-needed -lgcc_s --no-as-needed ./crtend.o /lib/../lib64/crtn.o
> GNU gold (Linux/GNU Binutils 2.23.51.0.7.20121127) 1.11
> /usr/local/bin/ld.gold: fatal error: -f/--auxiliary may not be used without 
> -shared
> collect2: error: ld returned 1 exit status
>
> This is because we pass everything to ld and ld.bfd/ld.gold doesn't
> understand -fuse-ld=bfd/-fuse-ld=gold.  It isn't a problem for collect2
> since it will filter-out -fuse-ld=bfd/-fuse-ld=gold.  I will submit a
> binutils patch to ignore -fuse-ld=bfd/-fuse-ld=gold, similar to -flto
> options.
>
> OK to install?
>
> Thanks.
>
>
> H.J.
> ---
> 2012-11-28   Nick Clifton  
>  Matthias Klose 
>  Doug Kwan  
>  H.J. Lu  
>
> PR driver/55470
> * collect2.c (main): Support -fuse-ld=bfd and -fuse-ld=gold.
>
> * common.opt: Add fuse-ld=bfd and fuse-ld=gold.
>
> * gcc.c (LINK_COMMAND_SPEC): Pass -fuse-ld=* to collect2.
>
> * opts.c (comman_handle_option): Ignore -fuse-ld=bfd and
> -fuse-ld=gold.
>
> * doc/invoke.texi: Document -fuse-ld=bfd and -fuse-ld=gold.

Here is the minimum patch for 4.8.  OK to install?


-- 
H.J.
---
diff --git a/gcc/collect2.c b/gcc/collect2.c
index 49c4030..4e8cdf0 100644
--- a/gcc/collect2.c
+++ b/gcc/collect2.c
@@ -842,8 +842,21 @@ maybe_run_lto_and_relink (char **lto_ld_argv,
char **object_lst,
 int
 main (int argc, char **argv)
 {
-  static const char *const ld_suffix   = "ld";
-  static const char *const plugin_ld_suffix = PLUGIN_LD_SUFFIX;
+  enum linker_select
+{
+  USE_DEFAULT_LD,
+  USE_PLUGIN_LD,
+  USE_GOLD_LD,
+  USE_BFD_LD,
+  USE_LD_MAX
+} selected_linker = USE_DEFAULT_LD;
+  static const char *const ld_suffixes[USE_LD_MAX] =
+{
+  "ld",
+  PLUGIN_LD_SUFFIX,
+  "ld.gold",
+  "ld.bfd"
+};
   static const char *const real_ld_suffix = "real-ld";
   static const char *const collect_ld_suffix = "collect-ld";
   static const char *const nm_suffix   = "nm";
@@ -854,16 +867,13 @@ main (int argc, char **argv)
   static const char *const strip_suffix = "strip";
   static const char *const gstrip_suffix = "gstrip";

+  const char *full_ld_suffixes[USE_LD_MAX];
 #ifdef CROSS_DIRECTORY_STRUCTURE
   /* If we look for a program in the compiler directories, we just use
  the short name, since these directories are already system-specific.
  But it we look for a program in the system directories, we need to
  qualify the program name with the target machine.  */

-  const char *const full_ld_suffix =
-concat(target_machine, "-", ld_suffix, NULL);
-  const char *const full_plugin_ld_suffix =
-concat(target_machine, "-", plugin_ld_suffix, NULL);
   const char *const full_nm_suffix =
 concat (target_machine, "-", nm_suffix, NULL);
   const char *const full_gnm_suffix =
@@ -877,13 +887,11 @@ main (int argc, char **argv)
   const char *const full_gstrip_suffix =
 concat (target_machine, "-", gstrip_suffix, NULL);
 #else
-  const char *const full_ld_suffix = ld_suffix;
-  const char *const full_plugin_ld_suffix = plugin_ld_suffix;
-  const char *const full_nm_suffix = nm_suffix;
-  const char *const full_gnm_suffix= gnm_suffix;
 #ifdef LDD_SUFFIX
   const char *const full_ldd_suffix= ldd_suffix;
 #endif
+  const char *const full_nm_suffix = nm_suffix;
+  const char *const full_gnm_suffix= gnm_suffix;
   const char *const full_strip_suffix  = strip_suffix;
   const char *const full_gstrip_suffix = gstrip_suffix;
 #endif /* CROSS_DIRECTORY_STRUCTURE */
@@ -900,6 +908,7 @@ main (int argc, char **argv)
   char **ld1_argv;
   const char **ld1;
   bool use_plugin = false;
+  bool use_collect_ld = false;

   /* The kinds of symbols we will have to consider when scanning the
  outcome of a first pass link.  This is ALL to start with, then might
@@ -919,6 +928,15 @@ main (int argc, char **argv)
   int first_file;
   int num_c_args;
   char **old_argv;
+  int i;
+
+  for (i = 0; i < USE_LD_MAX; i++)
+full_ld_suffixes[i]
+#ifdef CROSS_

RE: [RFC] New feature to reuse one multilib among different targets

[Terry Guo]

> -Original Message-
> From: Joseph Myers [mailto:jos...@codesourcery.com]
> Sent: Friday, December 07, 2012 2:04 AM
> To: Terry Guo
> Cc: gcc-patches@gcc.gnu.org
> Subject: RE: [RFC] New feature to reuse one multilib among different
> targets
> 
> On Tue, 13 Nov 2012, Terry Guo wrote:
> 
> > +@findex MULTILIB_REUSE
> > +@item MULTILIB_REUSE
> > +Sometimes it is desirable to reuse one existing multilib among
> different
> > +targets.  Such kind of reuse can minimize the number of multilib
> variants.
> 
> I don't think "among different targets" is the right wording here.
> "for
> different sets of options"?
> 

Updated with your comments.

> > +A typical reuse rule is comprised of two parts connected by equality
> sign.
> 
> Not just a typical reuse rule, but *any* reuse rule, as I understand it.
> 

You are right. Removed the word "typical".

> > +The left part of the rule are the options used to build multilib and
> the right
> > +part are the options representing target that will reuse this
> multilib.  The
> > +equality sign in both parts should be replaced with period.
> 
> Is the order of the options significant, on either or both sides?  Can
> the
> options on the right hand side be options that aren't used to build any
> multilibs?  I think the documentation should answer that sort of
> question.
> 

Yes, the option order in left part matters. More explanations are added as
in patch.

> > @@ -7475,10 +7484,16 @@ set_multilib_dir (void)
> >
> >first = 1;
> >p = multilib_select;
> > +
> > +  /* Append multilib reuse rules if any.  With those rules, we can
> reuse
> > + one multilib for certain different targets.  */
> > +  if (strlen(multilib_reuse) > 0)
> 
> Missing space before '('.
> 

Added the missing space.

> > -  /* Ignore newlines.  */
> > -  if (*p == '\n')
> > +  /* Ignore newlinesi and spaces.  */
> 
> Typo "newlinesi".  And why the change to ignore spaces as well - what's
> different about this new feature to require that?
> 

Typo is corrected. I once wanted to enable user to change multilib spec in
gcc driver on the fly by defining own spec file with content:

*multilib:
OWN RULES

or

*multilib:
+ OWN RULES

For the latter case, an extra space will be involved and break the parse of
multilib spec. So I ignore space here.

But as your said we had better not touch those internal data structure, I
give up this idea now.

> > @@ -7491,8 +7506,8 @@ set_multilib_dir (void)
> >   if (*p == '\0')
> > {
> > invalid_select:
> > - fatal_error ("multilib select %qs is invalid",
> > -  multilib_select);
> > + fatal_error ("multilib select %qs%qs is invalid",
> > +  multilib_select, multilib_reuse);
> 
> Printing two quoted strings with no space between the closing quote of
> one
> and the opening quote of the other certainly doesn't seem right.
> (Really
> this whole error message seems pretty bad - it won't make sense to
> users -
> but that's a pre-existing condition.)
> 

An extra space is inserted.

> > +rm -rf tmpmultilib3
> > +cat >tmpmultilib3 <<\EOF
> 
> As I understand it, this is a refactoring of existing code.  The patch
> might be easier to review if the bits that just refactored existing
> code
> into sub-scripts (without any changes to that code) were sent as a
> separate self-contained patch, and then the new feature patch was sent
> as
> a patch applying on top of those.
> 

Your understanding is correct. Now I put code refactor part into patch 00.
Patch 01 is supposed to be applied on top of it.

> > +  # We only care rule that has concrete multilib.
> 
> "care about", I think, but this sentence still doesn't really make
> sense
> to me.  What are the cases that aren't being cared about here, and why
> are
> they valid inputs?  Surely, given a proper MULTILIB_REUSE setting,
> every
> rule in that setting should do something meaningful and rules that
> don't
> should result in errors?
> 

Now an error will be generated once the rule tries to reuse nonexistent
multilib.

Thank you again, Joseph.

BR,
Terry

2012-12-07  Terry Guo  

* gcc/Makefile.in (s-mlib): New argument MULTILIB_REUSE.
* gcc/doc/fragments.texi: Document MULTILIB_REUSE.
* gcc/gcc.c (multilib_reuse): New internal spec.
(set_multilib_dir): Also search multilib from multilib_reuse.
* gcc/genmultilib (tmpmultilib3): Refactor code.
(tmpmultilib4): Ditto.
(multilib_reuse): New multilib argument.


00-multilib-reuse-v5.patch
Description: Binary data


01-multilib-reuse-v5.patch
Description: Binary data

Re: [PING] [PATCH] PR c++/54401 - Confusing diagnostics about type-alias at class scope

[Dodji Seketeli]

Jason Merrill  writes:

> Oops, thought I had sent this before.

No problem.  Thank you for replying now×

> On 11/17/2012 10:23 AM, Dodji Seketeli wrote:
> > - if (cp_parser_parse_definitely (parser))
> > + /* Note that if we actually see the '=' token after the
> > +identifier, cp_parser_alias_declaration commits the
> > +tentative parse.  In that case, we really expects an
> > +alias-declaration.  Otherwise, we expect a using
> > +declaration.  */
> > + alias_decl_expected =
> > +   !cp_parser_uncommitted_to_tentative_parse_p (parser);
> > + cp_parser_parse_definitely (parser);
> 
> Maybe just check whether decl is error_mark_node?

As we further discussed this on IRC, when cp_parser_alias_declaration
returns error_mark_node, it is either because we encountered an error
before the hypothetical '=', in which case we might want to try to
parse a using declaration, or it is because we encountered an error
after the the '=', in which case we committed to parsing an alias
declaration and we must emit a hard error.

And I believe what we want here is to tell the two possible cases
apart.

> 
> > +  if (type == error_mark_node)
> > +return error_mark_node;
> 
> I think for error-recovery we might want to
> cp_parser_skip_to_end_of_block_or_statement as well.

Right, done.

Bootstrapped and tested on x86_64-unknown-linux-gnu against trunk.

gcc/cp/

* parser.c (cp_parser_alias_declaration): Commit to tentative
parse when see the '=' token.  Get out if the type-id is invalid.
Update function comment.
(cp_parser_member_declaration): Don't try to parse a using
declaration if we know that we expected an alias declaration; that
is, if we see the '=' token after the identifier.

gcc/testsuite/

* g++.dg/cpp0x/alias-decl-28.C: New test.
* g++.dg/cpp0x/alias-decl-16.C: Update.
---
 gcc/cp/parser.c| 31 +++---
 gcc/testsuite/g++.dg/cpp0x/alias-decl-16.C |  2 +-
 gcc/testsuite/g++.dg/cpp0x/alias-decl-28.C |  7 +++
 3 files changed, 36 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/alias-decl-28.C

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index a010f1f..c39ef30 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -15262,7 +15262,11 @@ cp_parser_using_declaration (cp_parser* parser,
 /* Parse an alias-declaration.
 
alias-declaration:
- using identifier attribute-specifier-seq [opt] = type-id  */
+ using identifier attribute-specifier-seq [opt] = type-id
+
+   Note that if this function is used in the context of a tentative
+   parse, it commits the currently active tentative parse after it
+   sees the '=' token.  */
 
 static tree
 cp_parser_alias_declaration (cp_parser* parser)
@@ -15295,6 +15299,8 @@ cp_parser_alias_declaration (cp_parser* parser)
   if (cp_parser_error_occurred (parser))
 return error_mark_node;
 
+  cp_parser_commit_to_tentative_parse (parser);
+
   /* Now we are going to parse the type-id of the declaration.  */
 
   /*
@@ -15324,10 +15330,19 @@ cp_parser_alias_declaration (cp_parser* parser)
   if (parser->num_template_parameter_lists)
 parser->type_definition_forbidden_message = saved_message;
 
+  if (type == error_mark_node)
+{
+  cp_parser_skip_to_end_of_block_or_statement (parser);
+  return error_mark_node;
+}
+
   cp_parser_require (parser, CPP_SEMICOLON, RT_SEMICOLON);
 
   if (cp_parser_error_occurred (parser))
-return error_mark_node;
+{
+  cp_parser_skip_to_end_of_block_or_statement (parser);
+  return error_mark_node;
+}
 
   /* A typedef-name can also be introduced by an alias-declaration. The
  identifier following the using keyword becomes a typedef-name. It has
@@ -19063,9 +19078,19 @@ cp_parser_member_declaration (cp_parser* parser)
   else
{
  tree decl;
+ bool alias_decl_expected;
  cp_parser_parse_tentatively (parser);
  decl = cp_parser_alias_declaration (parser);
- if (cp_parser_parse_definitely (parser))
+ /* Note that if we actually see the '=' token after the
+identifier, cp_parser_alias_declaration commits the
+tentative parse.  In that case, we really expects an
+alias-declaration.  Otherwise, we expect a using
+declaration.  */
+ alias_decl_expected =
+   !cp_parser_uncommitted_to_tentative_parse_p (parser);
+ cp_parser_parse_definitely (parser);
+
+ if (alias_decl_expected)
finish_member_declaration (decl);
  else
cp_parser_using_declaration (parser,
diff --git a/gcc/testsuite/g++.dg/cpp0x/alias-decl-16.C 
b/gcc/testsuite/g++.dg/cpp0x/alias-decl-16.C
index d0a..ce6ad0a 100644
--- a/gcc/testsuite/g++.dg/cpp0x/alias-decl-16.C
+++ b/gcc/testsuite/g++.dg/cpp0x/alias-decl-16.C
@@ -23,6 +23,6 @@ template
 using A3 =
 enum B3 {b = 0;

Re: C++ PATCH for c++/54325 (wrong error initializing abstract base class)

[Gabriel Dos Reis]

On Fri, Dec 7, 2012 at 3:13 AM, Matthias Klose  wrote:
> Am 07.12.2012 06:05, schrieb Jason Merrill:
>> It's perfectly OK to initialize a base class of abstract type; it's only an
>> error to create a full object of such a type.  So this patch moves the check
>> from more generic initialization code out into a function that's definitely
>> creating a new object.
>>
>> Tested x86_64-pc-linux-gnu, applying to trunk and 4.7.
>
> this doesn't build on the branch:
>
> ../gcc/cp/tree.c: In function 'build_aggr_init_expr':
> ../gcc/cp/tree.c:399:1: error: parameter name omitted
>
> this fixes the bootstrap, currently running the testsuite.
>
> --- cp/tree.c~  2012-12-07 10:01:16.665415647 +0100
> +++ cp/tree.c   2012-12-07 10:11:01.373410862 +0100
> @@ -396,7 +396,8 @@
> callable.  */
>
>  tree
> -build_aggr_init_expr (tree type, tree init, tsubst_flags_t /*complain*/)
> +build_aggr_init_expr (tree type, tree init,
> + tsubst_flags_t complain ATTRIBUTE_UNUSED)
>  {
>tree fn;
>tree slot;
>

We should definitely teach the compiler to accept the former and not
be silly in requiring the latter when C++.

-- Gaby

Re: C++ PATCH for c++/54325 (wrong error initializing abstract base class)

[Jakub Jelinek]

On Fri, Dec 07, 2012 at 07:34:30AM -0600, Gabriel Dos Reis wrote:
> On Fri, Dec 7, 2012 at 3:13 AM, Matthias Klose  wrote:
> > Am 07.12.2012 06:05, schrieb Jason Merrill:
> >> It's perfectly OK to initialize a base class of abstract type; it's only an
> >> error to create a full object of such a type.  So this patch moves the 
> >> check
> >> from more generic initialization code out into a function that's definitely
> >> creating a new object.
> >>
> >> Tested x86_64-pc-linux-gnu, applying to trunk and 4.7.
> >
> > this doesn't build on the branch:
> >
> > ../gcc/cp/tree.c: In function 'build_aggr_init_expr':
> > ../gcc/cp/tree.c:399:1: error: parameter name omitted
> >
> > this fixes the bootstrap, currently running the testsuite.
> >
> > --- cp/tree.c~  2012-12-07 10:01:16.665415647 +0100
> > +++ cp/tree.c   2012-12-07 10:11:01.373410862 +0100
> > @@ -396,7 +396,8 @@
> > callable.  */
> >
> >  tree
> > -build_aggr_init_expr (tree type, tree init, tsubst_flags_t /*complain*/)
> > +build_aggr_init_expr (tree type, tree init,
> > + tsubst_flags_t complain ATTRIBUTE_UNUSED)
> >  {
> >tree fn;
> >tree slot;
> >
> 
> We should definitely teach the compiler to accept the former and not
> be silly in requiring the latter when C++.

Except that GCC 4.7 doesn't mandate building with C++, so the sources must
be valid C.

Jakub

Re: [PING] [PATCH] PR c++/54401 - Confusing diagnostics about type-alias at class scope

[Gabriel Dos Reis]

On Fri, Dec 7, 2012 at 7:33 AM, Dodji Seketeli  wrote:
> Jason Merrill  writes:
>
>> Oops, thought I had sent this before.
>
> No problem.  Thank you for replying now×
>
>> On 11/17/2012 10:23 AM, Dodji Seketeli wrote:
>> > - if (cp_parser_parse_definitely (parser))
>> > + /* Note that if we actually see the '=' token after the
>> > +identifier, cp_parser_alias_declaration commits the
>> > +tentative parse.  In that case, we really expects an
>> > +alias-declaration.  Otherwise, we expect a using
>> > +declaration.  */
>> > + alias_decl_expected =
>> > +   !cp_parser_uncommitted_to_tentative_parse_p (parser);
>> > + cp_parser_parse_definitely (parser);
>>
>> Maybe just check whether decl is error_mark_node?
>
> As we further discussed this on IRC, when cp_parser_alias_declaration
> returns error_mark_node, it is either because we encountered an error
> before the hypothetical '=', in which case we might want to try to
> parse a using declaration, or it is because we encountered an error
> after the the '=', in which case we committed to parsing an alias
> declaration and we must emit a hard error.
>
> And I believe what we want here is to tell the two possible cases
> apart.

Yes!

>
>>
>> > +  if (type == error_mark_node)
>> > +return error_mark_node;
>>
>> I think for error-recovery we might want to
>> cp_parser_skip_to_end_of_block_or_statement as well.
>
> Right, done.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu against trunk.
>
> gcc/cp/
>
> * parser.c (cp_parser_alias_declaration): Commit to tentative
> parse when see the '=' token.  Get out if the type-id is invalid.
> Update function comment.
> (cp_parser_member_declaration): Don't try to parse a using
> declaration if we know that we expected an alias declaration; that
> is, if we see the '=' token after the identifier.
>
> gcc/testsuite/
>
> * g++.dg/cpp0x/alias-decl-28.C: New test.
> * g++.dg/cpp0x/alias-decl-16.C: Update.
> ---
>  gcc/cp/parser.c| 31 
> +++---
>  gcc/testsuite/g++.dg/cpp0x/alias-decl-16.C |  2 +-
>  gcc/testsuite/g++.dg/cpp0x/alias-decl-28.C |  7 +++
>  3 files changed, 36 insertions(+), 4 deletions(-)
>  create mode 100644 gcc/testsuite/g++.dg/cpp0x/alias-decl-28.C
>
> diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
> index a010f1f..c39ef30 100644
> --- a/gcc/cp/parser.c
> +++ b/gcc/cp/parser.c
> @@ -15262,7 +15262,11 @@ cp_parser_using_declaration (cp_parser* parser,
>  /* Parse an alias-declaration.
>
> alias-declaration:
> - using identifier attribute-specifier-seq [opt] = type-id  */
> + using identifier attribute-specifier-seq [opt] = type-id
> +
> +   Note that if this function is used in the context of a tentative
> +   parse, it commits the currently active tentative parse after it
> +   sees the '=' token.  */

This comment is repeated below; I don't think it is necessary
or should be part of the specification.  In general we don't (and shouldn't)
say this unless a parsing function deviates from the general
parsing strategy -- this one doesn't.


>
>  static tree
>  cp_parser_alias_declaration (cp_parser* parser)
> @@ -15295,6 +15299,8 @@ cp_parser_alias_declaration (cp_parser* parser)
>if (cp_parser_error_occurred (parser))
>  return error_mark_node;
>
> +  cp_parser_commit_to_tentative_parse (parser);
> +
>/* Now we are going to parse the type-id of the declaration.  */
>
>/*
> @@ -15324,10 +15330,19 @@ cp_parser_alias_declaration (cp_parser* parser)
>if (parser->num_template_parameter_lists)
>  parser->type_definition_forbidden_message = saved_message;
>
> +  if (type == error_mark_node)
> +{
> +  cp_parser_skip_to_end_of_block_or_statement (parser);
> +  return error_mark_node;
> +}
> +
>cp_parser_require (parser, CPP_SEMICOLON, RT_SEMICOLON);
>
>if (cp_parser_error_occurred (parser))
> -return error_mark_node;
> +{
> +  cp_parser_skip_to_end_of_block_or_statement (parser);
> +  return error_mark_node;
> +}
>
>/* A typedef-name can also be introduced by an alias-declaration. The
>   identifier following the using keyword becomes a typedef-name. It has
> @@ -19063,9 +19078,19 @@ cp_parser_member_declaration (cp_parser* parser)
>else
> {
>   tree decl;
> + bool alias_decl_expected;
>   cp_parser_parse_tentatively (parser);
>   decl = cp_parser_alias_declaration (parser);
> - if (cp_parser_parse_definitely (parser))
> + /* Note that if we actually see the '=' token after the
> +identifier, cp_parser_alias_declaration commits the
> +tentative parse.  In that case, we really expects an
> +alias-declaration.  Otherwise, we expect a using
> +declaration.  */
> + alias_decl_expected =
> +   !cp_parser_uncommitted_to_tentative_

Re: C++ PATCH for c++/54325 (wrong error initializing abstract base class)

[Gabriel Dos Reis]

On Fri, Dec 7, 2012 at 7:39 AM, Jakub Jelinek  wrote:
> On Fri, Dec 07, 2012 at 07:34:30AM -0600, Gabriel Dos Reis wrote:
>> On Fri, Dec 7, 2012 at 3:13 AM, Matthias Klose  wrote:
>> > Am 07.12.2012 06:05, schrieb Jason Merrill:
>> >> It's perfectly OK to initialize a base class of abstract type; it's only 
>> >> an
>> >> error to create a full object of such a type.  So this patch moves the 
>> >> check
>> >> from more generic initialization code out into a function that's 
>> >> definitely
>> >> creating a new object.
>> >>
>> >> Tested x86_64-pc-linux-gnu, applying to trunk and 4.7.
>> >
>> > this doesn't build on the branch:
>> >
>> > ../gcc/cp/tree.c: In function 'build_aggr_init_expr':
>> > ../gcc/cp/tree.c:399:1: error: parameter name omitted
>> >
>> > this fixes the bootstrap, currently running the testsuite.
>> >
>> > --- cp/tree.c~  2012-12-07 10:01:16.665415647 +0100
>> > +++ cp/tree.c   2012-12-07 10:11:01.373410862 +0100
>> > @@ -396,7 +396,8 @@
>> > callable.  */
>> >
>> >  tree
>> > -build_aggr_init_expr (tree type, tree init, tsubst_flags_t /*complain*/)
>> > +build_aggr_init_expr (tree type, tree init,
>> > + tsubst_flags_t complain ATTRIBUTE_UNUSED)
>> >  {
>> >tree fn;
>> >tree slot;
>> >
>>
>> We should definitely teach the compiler to accept the former and not
>> be silly in requiring the latter when C++.
>
> Except that GCC 4.7 doesn't mandate building with C++, so the sources must
> be valid C.
>
> Jakub

Right you are!

Thanks,

-- Gaby

Re: [RFA/4.7/ARM] Backport arm-*-linux-gnueabihf triplet support to 4.7

[Matthew Gretton-Dann]

PING^2

On 29 November 2012 14:45, Matthew Gretton-Dann
 wrote:
> PING
>
> On 20 November 2012 20:34, Matthew Gretton-Dann
>  wrote:
>> All,
>>
>> This patch backports Matthais Klose's arm*-*-linux-gnueabihf triplet
>> support patch of 2012-10-15 to 4.7.
>>
>> The backport was not clean as 4.8 has obsoleted various arm*-*-*
>> triplets which are valid in 4.7.
>>
>> I have tested this cross with arm-none-linux-gnueabihf and
>> arm-none-linux-gnueabi.
>>
>> One question I do have having done this work - is there a canonical way to
>> test for the arm*-*-linux-gnueabi triplet (or variants)?  Various configure
>> and testsuite files test for this, but there doesn't seem to be a consistent
>> method.
>>
>> OK for 4.7?
>>
>> Thanks,
>>
>> Matt
>>
>> 2012-11-08  Matthew Gretton-Dann  
>>
>> Backport from mainline
>> 2012-10-15  Matthias Klose  
>>
>> * config.gcc: Match arm*-*-linux-* for ARM Linux/GNU.
>> * doc/install.texi: Use arm-*-*linux-* instead of 
>> arm-*-*linux-gnueabi.
>>
>> gcc/ada/ChangeLog:
>> 2012-11-08  Matthew Gretton-Dann  
>>
>> Backport from mainline.
>> 2012-10-15  Matthias Klose  
>>
>> * gcc-interface/Makefile.in: Match arm*-*-linux-*eabi* for
>> ARM Linux/GNU.
>>
>> gcc/testsuite/ChangeLog:
>> 2012-11-08  Matthew Gretton-Dann  
>>
>> Backport from mainline
>> 2012-10-15  Matthias Klose  
>>
>> * lib/target-supports.exp (check_profiling_available): Match
>> arm*-*-linux-* for ARM Linux/GNU.
>> * gfortran.dg/enum_10.f90: Likewise.
>> * gfortran.dg/enum_9.f90: Likewise.
>> * gcc.target/arm/synchronize.c: Likewise.
>> * g++.old-deja/g++.jason/enum6.C: Likewise.
>> * g++.old-deja/g++.law/enum9.C: Likewise.
>> * g++.old-deja/g++.other/enum4.C: Likewise.
>>
>> libgcc/ChangeLog:
>> 2012-11-08  Matthew Gretton-Dann  >
>> Backport from mainline.
>> 2012-10-15  Matthias Klose  
>>
>> * config.host: Match arm*-*-linux-* for ARM Linux/GNU.
>>
>> libjava/ChangeLog:
>> 2012-11-08  Matthew Gretton-Dann  
>>
>> Backport from mainline.
>> 2012-10-15  Matthias Klose  
>>
>> * configure.ac: Match arm*-*-linux-* for ARM Linux/GNU.
>> * configure: Regenerate.
>>
>> libstdc++-v3/ChangeLog:
>> 2012-11-08  Matthew Gretton-Dann  
>>
>> Backport from mainline
>> 2012-10-15  Matthias Klose  
>>
>> * configure.host: Match arm*-*-linux-* for ARM Linux/GNU.
>> * testsuite/20_util/make_signed/requirements/typedefs-2.cc: Likewise.
>> * testsuite/20_util/make_unsigned/requirements/typedefs-2.cc: 
>> Likewise.

--
Matthew Gretton-Dann
Linaro Toolchain Working Group
matthew.gretton-d...@linaro.org

Re: [i386] scalar ops that preserve the high part of a vector

[Marc Glisse]

On Fri, 7 Dec 2012, Michael Zolotukhin wrote:


By the way, if we decide to have one pattern for V4SF instructions and
another for V2DF, we could try to use recently introduced define_subst
here. It won't reduce number of actual patterns (I mean number of
patterns after iterators and subst expanding), but it could help to
make sse.md more compact.


Here is a version of the patch with define_subst. This helps make sse.md 
more compact indeed (well, the define_subst takes space, but it will 
already be there for mult, div, etc). One side effect is that in the 
expanded .md file, we have both variants of the V2DF operation (I switched 
the builtins to use the _vconcat version).


(not tested beyond "make dumpmd" and a quick look at that dump)

--
Marc GlisseIndex: testsuite/gcc.target/i386/pr54855-2.c
===
--- testsuite/gcc.target/i386/pr54855-2.c   (revision 0)
+++ testsuite/gcc.target/i386/pr54855-2.c   (revision 0)
@@ -0,0 +1,18 @@
+/* { dg-do compile } */
+/* { dg-options "-O -msse" } */
+
+typedef float vec __attribute__((vector_size(16)));
+
+vec f (vec x)
+{
+  x[0] += 2;
+  return x;
+}
+
+vec g (vec x)
+{
+  x[0] -= 1;
+  return x;
+}
+
+/* { dg-final { scan-assembler-not "mov" } } */

Property changes on: testsuite/gcc.target/i386/pr54855-2.c
___
Added: svn:keywords
   + Author Date Id Revision URL
Added: svn:eol-style
   + native

Index: testsuite/gcc.target/i386/pr54855-1.c
===
--- testsuite/gcc.target/i386/pr54855-1.c   (revision 0)
+++ testsuite/gcc.target/i386/pr54855-1.c   (revision 0)
@@ -0,0 +1,18 @@
+/* { dg-do compile } */
+/* { dg-options "-O -msse2" } */
+
+typedef double vec __attribute__((vector_size(16)));
+
+vec f (vec x)
+{
+  x[0] += 2;
+  return x;
+}
+
+vec g (vec x)
+{
+  x[0] -= 1;
+  return x;
+}
+
+/* { dg-final { scan-assembler-not "mov" } } */

Property changes on: testsuite/gcc.target/i386/pr54855-1.c
___
Added: svn:eol-style
   + native
Added: svn:keywords
   + Author Date Id Revision URL

Index: config/i386/i386.c
===
--- config/i386/i386.c  (revision 194301)
+++ config/i386/i386.c  (working copy)
@@ -27070,22 +27070,22 @@ static const struct builtin_description
   { OPTION_MASK_ISA_SSE, CODE_FOR_sse_cvttps2pi, "__builtin_ia32_cvttps2pi", 
IX86_BUILTIN_CVTTPS2PI, UNKNOWN, (int) V2SI_FTYPE_V4SF },
   { OPTION_MASK_ISA_SSE, CODE_FOR_sse_cvttss2si, "__builtin_ia32_cvttss2si", 
IX86_BUILTIN_CVTTSS2SI, UNKNOWN, (int) INT_FTYPE_V4SF },
   { OPTION_MASK_ISA_SSE | OPTION_MASK_ISA_64BIT, CODE_FOR_sse_cvttss2siq, 
"__builtin_ia32_cvttss2si64", IX86_BUILTIN_CVTTSS2SI64, UNKNOWN, (int) 
INT64_FTYPE_V4SF },
 
   { OPTION_MASK_ISA_SSE, CODE_FOR_sse_shufps, "__builtin_ia32_shufps", 
IX86_BUILTIN_SHUFPS, UNKNOWN, (int) V4SF_FTYPE_V4SF_V4SF_INT },
 
   { OPTION_MASK_ISA_SSE, CODE_FOR_addv4sf3, "__builtin_ia32_addps", 
IX86_BUILTIN_ADDPS, UNKNOWN, (int) V4SF_FTYPE_V4SF_V4SF },
   { OPTION_MASK_ISA_SSE, CODE_FOR_subv4sf3, "__builtin_ia32_subps", 
IX86_BUILTIN_SUBPS, UNKNOWN, (int) V4SF_FTYPE_V4SF_V4SF },
   { OPTION_MASK_ISA_SSE, CODE_FOR_mulv4sf3, "__builtin_ia32_mulps", 
IX86_BUILTIN_MULPS, UNKNOWN, (int) V4SF_FTYPE_V4SF_V4SF },
   { OPTION_MASK_ISA_SSE, CODE_FOR_sse_divv4sf3, "__builtin_ia32_divps", 
IX86_BUILTIN_DIVPS, UNKNOWN, (int) V4SF_FTYPE_V4SF_V4SF },
-  { OPTION_MASK_ISA_SSE, CODE_FOR_sse_vmaddv4sf3,  "__builtin_ia32_addss", 
IX86_BUILTIN_ADDSS, UNKNOWN, (int) V4SF_FTYPE_V4SF_V4SF },
-  { OPTION_MASK_ISA_SSE, CODE_FOR_sse_vmsubv4sf3,  "__builtin_ia32_subss", 
IX86_BUILTIN_SUBSS, UNKNOWN, (int) V4SF_FTYPE_V4SF_V4SF },
+  { OPTION_MASK_ISA_SSE, CODE_FOR_sse_vmaddv4sf3,  "__builtin_ia32_addss", 
IX86_BUILTIN_ADDSS, UNKNOWN, (int) V4SF_FTYPE_V4SF_FLOAT },
+  { OPTION_MASK_ISA_SSE, CODE_FOR_sse_vmsubv4sf3,  "__builtin_ia32_subss", 
IX86_BUILTIN_SUBSS, UNKNOWN, (int) V4SF_FTYPE_V4SF_FLOAT },
   { OPTION_MASK_ISA_SSE, CODE_FOR_sse_vmmulv4sf3,  "__builtin_ia32_mulss", 
IX86_BUILTIN_MULSS, UNKNOWN, (int) V4SF_FTYPE_V4SF_V4SF },
   { OPTION_MASK_ISA_SSE, CODE_FOR_sse_vmdivv4sf3,  "__builtin_ia32_divss", 
IX86_BUILTIN_DIVSS, UNKNOWN, (int) V4SF_FTYPE_V4SF_V4SF },
 
   { OPTION_MASK_ISA_SSE, CODE_FOR_sse_maskcmpv4sf3, "__builtin_ia32_cmpeqps", 
IX86_BUILTIN_CMPEQPS, EQ, (int) V4SF_FTYPE_V4SF_V4SF },
   { OPTION_MASK_ISA_SSE, CODE_FOR_sse_maskcmpv4sf3, "__builtin_ia32_cmpltps", 
IX86_BUILTIN_CMPLTPS, LT, (int) V4SF_FTYPE_V4SF_V4SF },
   { OPTION_MASK_ISA_SSE, CODE_FOR_sse_maskcmpv4sf3, "__builtin_ia32_cmpleps", 
IX86_BUILTIN_CMPLEPS, LE, (int) V4SF_FTYPE_V4SF_V4SF },
   { OPTION_MASK_ISA_SSE, CODE_FOR_sse_maskcmpv4sf3, "__builtin_ia32_cmpgtps", 
IX86_BUILTIN_CMPGTPS, LT, (int) V4SF_FTYPE_V4SF_V4SF_SWAP },
   { OPTION_MASK_ISA_SSE, CODE_FOR_sse_maskcmpv4sf3, "__

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

[Richard Biener]

On Fri, Dec 7, 2012 at 10:52 AM, Steven Bosscher  wrote:
> Ping?

Ok if C++ frontend maintainers don't complain over the weekend.

Thanks,
Richard.

> On Sun, Dec 2, 2012 at 9:27 PM, Steven Bosscher wrote:
>> Hello,
>>
>> The C++ front end pushes everything through the compiler queue after
>> writing a PCH. This is pointless: After the PCH is written nothing the
>> compiler does has any effect on it anymore.
>>
>> This patch makes the C++ front end stop after writing the PCH,
>> speeding up PCH creation
>>
>> The C front end has behaved this way since 2004
>> (http://gcc.gnu.org/ml/gcc-patches/2004-07/msg00738.html).
>>
>> Bootstrapped&tested on powerpc64-unknown-linux-gnu and 
>> x86_64-unknown-linux-gnu.
>> OK for trunk?
>>
>> Ciao!
>> Steven
>>
>>
>>
>> * decl2.c (cp_write_global_declarations): Return after writing a PCH.
>>
>> Index: decl2.c
>> ===
>> --- decl2.c (revision 194052)
>> +++ decl2.c (working copy)
>> @@ -3944,8 +3944,13 @@ cp_write_global_declarations (void)
>>|| !vec_safe_is_empty (decl_namespace_list))
>>  return;
>>
>> +  /* This is the point to write out a PCH if we're doing that.
>> + In that case we do not want to do anything else.  */
>>if (pch_file)
>> -c_common_write_pch ();
>> +{
>> +  c_common_write_pch ();
>> +  return;
>> +}
>>
>>cgraph_process_same_body_aliases ();
>>
>>
>>
>>
>> Compile time at -O2 (test = patched, orig = unpatched):
>> $ for i in 1 2 3 ; do time ~/devel/build-test/gcc/xg++
>> -B../devel/build-test/gcc/ -w -O2 slow.h ; done ; ls -ltr
>>
>> real0m8.577s
>> user0m8.037s
>> sys 0m0.540s
>>
>> real0m8.580s
>> user0m8.093s
>> sys 0m0.484s
>>
>> real0m8.595s
>> user0m8.093s
>> sys 0m0.500s
>> total 100440
>> -rw-r--r-- 1 stevenb stevenb  4017783 2012-12-02 21:16 slow.h
>> -rw-r--r-- 1 stevenb stevenb 98722192 2012-12-02 21:20 slow.h.gch
>> $ for i in 1 2 3 ; do time ~/devel/build-orig/gcc/xg++
>> -B../devel/build-orig/gcc/ -w -O2 slow.h ; done ; ls -ltr
>>
>> real0m10.795s
>> user0m10.273s
>> sys 0m0.520s
>>
>> real0m10.876s
>> user0m10.365s
>> sys 0m0.544s
>>
>> real0m10.767s
>> user0m10.245s
>> sys 0m0.520s
>> total 100440
>> -rw-r--r-- 1 stevenb stevenb  4017783 2012-12-02 21:16 slow.h
>> -rw-r--r-- 1 stevenb stevenb 98722192 2012-12-02 21:20 slow.h.gch

[committed] Built libbacktrace with -frandom-seed=$@ (PR bootstrap/54926)

[Jakub Jelinek]

Hi!

As discussed in the PR, bootstrap comparison doesn't like random
random-seed, causing differences in some symbols on some targets.
Fixed thusly, approved by Alex in the PR, committed to trunk.

2012-12-07  Jakub Jelinek  

PR bootstrap/54926
* Makefile.am (AM_CFLAGS): Add -frandom-seed=$@.
* Makefile.in: Regenerated.

--- libbacktrace/Makefile.am.jj 2012-10-02 15:36:21.0 +0200
+++ libbacktrace/Makefile.am2012-12-06 19:36:05.888001803 +0100
@@ -34,7 +34,7 @@ ACLOCAL_AMFLAGS = -I .. -I ../config
 AM_CPPFLAGS = -I $(top_srcdir)/../include -I $(top_srcdir)/../libgcc \
-I ../libgcc -I ../gcc/include -I $(MULTIBUILDTOP)../../gcc/include
 
-AM_CFLAGS = $(EXTRA_FLAGS) $(WARN_FLAGS) $(PIC_FLAG)
+AM_CFLAGS = $(EXTRA_FLAGS) $(WARN_FLAGS) $(PIC_FLAG) -frandom-seed=$@
 
 noinst_LTLIBRARIES = libbacktrace.la
 
--- libbacktrace/Makefile.in.jj 2012-10-02 15:36:21.0 +0200
+++ libbacktrace/Makefile.in2012-12-06 19:36:26.284875521 +0100
@@ -254,7 +254,7 @@ ACLOCAL_AMFLAGS = -I .. -I ../config
 AM_CPPFLAGS = -I $(top_srcdir)/../include -I $(top_srcdir)/../libgcc \
-I ../libgcc -I ../gcc/include -I $(MULTIBUILDTOP)../../gcc/include
 
-AM_CFLAGS = $(EXTRA_FLAGS) $(WARN_FLAGS) $(PIC_FLAG)
+AM_CFLAGS = $(EXTRA_FLAGS) $(WARN_FLAGS) $(PIC_FLAG) -frandom-seed=$@
 noinst_LTLIBRARIES = libbacktrace.la
 libbacktrace_la_SOURCES = \
backtrace.h \

Jakub

Re: [patch] PR55158 - segfault in sched-rgn.c

[Bernd Schmidt]

On 12/06/2012 01:31 PM, Steven Bosscher wrote:
> Hello,
> 
> The problem in this PR is that new basic blocks can be created if the
> scheduler moves speculative insns and adds recovery code, but the
> bb_state* arrays are allocated only at the start of scheduling a
> region and are not set up to deal with changing last_basic_block.
> 
> Fixed by resizing the arrays if necessary. This fixes most of the
> testsuite failures on ia64:

Looks OK to me. Thanks,


Bernd

Re: C++ PATCH for c++/54325 (wrong error initializing abstract base class)

[Jason Merrill]

OK.

Jason

Re: [i386] scalar ops that preserve the high part of a vector

[Richard Henderson]

On 2012-12-07 02:49, Marc Glisse wrote:
> The root problem is that we model the subs[sd] instructions as taking
> a 128-bit second operand, when Intel's documentation says they take a
> 32/64-bit operand, which is an important difference for memory
> operands (and constants). Writing a pattern that reconstructs the
> result from a scalar operation also seems more natural than
> pretending we are doing a parallel operation and dropping most of it
> (easier for recog and friends).

I agree this is a problem with the current representation.

> For 2-element vectors, vec_concat does seem more natural than
> vec_merge. If we chose vec_merge as the canonical representation, we
> should chose it for setting an element in a vector
> (ix86_expand_vector_set) everywhere, not just those scalarish
> operations.

I'd hate to enshrine vec_merge over vec_concat for the benefit of x86,
and to the detriment of e.g. mips.  There are plenty of embedded simd
implementations that are V2xx only.

If we simply pull the various x86 patterns into one common form, set
and extract included, does that buy us most of what we'd get for
playing games in combine?


As for your xmmintrin.h changes, I'd like to see a test case that verifies
that _mm_add_ss(a, b) does not add extra insns to extract __B[0].

> +(define_insn "_vm3"
>[(set (match_operand:VF_128 0 "register_operand" "=x,x")
>   (vec_merge:VF_128
> -   (plusminus:VF_128
> - (match_operand:VF_128 1 "register_operand" "0,x")
> - (match_operand:VF_128 2 "nonimmediate_operand" "xm,xm"))
> +   (vec_duplicate:VF_128
> + (plusminus:
> +   (vec_select:
> + (match_operand:VF_128 1 "register_operand" "0,x")
> + (parallel [(const_int 0)]))
> +   (match_operand: 2 "nonimmediate_operand" "xm,xm")))
> (match_dup 1)
> (const_int 1)))]
>"TARGET_SSE"
>"@
> \t{%2, %0|%0, %2}
> v\t{%2, %1, %0|%0, %1, %2}"
>[(set_attr "isa" "noavx,avx")
> (set_attr "type" "sseadd")
> (set_attr "prefix" "orig,vex")
> (set_attr "mode" "")])

Did this really trigger as a substitution?  It's not supposed to have, since
you didn't add (set_attr "replace_vec_merge_with_vec_concat" "yes")...


r~

Re: [PING] [PATCH] PR c++/54401 - Confusing diagnostics about type-alias at class scope

[Jason Merrill]

On 12/07/2012 08:42 AM, Gabriel Dos Reis wrote:

Sound good to me (except for the comment).


Me, too.

Jason

Re: [i386] scalar ops that preserve the high part of a vector

[Jakub Jelinek]

On Fri, Dec 07, 2012 at 08:43:05AM -0600, Richard Henderson wrote:
> > +(define_insn "_vm3"
> >[(set (match_operand:VF_128 0 "register_operand" "=x,x")
> > (vec_merge:VF_128
> > - (plusminus:VF_128
> > -   (match_operand:VF_128 1 "register_operand" "0,x")
> > -   (match_operand:VF_128 2 "nonimmediate_operand" "xm,xm"))
> > + (vec_duplicate:VF_128
> > +   (plusminus:
> > + (vec_select:
> > +   (match_operand:VF_128 1 "register_operand" "0,x")
> > +   (parallel [(const_int 0)]))
> > + (match_operand: 2 "nonimmediate_operand" "xm,xm")))
> >   (match_dup 1)
> >   (const_int 1)))]
> >"TARGET_SSE"
> >"@
> > \t{%2, %0|%0, %2}
> > v\t{%2, %1, %0|%0, %1, %2}"
> >[(set_attr "isa" "noavx,avx")
> > (set_attr "type" "sseadd")
> > (set_attr "prefix" "orig,vex")
> > (set_attr "mode" "")])
> 
> Did this really trigger as a substitution?  It's not supposed to have, since
> you didn't add (set_attr "replace_vec_merge_with_vec_concat" "yes")...

That was the older proposal, the current way to trigger it is using
the substitution attr somewhere, typically in pattern name
-  in the above case.

Jakub

Re: [i386] scalar ops that preserve the high part of a vector

[Richard Henderson]

On 2012-12-07 08:47, Jakub Jelinek wrote:
> That was the older proposal, the current way to trigger it is using
> the substitution attr somewhere, typically in pattern name
> -  in the above case.

Ah right.

("My mind is going, Dave.  I can feel it.")


r~

Re: [i386] scalar ops that preserve the high part of a vector

[Marc Glisse]

On Fri, 7 Dec 2012, Richard Henderson wrote:


On 2012-12-07 02:49, Marc Glisse wrote:

For 2-element vectors, vec_concat does seem more natural than
vec_merge. If we chose vec_merge as the canonical representation, we
should chose it for setting an element in a vector
(ix86_expand_vector_set) everywhere, not just those scalarish
operations.


I'd hate to enshrine vec_merge over vec_concat for the benefit of x86,
and to the detriment of e.g. mips.  There are plenty of embedded simd
implementations that are V2xx only.

If we simply pull the various x86 patterns into one common form, set
and extract included, does that buy us most of what we'd get for
playing games in combine?


I'm sorry, could you be more precise? I don't see clearly what you are 
suggesting.



As for your xmmintrin.h changes, I'd like to see a test case that verifies
that _mm_add_ss(a, b) does not add extra insns to extract __B[0].


Yes, good idea, thanks.

--
Marc Glisse

Re: [i386] scalar ops that preserve the high part of a vector

[Richard Henderson]

On 2012-12-07 09:00, Marc Glisse wrote:
> On Fri, 7 Dec 2012, Richard Henderson wrote:
> 
>> On 2012-12-07 02:49, Marc Glisse wrote:
>>> For 2-element vectors, vec_concat does seem more natural than
>>> vec_merge. If we chose vec_merge as the canonical representation, we
>>> should chose it for setting an element in a vector
>>> (ix86_expand_vector_set) everywhere, not just those scalarish
>>> operations.
>>
>> I'd hate to enshrine vec_merge over vec_concat for the benefit of x86,
>> and to the detriment of e.g. mips.  There are plenty of embedded simd
>> implementations that are V2xx only.
>>
>> If we simply pull the various x86 patterns into one common form, set
>> and extract included, does that buy us most of what we'd get for
>> playing games in combine?
> 
> I'm sorry, could you be more precise? I don't see clearly what you are 
> suggesting.

Don't change combine?

Have I lost the plot somewhere here?


r~

Re: [i386] scalar ops that preserve the high part of a vector

[Marc Glisse]

On Fri, 7 Dec 2012, Richard Henderson wrote:


On 2012-12-07 09:00, Marc Glisse wrote:

On Fri, 7 Dec 2012, Richard Henderson wrote:


On 2012-12-07 02:49, Marc Glisse wrote:

For 2-element vectors, vec_concat does seem more natural than
vec_merge. If we chose vec_merge as the canonical representation, we
should chose it for setting an element in a vector
(ix86_expand_vector_set) everywhere, not just those scalarish
operations.


I'd hate to enshrine vec_merge over vec_concat for the benefit of x86,
and to the detriment of e.g. mips.  There are plenty of embedded simd
implementations that are V2xx only.

If we simply pull the various x86 patterns into one common form, set
and extract included, does that buy us most of what we'd get for
playing games in combine?


I'm sorry, could you be more precise? I don't see clearly what you are 
suggesting.


Don't change combine?


but change ix86_expand_vector_set and others to generate vec_merge and 
have only the vec_merge define_insn in sse.md? I guess it would buy a 
large part of it. That's a pretty invasive change, I'll have to try...


--
Marc Glisse

Re: [PATCH] validate_failures.py: Fix performance regression

[Diego Novillo]

On Thu, Dec 6, 2012 at 1:12 PM, Bernhard Reutner-Fischer
 wrote:

>  def IsComment(line):
>"""Return True if line is a comment."""
> -  return line.startswith('#')
> +  return bool(re.matches("#", line))

startswith() is a better match here.

>  def IsInclude(line):
>"""Return True if line is an include of another file."""
> -  return line.startswith("@include ")
> +  return bool(re.matches("@include ", line))

Likewise.

>  def IsNegativeResult(line):
>"""Return True if line should be removed from the expected results."""
> -  return line.startswith("@remove ")
> +  return bool(re.matches("@remove ", line))

Likewise.


OK with those changes.


Diego.

[PATCH] Fix regression caused by my var-tracking.c note fix (PR bootstrap/55615, PR middle-end/43631)

[Jakub Jelinek]

Hi!

The barriers pass wants to put a BARRIER from after a noreturn call in
between the call and NOTE_INSN_CALL_ARG_LOCATION, but as the note no longer
is BB_END (the call is), it happens to extend BB_END to the BARRIER which
later breaks the md reorg pass.

dwarf2out.c seems to handle a BARRIER in between the call and related
NOTE_INSN_CALL_ARG_LOCATION resp. NOTE_INSN_VAR_LOCATION/c just fine,
only NOTE_INSN_CALL_ARG_LOCATION needs to go first.

My first fix was to the barriers pass to allow NOTE_INSN_CALL_ARG_LOCATION
in between the CALL_INSN and BARRIER, but I think I prefer to put the
BARRIER first from the beginning.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?

2012-12-07  Jakub Jelinek  

PR middle-end/43631
PR bootstrap/55615
* var-tracking.c (emit_note_insn_var_location): If insn is followed
by BARRIER, put note after the BARRIER.
(next_non_note_insn_var_location): Skip over BARRIERs.
(emit_notes_in_bb): If call is followed by BARRIER, put note after
the BARRIER.

* g++.dg/other/pr43631.C: New test.

--- gcc/var-tracking.c.jj   2012-12-06 15:37:30.0 +0100
+++ gcc/var-tracking.c  2012-12-07 13:00:32.713116052 +0100
@@ -8538,7 +8538,10 @@ emit_note_insn_var_location (void **varp
 
   if (where != EMIT_NOTE_BEFORE_INSN)
 {
-  note = emit_note_after (NOTE_INSN_VAR_LOCATION, insn);
+  rtx after = insn;
+  while (NEXT_INSN (after) && BARRIER_P (NEXT_INSN (after)))
+   after = NEXT_INSN (after);
+  note = emit_note_after (NOTE_INSN_VAR_LOCATION, after);
   if (where == EMIT_NOTE_AFTER_CALL_INSN)
NOTE_DURING_CALL_P (note) = true;
 }
@@ -8892,9 +8895,11 @@ next_non_note_insn_var_location (rtx ins
   while (insn)
 {
   insn = NEXT_INSN (insn);
-  if (insn == 0
- || !NOTE_P (insn)
- || NOTE_KIND (insn) != NOTE_INSN_VAR_LOCATION)
+  if (insn == 0)
+   break;
+  if (BARRIER_P (insn))
+   continue;
+  if (!NOTE_P (insn) || NOTE_KIND (insn) != NOTE_INSN_VAR_LOCATION)
break;
 }
 
@@ -8923,7 +8928,7 @@ emit_notes_in_bb (basic_block bb, datafl
dataflow_set_clear_at_call (set);
emit_notes_for_changes (insn, EMIT_NOTE_AFTER_CALL_INSN, set->vars);
{
- rtx arguments = mo->u.loc, *p = &arguments, note;
+ rtx arguments = mo->u.loc, *p = &arguments, note, after;
  while (*p)
{
  XEXP (XEXP (*p, 0), 1)
@@ -8947,7 +8952,10 @@ emit_notes_in_bb (basic_block bb, datafl
  else
*p = XEXP (*p, 1);
}
- note = emit_note_after (NOTE_INSN_CALL_ARG_LOCATION, insn);
+ after = insn;
+ while (NEXT_INSN (after) && BARRIER_P (NEXT_INSN (after)))
+   after = NEXT_INSN (after);
+ note = emit_note_after (NOTE_INSN_CALL_ARG_LOCATION, after);
  NOTE_VAR_LOCATION (note) = arguments;
  /* If insn is BB_END of some bb, make sure the note
 doesn't have BLOCK_FOR_INSN set.  The notes don't
--- gcc/testsuite/g++.dg/other/pr43631.C.jj 2012-12-07 12:12:35.557226106 
+0100
+++ gcc/testsuite/g++.dg/other/pr43631.C2012-12-07 12:13:48.17083 
+0100
@@ -0,0 +1,15 @@
+// PR middle-end/43631
+// { dg-do compile }
+// { dg-options "-g -O2" }
+// { dg-additional-options "-mtune=atom" { target i?86-*-* x86_64-*-* } }
+
+typedef void (*T) ();
+struct S { T t; };
+void bar (T) __attribute__ ((__noreturn__));
+S *p;
+
+void
+foo ()
+{
+  try { bar (p->t); } catch (...) { throw 1; }
+}

Jakub

Re: [PATCH] Don't drop DECL_INITIAL if -g for DWARF2+ (PR fortran/55395)

[Jakub Jelinek]

On Fri, Dec 07, 2012 at 12:36:58PM +0100, Richard Biener wrote:
> Hmm.  Then make it DINFO_LEVEL_NONE and put in a fixme comment refering
> to the bugreport.

Here is what I've committed after another bootstrap/regtest:

2012-12-07  Jakub Jelinek  

PR fortran/55395
* varpool.c (varpool_remove_node): Don't drop DECL_INITIAL
for -g for any kind of debug info.

--- gcc/varpool.c.jj2012-12-06 21:34:16.0 +0100
+++ gcc/varpool.c   2012-12-07 13:25:42.005710625 +0100
@@ -63,12 +63,8 @@ varpool_remove_node (struct varpool_node
   && !DECL_IN_CONSTANT_POOL (node->symbol.decl)
   /* Keep vtables for BINFO folding.  */
   && !DECL_VIRTUAL_P (node->symbol.decl)
-  /* dbxout output constant initializers for readonly vars.  */
-  && (!host_integerp (DECL_INITIAL (node->symbol.decl), 0)
- || !TREE_READONLY (node->symbol.decl))
-  /* dwarf2out can use most of the initializers.  */
-  && write_symbols != DWARF2_DEBUG
-  && write_symbols != VMS_AND_DWARF2_DEBUG)
+  /* FIXME: http://gcc.gnu.org/PR55395 */
+  && debug_info_level == DINFO_LEVEL_NONE)
 DECL_INITIAL (node->symbol.decl) = error_mark_node;
   ggc_free (node);
 }

Jakub

Re: [i386] scalar ops that preserve the high part of a vector

[Richard Henderson]

On 2012-12-07 09:12, Marc Glisse wrote:
> but change ix86_expand_vector_set and others to generate vec_merge
> and have only the vec_merge define_insn in sse.md? I guess it would
> buy a large part of it. That's a pretty invasive change, I'll have to
> try...

Is it really that invasive?  Anyway, it's something worth trying for 4.9...


r~

Re: [PING] [PATCH] PR c++/54401 - Confusing diagnostics about type-alias at class scope

[Dodji Seketeli]

Gabriel Dos Reis  writes:

> On Fri, Dec 7, 2012 at 7:33 AM, Dodji Seketeli  wrote:

>> diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
>> index a010f1f..c39ef30 100644
>> --- a/gcc/cp/parser.c
>> +++ b/gcc/cp/parser.c
>> @@ -15262,7 +15262,11 @@ cp_parser_using_declaration (cp_parser* parser,
>>  /* Parse an alias-declaration.
>>
>> alias-declaration:
>> - using identifier attribute-specifier-seq [opt] = type-id  */
>> + using identifier attribute-specifier-seq [opt] = type-id
>> +
>> +   Note that if this function is used in the context of a tentative
>> +   parse, it commits the currently active tentative parse after it
>> +   sees the '=' token.  */
>
> This comment is repeated below; I don't think it is necessary
> or should be part of the specification.  In general we don't (and shouldn't)
> say this unless a parsing function deviates from the general
> parsing strategy -- this one doesn't.

Fair enough.  I have removed this comment then.  Thanks.

> Sound good to me (except for the comment).

Thanks!

Here is what I am committing to trunk.

gcc/cp/

* parser.c (cp_parser_alias_declaration): Commit to tentative
parse when see the '=' token.  Get out if the type-id is invalid.
Update function comment.
(cp_parser_member_declaration): Don't try to parse a using
declaration if we know that we expected an alias declaration; that
is, if we see the '=' token after the identifier.

gcc/testsuite/

* g++.dg/cpp0x/alias-decl-28.C: New test.
* g++.dg/cpp0x/alias-decl-16.C: Update.
---
 gcc/cp/ChangeLog   | 10 ++
 gcc/cp/parser.c| 25 +++--
 gcc/testsuite/ChangeLog|  6 ++
 gcc/testsuite/g++.dg/cpp0x/alias-decl-16.C |  2 +-
 gcc/testsuite/g++.dg/cpp0x/alias-decl-28.C |  7 +++
 5 files changed, 47 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/alias-decl-28.C

diff --git a/gcc/cp/ChangeLog b/gcc/cp/ChangeLog
index 7bec9ca..81c2048 100644
--- a/gcc/cp/ChangeLog
+++ b/gcc/cp/ChangeLog
@@ -1,3 +1,13 @@
+2012-12-07  Dodji Seketeli  
+
+   PR c++/54401
+   * parser.c (cp_parser_alias_declaration): Commit to tentative
+   parse when see the '=' token.  Get out if the type-id is invalid.
+   Update function comment.
+   (cp_parser_member_declaration): Don't try to parse a using
+   declaration if we know that we expected an alias declaration; that
+   is, if we see the '=' token after the identifier.
+
 2012-12-06  Jason Merrill  
 
PR c++/54325
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 3566d74..3dc2ec6 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -15295,6 +15295,8 @@ cp_parser_alias_declaration (cp_parser* parser)
   if (cp_parser_error_occurred (parser))
 return error_mark_node;
 
+  cp_parser_commit_to_tentative_parse (parser);
+
   /* Now we are going to parse the type-id of the declaration.  */
 
   /*
@@ -15324,10 +15326,19 @@ cp_parser_alias_declaration (cp_parser* parser)
   if (parser->num_template_parameter_lists)
 parser->type_definition_forbidden_message = saved_message;
 
+  if (type == error_mark_node)
+{
+  cp_parser_skip_to_end_of_block_or_statement (parser);
+  return error_mark_node;
+}
+
   cp_parser_require (parser, CPP_SEMICOLON, RT_SEMICOLON);
 
   if (cp_parser_error_occurred (parser))
-return error_mark_node;
+{
+  cp_parser_skip_to_end_of_block_or_statement (parser);
+  return error_mark_node;
+}
 
   /* A typedef-name can also be introduced by an alias-declaration. The
  identifier following the using keyword becomes a typedef-name. It has
@@ -19063,9 +19074,19 @@ cp_parser_member_declaration (cp_parser* parser)
   else
{
  tree decl;
+ bool alias_decl_expected;
  cp_parser_parse_tentatively (parser);
  decl = cp_parser_alias_declaration (parser);
- if (cp_parser_parse_definitely (parser))
+ /* Note that if we actually see the '=' token after the
+identifier, cp_parser_alias_declaration commits the
+tentative parse.  In that case, we really expects an
+alias-declaration.  Otherwise, we expect a using
+declaration.  */
+ alias_decl_expected =
+   !cp_parser_uncommitted_to_tentative_parse_p (parser);
+ cp_parser_parse_definitely (parser);
+
+ if (alias_decl_expected)
finish_member_declaration (decl);
  else
cp_parser_using_declaration (parser,
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index d50d73b..1fd69fa 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,9 @@
+2012-12-07  Dodji Seketeli  
+
+   PR c++/54401
+   * g++.dg/cpp0x/alias-decl-28.C: New test.
+   * g++.dg/cpp0x/alias-decl-16.C: Update.
+
 2012-12-07  Martin Jambor  
 
PR tree-optimization/

Re: [PATCH, rs6000] Update default loop peel limits

[Jan Hubicka]

> On Thu, Dec 6, 2012 at 10:43 PM, Jan Hubicka  wrote:
> >> The following patch restores the old default limits for loop peeling
> >> that were recently changed to 100 and caused a 20% degradation in
> >> 454.calculix.
> >>
> >> Bootstrap/regtest on powerpc64-linux with no new regressions. Ok for trunk?
> >>
> >> -Pat
> >>
> >>
> >> 2012-12-06  Pat Haugen 
> >> * config/rs6000/rs6000.c (rs6000_option_override_internal): Set
> >> default loop peeling limits.
> >
> > Actually the calculix regression is also seen on core.
> > Igor was looking into what loops got slower and why. Either we can fix that 
> > partiuclar
> > loop or revert to the old default (that sadly causes quite a lot of code 
> > bloat)
> 
> Well, as the patch regressed the testcase in put in the testsuite for calculix
> that is no surprise... gfortran.dg/reassoc_4.f.  The fix for the testcase was 
> to
> increase the limit with a --param :/

I would not care too much about limits for gfortran.dg/reassoc_4.f, it is an 
artificail
testcase.
> 
> Note that it is even beneficial to unroll two more levels of the nest
> completely.
> It's just an insane testcase (and I spent quite some time on it trying to
> somehow autodetect the simplification opportunities - see the unrolling
> heuristic rewrite patch I dumped on you a few weeks ago).
> 
> No advice from me on how to "fix" this ... but eventually the rewrite restores
> the old behavior with the new limits (I did the rewrite to try to somehow make
> it do two extra levels of nest unrolling ...).

Yep, calculix is kind of special case.  I also tested increasing the limits to 
more
than 10 fold improves ammp and applu (I filled in enhancement PR to track that).

I am not sure how to deal with calculix - I am OK with reverting to the old 
limit even
if it doesn't fare best with firefox (whose code size growth was main 
motivation for
tamning the heuristics down). In meantime inlining improved so except for FDO 
the firefox
is still smaller with 4.8 compres to 4.7 in my setup.

I am also OK with declaring calculix a special case and living with the 
regression,
same way as we do not try to handle ammp/applu.

Honza
> 
> Richard.
> 
> > Honza

Re: [PATCH, rs6000] Update default loop peel limits

[Michael Matz]

Hi,

On Fri, 7 Dec 2012, Jan Hubicka wrote:

> > > Actually the calculix regression is also seen on core.
> > > Igor was looking into what loops got slower and why. Either we can fix 
> > > that partiuclar
> > > loop or revert to the old default (that sadly causes quite a lot of code 
> > > bloat)
> > 
> > Well, as the patch regressed the testcase in put in the testsuite for 
> > calculix
> > that is no surprise... gfortran.dg/reassoc_4.f.  The fix for the testcase 
> > was to
> > increase the limit with a --param :/
> 
> I would not care too much about limits for gfortran.dg/reassoc_4.f, it 
> is an artificail testcase.

Ehm, no it's not.  It _specifically_ is the important inner loop nest of 
calculix and it should be compiled to exactly the expected form (i.e. 22 
multiplications and unrolled) without any changes to params.  At least 
when you expect that -Ofast is giving good results on 454.calculix.

I.e. this testcase breaking automatically implies slower calculix results.


Ciao,
Michael.

Re: [i386] scalar ops that preserve the high part of a vector

[Marc Glisse]

On Fri, 7 Dec 2012, Richard Henderson wrote:


On 2012-12-07 09:12, Marc Glisse wrote:

but change ix86_expand_vector_set and others to generate vec_merge
and have only the vec_merge define_insn in sse.md? I guess it would
buy a large part of it. That's a pretty invasive change, I'll have to
try...


Is it really that invasive?


No, changing only V2DF, I seem to have the basic pieces in place changing 
just 6 patterns in sse.md and a couple functions in i386.c. Now I need to 
test it and see how much it affects the generated code...



Anyway, it's something worth trying for 4.9...


Should I take it that if it ends up looking manageable, you prefer 
changing all the V2DF operations to vec_merge, rather than just adapting 
the addsd pattern? Won't it complicate things for generic optimizations if 
different platforms have different canonical patterns for the same 
operation on V2DF? It seems to me that it would be good if we agreed on a 
pattern common to all platforms so we could canonicalize as in the last 
part of:

http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00243.html
(or possibly the reverse transformation depending on the pattern we settle 
on).


(those 2 patches didn't touch the generic simplify-rtx code either, if I 
remember just the "don't touch combine" part of your suggestion ;-)

http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00028.html
http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00492.html )

--
Marc Glisse

PS: I'll ping you about this other patch when trunk re-opens for 4.9, if 
you don't mind:

http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00079.html

Re: [RFA] .gitignore: Ignore *.pyc files.

[Mike Stump]

On Dec 7, 2012, at 1:36 AM, Joel Brobecker  wrote:
> The GDB sources contain some python files, and executing them
> causes these .pyc files to appear.  We could ignore them in GDB
> only, but I think this is the type of extension (compilation
> artifact) which can be shared amoung all projects.

This happened to us in a gcc port, so, we'd like this…  Don't know if anyone 
else cares enough to say ok however.  I might ask objections?

PR c++/55513: do not fold away builtins in COMPOUND_EXPRs

[Aldy Hernandez]

The problem here is that we fold away calls to built-ins in 
COMPOUND_EXPRs such as:


const int t = (__builtin_memcpy (s, "Hello", 6), 777);

Since we return true for any built-in in 
potential_constant_expression_1, this means that 
check_initializer->store_init_value->maybe_constant_init will chop off 
the built-in side of a COMPOUND_EXPR when setting a DECL_INITIAL, 
transforming:


(COMPOUND_EXPR (CALL_EXPR built-in) INTEGER_CST)

into

INTEGER_CST

Fixed by setting `non_constant_p' if folding a built-in does not yield a 
constant.


Tested on x86-64 Linux.

OK for trunk?
commit 9775b837cf9ece71cbf9560c35c638b3f8c0a778
Author: Aldy Hernandez 
Date:   Fri Dec 7 10:40:25 2012 -0600

PR c++/55513
* semantics.c (cxx_eval_builtin_function_call): Set non_constant_p
after folding.

diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 491d97c..f487a61 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -6437,7 +6437,10 @@ cxx_eval_builtin_function_call (const constexpr_call 
*call, tree t,
 return t;
   new_call = build_call_array_loc (EXPR_LOCATION (t), TREE_TYPE (t),
CALL_EXPR_FN (t), nargs, args);
-  return fold (new_call);
+  new_call = fold (new_call);
+  if (!TREE_CONSTANT (new_call))
+*non_constant_p = true;
+  return new_call;
 }
 
 /* TEMP is the constant value of a temporary object of type TYPE.  Adjust
diff --git a/gcc/testsuite/g++.dg/pr55513.C b/gcc/testsuite/g++.dg/pr55513.C
new file mode 100644
index 000..06eedee
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pr55513.C
@@ -0,0 +1,12 @@
+// { dg-do compile }
+// { dg-options "-O0 -fdump-tree-gimple" }
+
+main ()
+{
+  char s[10];
+  const int t = (__builtin_memcpy (s, "Hello", 6), 777);
+  __builtin_printf ("%d %s\n", t, s);
+}
+
+// { dg-final { scan-tree-dump-times "memcpy" 1 "gimple" } }
+// { dg-final { cleanup-tree-dump "gimple" } }

Ada: ^M in ada source files

[Mike Stump]

I've noticed that:

$ grep -l '^M' gcc/testsuite/gnat.dg/*
discr36.ads
discr36_pkg.adb
discr36_pkg.ads
discr38.adb
loop_optimization11.adb
loop_optimization11_pkg.ads
loop_optimization13.adb
loop_optimization13.ads

:-(  Surely these are just normal text files, right?  Can I strip the ^M from 
them?

Re: Ada: ^M in ada source files

[Robert Dewar]

On 12/7/2012 1:56 PM, Mike Stump wrote:

I've noticed that:

$ grep -l '^M' gcc/testsuite/gnat.dg/*
discr36.ads
discr36_pkg.adb
discr36_pkg.ads
discr38.adb
loop_optimization11.adb
loop_optimization11_pkg.ads
loop_optimization13.adb
loop_optimization13.ads

:-(  Surely these are just normal text files, right?  Can I strip the ^M from 
them?



Probably good to have some tests with standard CR/LF terminators, since 
this is what a lot of the world uses.

Re: Ada: ^M in ada source files

[Arnaud Charlet]

> I've noticed that:
> 
> $ grep -l '^M' gcc/testsuite/gnat.dg/*
> discr36.ads
> discr36_pkg.adb
> discr36_pkg.ads
> discr38.adb
> loop_optimization11.adb
> loop_optimization11_pkg.ads
> loop_optimization13.adb
> loop_optimization13.ads
> 
> :-(  Surely these are just normal text files, right?  Can I strip the ^M from
> them?

Yes, you can strip them, no problem.

Arno

libgo: ^M in source files

[Mike Stump]

So I found some ^Ms in libgo.

$ grep -l '^M' libgo/go/mime/multipart/testdata/nested-mime
libgo/go/mime/multipart/testdata/nested-mime

This file is likely meant to contain them if I don't miss my guess.  The 
problem is, it is not tagged as a binary file in svn and git, leading to 
inconsistent contents depending upon how it is pulled.  Could you either tag as 
binary in svn/git or strip the the ^Ms, thanks.

Re: Ada: ^M in ada source files

[Mike Stump]

On Dec 7, 2012, at 10:57 AM, Robert Dewar  wrote:
> On 12/7/2012 1:56 PM, Mike Stump wrote:
>> I've noticed that:
>> 
>> $ grep -l '^M' gcc/testsuite/gnat.dg/*
>> discr36.ads
>> discr36_pkg.adb
>> discr36_pkg.ads
>> discr38.adb
>> loop_optimization11.adb
>> loop_optimization11_pkg.ads
>> loop_optimization13.adb
>> loop_optimization13.ads
>> 
>> :-(  Surely these are just normal text files, right?  Can I strip the ^M 
>> from them?
>> 
> 
> Probably good to have some tests with standard CR/LF terminators, since this 
> is what a lot of the world uses.

Then, to preserve them, the files must be tagged as binary in svn and git.  
Doing so will probably make the normal file merging that git/svn would do, 
inoperative.

Ok to so tag all the files?

Re: Ada: ^M in ada source files

[Mike Stump]

On Dec 7, 2012, at 10:59 AM, Arnaud Charlet  wrote:
>> I've noticed that:
>> 
>> $ grep -l '^M' gcc/testsuite/gnat.dg/*
>> discr36.ads
>> discr36_pkg.adb
>> discr36_pkg.ads
>> discr38.adb
>> loop_optimization11.adb
>> loop_optimization11_pkg.ads
>> loop_optimization13.adb
>> loop_optimization13.ads
>> 
>> :-(  Surely these are just normal text files, right?  Can I strip the ^M from
>> them?
> 
> Yes, you can strip them, no problem.

Since emails likely crossed paths….  I'm going to give you and Robert a change 
to figure out what you'd like to do…  I _only_ care about consistency between 
contents as seen from svn and git.  Stripping ^M can do this, as can marking 
them as binary.  So marking them, ensures that the ^Ms are always there, both 
on ^M systems and non-^M systems.

So, after hashing it how, let me know the final verdict.  Thanks.

Re: [PATCH] Improve debug info for various cases where we drop location info on the floor (PR debug/55608)

[Cary Coutant]

> This patch adds DW_AT_const_value or DW_AT_location for unused static vars
> (thus, not really modified and their DECL_INITIAL can be used for
> location/constant value info), and optimizes various cases using
> DW_OP_GNU_implicit_pointer (e.g. DW_OP_addr  DW_OP_stack_value
> where symbol is either an optimized away static var (but with DW_AT_location
> or DW_AT_const_value on it's DIE), which would be otherwise dropped
> to avoid referencing non-existent symbol, can be replaced with
> DW_OP_GNU_implicit_pointer to that DIE.  Or, if symbol above is a constant 
> string
> literal, we can create DW_TAG_dwarf_procedure with DW_AT_location
> DW_OP_implicit_value (and, surprisingly, GDB handles that out of the box).
>
> In cc1plus .debug_loc grew with this by about 3% and .debug_info grew by
> 0.25%, in libstdc++ the changes were in the noise.

Based on my reading of PR 55608, this isn't really a regression, and
it's definitely not a regression from 4.7 to 4.8. While the patch
looks OK to me, the size increase in .debug_loc and the scope of the
change suggest that this would be more appropriate for when Stage 1
reopens.

-cary

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

[Richard Henderson]

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~

Re: Ada: ^M in ada source files

[Robert Dewar]

On 12/7/2012 2:09 PM, Mike Stump wrote:

On Dec 7, 2012, at 10:57 AM, Robert Dewar  wrote:

On 12/7/2012 1:56 PM, Mike Stump wrote:

I've noticed that:

$ grep -l '^M' gcc/testsuite/gnat.dg/*
discr36.ads
discr36_pkg.adb
discr36_pkg.ads
discr38.adb
loop_optimization11.adb
loop_optimization11_pkg.ads
loop_optimization13.adb
loop_optimization13.ads

:-(  Surely these are just normal text files, right?  Can I strip the ^M from 
them?



Probably good to have some tests with standard CR/LF terminators, since this is 
what a lot of the world uses.


Then, to preserve them, the files must be tagged as binary in svn and git.  
Doing so will probably make the normal file merging that git/svn would do, 
inoperative.

Ok to so tag all the files?


probably not worth it if it causes that disruption. svn certainly 
handleds CR/LF terminators fine, I guess Git does not?

[PATCH] Fix up convert_for_assignment warnings (PR c/39464)

[Jakub Jelinek]

Hi!

As the testcase shows, for implicit conversions between signed integer
and signed integer with some attribute that makes it a distinct type from
that such as may_alias attribute, we warn that the pointer targets differ
in signedness, even when they have the same size.  For similar unsigned
integer vs. unsigned integer with attribute we warn about initialization
from incompatible pointer type.  This patch ensures we treat the former
as the latter.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2012-12-07  Jakub Jelinek  

PR c/39464
* c-typeck.c (convert_for_assignment): For -Wpointer-sign
warning require that both c_common_unsigned_type as well as
c_common_signed_type is the same for both mvl and mvr types.

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

--- gcc/c/c-typeck.c.jj 2012-12-07 17:08:05.391996135 +0100
+++ gcc/c/c-typeck.c2012-12-07 17:31:11.831147409 +0100
@@ -5543,8 +5543,10 @@ convert_for_assignment (location_t locat
   if (VOID_TYPE_P (ttl) || VOID_TYPE_P (ttr)
  || (target_cmp = comp_target_types (location, type, rhstype))
  || is_opaque_pointer
- || (c_common_unsigned_type (mvl)
- == c_common_unsigned_type (mvr)))
+ || ((c_common_unsigned_type (mvl)
+  == c_common_unsigned_type (mvr))
+ && c_common_signed_type (mvl)
+== c_common_signed_type (mvr)))
{
  if (pedantic
  && ((VOID_TYPE_P (ttl) && TREE_CODE (ttr) == FUNCTION_TYPE)
--- gcc/testsuite/gcc.dg/pr39464.c.jj   2012-12-07 17:19:33.885125923 +0100
+++ gcc/testsuite/gcc.dg/pr39464.c  2012-12-07 17:33:14.0 +0100
@@ -0,0 +1,19 @@
+/* PR c/39464 */
+/* { dg-do compile } */
+/* { dg-options "-Wall" } */
+
+typedef int T __attribute__((may_alias));
+typedef unsigned int U __attribute__((may_alias));
+
+void
+foo (void *p)
+{
+  T *a = (int *) p;/* { dg-warning "initialization from 
incompatible pointer type" } */
+  int *b = (T *) p;/* { dg-warning "initialization from 
incompatible pointer type" } */
+  U *c = (unsigned int *) p;   /* { dg-warning "initialization from 
incompatible pointer type" } */
+  unsigned int *d = (U *) p;   /* { dg-warning "initialization from 
incompatible pointer type" } */
+  (void) a;
+  (void) b;
+  (void) c;
+  (void) d;
+}

Jakub

Re: Ada: ^M in ada source files

[Robert Dewar]

On 12/7/2012 2:16 PM, Mike Stump wrote:


Yes, you can strip them, no problem.


Since emails likely crossed paths….  I'm going to give you and Robert a change 
to figure out what you'd like to do…  I _only_ care about consistency between 
contents as seen from svn and git.  Stripping ^M can do this, as can marking 
them as binary.  So marking them, ensures that the ^Ms are always there, both 
on ^M systems and non-^M systems.

So, after hashing it how, let me know the final verdict.  Thanks.


I would strip the CR's, not a big deal, and not worth worrying about.

Re: Ada: ^M in ada source files

[Marc Glisse]

On Fri, 7 Dec 2012, Mike Stump wrote:


On Dec 7, 2012, at 10:57 AM, Robert Dewar  wrote:

Probably good to have some tests with standard CR/LF terminators, since this is 
what a lot of the world uses.


Then, to preserve them, the files must be tagged as binary in svn and 
git.


Assuming they consistently use CRLF (I didn't look), wouldn't marking them 
with svn:eol-style=CRLF be less problematic?


--
Marc Glisse

Re: Ada: ^M in ada source files

[Arnaud Charlet]

> >>Probably good to have some tests with standard CR/LF terminators, since
> >>this is what a lot of the world uses.
> >
> >Then, to preserve them, the files must be tagged as binary in svn and git. 
> >Doing so will probably make the normal file merging that git/svn would do,
> >inoperative.
> >
> >Ok to so tag all the files?
> 
> probably not worth it if it causes that disruption. svn certainly

It's not very important either way IMO.

I think there is little point in having CRLF in those tests (which
are testing other capabilities/bugs), except possibly for a single test
(and even then, it seems very unlikely that a problem would occur there).

Anyway, I'll let Robert have the final word on this one.

I'm fine with either solution (converting to LF, or marking files binary,
or a mix of both).

Arno

Re: Minimize downward code motion during reassociation

[Easwaran Raman]

It seems I need to reset the debug uses of a statement before moving
the statement itself. The attached patch starts from the leaf to root
of the tree to be reassociated and places them at the point where
their dependences will be met after reassociation. This bootstraps and
I am running the tests. Ok if there are no test failures?

Thanks,
Easwaran

2012-12-07   Easwaran Raman  
* tree-ssa-reassoc.c(find_insert_point): New function.
(insert_stmt_after): Likewise.
(get_def_stmt): Likewise.
(ensure_ops_are_available): Likewise.
(rewrite_expr_tree): Do not move statements beyond what is
necessary. Remove call to swap_ops_for_binary_stmt...
(reassociate_bb): ... and move it here.
(build_and_add_sum): Assign UIDs for new statements.
(linearize_expr): Likewise.
(do_reassoc): Renumber gimple statement UIDs.



On Thu, Dec 6, 2012 at 1:10 AM, Richard Biener
 wrote:
> On Tue, Nov 6, 2012 at 1:54 AM, Easwaran Raman  wrote:
>> I am unable to figure out the right way to handle the debug
>> statements. What I tried was to find debug statements that use the SSA
>> name defined by the statement I moved (using SSA_NAME_IMM_USE_NODE)
>> and then moved them as well at the right place. Thus, if I have to
>> move t1 = a + b down (after the definition of 'd'), I also moved all
>> debug statements that use t1 after the new position of t1. That still
>> caused use-before-def problems in ssa_verify. I noticed that the debug
>> statements got modified behind the scenes causing these issues. Any
>> hints on what is the right way to handle the debug statements would be
>> very helpful.
>
> I think you cannot (and should not) move debug statements.  Instead you
> have to invalidate them.  Otherwise you'll introduce confusion as debug
> info cannot handle overlapping live ranges.
>
> But maybe Alex can clarify.
>
> Richard.


reassoc_revised.diff
Description: Binary data

Re: PR rtl-optimization/51771: revert TM returns twice kludge

[Richard Henderson]

On 2012-12-05 15:06, Aldy Hernandez wrote:
>   PR rtl-optimization/51771
>   Revert:
>   * builtin-attrs.def (ATTR_RETURNS_TWICE, ATTR_TM_NOTHROW_RT_LIST): New.
>   * gtm-builtins.def (BUILT_IN_TM_START): Add returns-twice attrib.

Are we absolutely sure that the rtl edges are fixed?
Fixing only the gimple level edges doesn't really help the regsister allocator.


r~

Re: [PING] [PATCH] PR c++/54401 - Confusing diagnostics about type-alias at class scope

[Gabriel Dos Reis]

On Fri, Dec 7, 2012 at 10:06 AM, Dodji Seketeli  wrote:

> Here is what I am committing to trunk.

Thank you!

-- Gaby

Re: Ada: ^M in ada source files

[Robert Dewar]

On 12/7/2012 2:50 PM, Arnaud Charlet wrote:


Anyway, I'll let Robert have the final word on this one.

I'm fine with either solution (converting to LF, or marking files binary,
or a mix of both).

Arno



I would convert to LF, I think it causes less confusion

Re: PR rtl-optimization/51771: revert TM returns twice kludge

[Aldy Hernandez]

On 12/07/12 14:04, Richard Henderson wrote:

On 2012-12-05 15:06, Aldy Hernandez wrote:

PR rtl-optimization/51771
Revert:
* builtin-attrs.def (ATTR_RETURNS_TWICE, ATTR_TM_NOTHROW_RT_LIST): New.
* gtm-builtins.def (BUILT_IN_TM_START): Add returns-twice attrib.

Are we absolutely sure that the rtl edges are fixed?
Fixing only the gimple level edges doesn't really help the regsister allocator.


I'm actually sure that the rtl edges are NOT fixed in the rtl :).

All the back edges are removed prior to generating RTL in 
gimple_expand_cfg(), seemingly by design:


  /* At the moment not all abnormal edges match the RTL
 representation.  It is safe to remove them here as
 find_many_sub_basic_blocks will rediscover them.
 In the future we should get this fixed properly.  */

What I was assuming was that the returns-twice kludge was papering over 
some other issue, because we were never sure that the lack of edges was 
actually causing the problem in the PR.  I can't find any tests 
(internal or external) that need the returns-twice hack.


I am hoping that by removing this hack we can find actual problems.

However, if you believe the RTL edge dropping in gimple_expand_cfg() is 
problematic, I can look into fixing this, though it would be nice to 
have a test I can work off of.


Aldy

Re: PR rtl-optimization/51771: revert TM returns twice kludge

[Richard Henderson]

On 2012-12-07 14:11, Aldy Hernandez wrote:
> I am hoping that by removing this hack we can find actual problems.
> 
> However, if you believe the RTL edge dropping in gimple_expand_cfg() is 
> problematic, I can look into fixing this, though it would be nice to have a 
> test I can work off of.

Lets leave this for 4.9 work then.


r~

Re: PR c++/55513: do not fold away builtins in COMPOUND_EXPRs

[Jason Merrill]

On 12/07/2012 01:08 PM, Aldy Hernandez wrote:

+  if (!TREE_CONSTANT (new_call))
+*non_constant_p = true;


You can use VERIFY_CONSTANT here instead.  OK with that change.

Jason

Re: PR c++/55513: do not fold away builtins in COMPOUND_EXPRs

[Aldy Hernandez]

On 12/07/12 14:28, Jason Merrill wrote:

On 12/07/2012 01:08 PM, Aldy Hernandez wrote:

+  if (!TREE_CONSTANT (new_call))
+*non_constant_p = true;


You can use VERIFY_CONSTANT here instead.  OK with that change.

Jason



VERIFY_CONSTANT is defined further down, so I moved things around.

OK with these changes, or would you rather me rearrange things differently?

commit 7ba66e780950761d286ce40db8c457d9d8bfd744
Author: Aldy Hernandez 
Date:   Fri Dec 7 10:40:25 2012 -0600

PR c++/55513
* semantics.c (cxx_eval_builtin_function_call): Set non_constant_p
after folding.

diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 491d97c..92b4a2b 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -45,6 +45,13 @@ along with GCC; see the file COPYING3.  If not see
 #include "bitmap.h"
 #include "hash-table.h"
 
+static bool verify_constant (tree, bool, bool *, bool *);
+#define VERIFY_CONSTANT(X) \
+do {   \
+  if (verify_constant ((X), allow_non_constant, non_constant_p, overflow_p)) \
+return t;  \
+ } while (0)
+
 /* There routines provide a modular interface to perform many parsing
operations.  They may therefore be used during actual parsing, or
during template instantiation, which may be regarded as a
@@ -6437,7 +6444,9 @@ cxx_eval_builtin_function_call (const constexpr_call 
*call, tree t,
 return t;
   new_call = build_call_array_loc (EXPR_LOCATION (t), TREE_TYPE (t),
CALL_EXPR_FN (t), nargs, args);
-  return fold (new_call);
+  new_call = fold (new_call);
+  VERIFY_CONSTANT (new_call);
+  return new_call;
 }
 
 /* TEMP is the constant value of a temporary object of type TYPE.  Adjust
@@ -6738,11 +6747,6 @@ verify_constant (tree t, bool allow_non_constant, bool 
*non_constant_p,
 }
   return *non_constant_p;
 }
-#define VERIFY_CONSTANT(X) \
-do {   \
-  if (verify_constant ((X), allow_non_constant, non_constant_p, overflow_p)) \
-return t;  \
- } while (0)
 
 /* Subroutine of cxx_eval_constant_expression.
Attempt to reduce the unary expression tree T to a compile time value.
diff --git a/gcc/testsuite/g++.dg/pr55513.C b/gcc/testsuite/g++.dg/pr55513.C
new file mode 100644
index 000..06eedee
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pr55513.C
@@ -0,0 +1,12 @@
+// { dg-do compile }
+// { dg-options "-O0 -fdump-tree-gimple" }
+
+main ()
+{
+  char s[10];
+  const int t = (__builtin_memcpy (s, "Hello", 6), 777);
+  __builtin_printf ("%d %s\n", t, s);
+}
+
+// { dg-final { scan-tree-dump-times "memcpy" 1 "gimple" } }
+// { dg-final { cleanup-tree-dump "gimple" } }

Re: libgo: ^M in source files

[Ian Lance Taylor]

On Fri, Dec 7, 2012 at 11:02 AM, Mike Stump  wrote:
> So I found some ^Ms in libgo.
>
> $ grep -l '^M' libgo/go/mime/multipart/testdata/nested-mime
> libgo/go/mime/multipart/testdata/nested-mime
>
> This file is likely meant to contain them if I don't miss my guess.  The 
> problem is, it is not tagged as a binary file in svn and git, leading to 
> inconsistent contents depending upon how it is pulled.  Could you either tag 
> as binary in svn/git or strip the the ^Ms, thanks.

I did mark the file as binary on June 11, 2012.  I checked a current
SVN working directory and it is marked as binary for me (use svn
proplist and svn propget svn:mime-type to see this).

If you are using the git repository, is it possible that git is
somehow not reflecting that change?

Ian

patch to fix pr55141

[Vladimir Makarov]

  The following patch fixes

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

  The patch was successfully bootstrapped on x86/x86-64.

  Committed as rev. 194308.

2012-12-07  Vladimir Makarov  

testsuite/gcc.target/i386/pr55141.c
* lra-constraints.c (lra_constraints): Use biggest mode for
df_set_regs_ever_live.

2012-12-07  Vladimir Makarov  

PR rtl-optimization/55141
* gcc.target/i386/pr55141.c: New.

Index: lra-constraints.c
===
--- lra-constraints.c   (revision 194307)
+++ lra-constraints.c   (working copy)
@@ -3329,8 +3329,9 @@ lra_constraints (bool first_p)
reg = regno_reg_rtx[i];
if ((hard_regno = lra_get_regno_hard_regno (i)) >= 0)
  {
-   int j, nregs = hard_regno_nregs[hard_regno][PSEUDO_REGNO_MODE (i)];
+   int j, nregs;
 
+   nregs = hard_regno_nregs[hard_regno][lra_reg_info[i].biggest_mode];
for (j = 0; j < nregs; j++)
  df_set_regs_ever_live (hard_regno + j, true);
  }
Index: testsuite/gcc.target/i386/pr55141.c
===
--- testsuite/gcc.target/i386/pr55141.c (revision 0)
+++ testsuite/gcc.target/i386/pr55141.c (working copy)
@@ -0,0 +1,29 @@
+/* { dg-do run } */
+/* { dg-options "-O -fno-split-wide-types" } */
+
+typedef struct
+{
+  long int p_x, p_y;
+} Point;
+
+static __attribute__ ((noinline, noclone))
+ void foo (Point p0, Point p1, Point p2, Point p3)
+{
+  if (p0.p_x != 1
+  || p1.p_x != 3
+  || p2.p_x != 5
+  || p3.p_x != 7)
+__builtin_abort ();
+}
+
+int
+main (int argc, char *argv[])
+{
+  Point p0, p1, p2, p3, p4, p5;
+  p0.p_x = 1;
+  p1.p_x = 3;
+  p2.p_x = 5;
+  p3.p_x = 7;
+  foo (p0, p1, p2, p3);
+  return 0;
+}

Re: Ada: ^M in ada source files

[Mike Stump]

On Dec 7, 2012, at 12:08 PM, Robert Dewar  wrote:
> I would convert to LF, I think it causes less confusion

Done.

2012-12-07  Mike Stump  

* gnat.dg/discr38.adb: Don't use ^M line endings.
gnat.dg/loop_optimization13.adb: Likewise.
gnat.dg/loop_optimization13.ads: Likewise.
gnat.dg/discr36_pkg.adb: Likewise.
gnat.dg/discr36_pkg.ads: Likewise.
gnat.dg/loop_optimization11_pkg.ads: Likewise.
gnat.dg/discr36.ads: Likewise.
gnat.dg/loop_optimization11.adb: Likewise.

Index: discr38.adb
===
--- discr38.adb (revision 194308)
+++ discr38.adb (working copy)
@@ -1,40 +1,40 @@
--- { dg-do compile }
-
-procedure Discr38 is
-
-   type Enum is (OK,
- NOT_CONNECTED,
- DISCONNECTED,
- REQUEST_Q_EMPTY,
- SERVER_UNAVAILABLE,
- BUFFER_TOO_SMALL,
- NO_FREE_SLOT,
- RAISE_EXCEPTION,
- REQUEST_CANCELLED,
- REQUEST_IN_PROGRESS,
- SERVER_BUSY,
- BLOCK_ACKNOWLEDGE);
-
-   type R (Status : Enum := OK) is record
-  Status_Block : Integer;
-  case Status is
-  when RAISE_EXCEPTION =>
- I : Integer;
-  when OK =>
- Length : Natural;
- Data   : Integer;
-  when others =>
- null;
-  end case;
-   end record;
-   for R use record
-  Statusat  0 range 0 .. 7;
-  Status_Block  at  4 range 0 .. 31;
-  Lengthat  8 range 0 .. 31;
-   end record;
-
-   Nil : constant R := (OK, 1, 0, 1);
-
-begin
-   null;
-end;
+-- { dg-do compile }
+
+procedure Discr38 is
+
+   type Enum is (OK,
+ NOT_CONNECTED,
+ DISCONNECTED,
+ REQUEST_Q_EMPTY,
+ SERVER_UNAVAILABLE,
+ BUFFER_TOO_SMALL,
+ NO_FREE_SLOT,
+ RAISE_EXCEPTION,
+ REQUEST_CANCELLED,
+ REQUEST_IN_PROGRESS,
+ SERVER_BUSY,
+ BLOCK_ACKNOWLEDGE);
+
+   type R (Status : Enum := OK) is record
+  Status_Block : Integer;
+  case Status is
+  when RAISE_EXCEPTION =>
+ I : Integer;
+  when OK =>
+ Length : Natural;
+ Data   : Integer;
+  when others =>
+ null;
+  end case;
+   end record;
+   for R use record
+  Statusat  0 range 0 .. 7;
+  Status_Block  at  4 range 0 .. 31;
+  Lengthat  8 range 0 .. 31;
+   end record;
+
+   Nil : constant R := (OK, 1, 0, 1);
+
+begin
+   null;
+end;
Index: loop_optimization13.adb
===
--- loop_optimization13.adb (revision 194308)
+++ loop_optimization13.adb (working copy)
@@ -1,21 +1,21 @@
--- { dg-do compile }
--- { dg-options "-O" }
-
-with Loop_Optimization13_Pkg; use Loop_Optimization13_Pkg;
-
-package body Loop_Optimization13 is
-
-   function F (A : Rec) return Rec is
-  N : constant Integer := A.V'Length / L;
-  Res : Rec
-:= (True, new Complex_Vector' (0 .. A.V'Length / L - 1 => (0.0, 0.0)));
-   begin
-  for I in 0 .. L - 1 loop
- for J in 0 .. N - 1 loop
-Res.V (J) := Res.V (J) + A.V (I * N + J);
- end loop;
-  end loop;
-  return Res;
-   end;
-
-end Loop_Optimization13;
+-- { dg-do compile }
+-- { dg-options "-O" }
+
+with Loop_Optimization13_Pkg; use Loop_Optimization13_Pkg;
+
+package body Loop_Optimization13 is
+
+   function F (A : Rec) return Rec is
+  N : constant Integer := A.V'Length / L;
+  Res : Rec
+:= (True, new Complex_Vector' (0 .. A.V'Length / L - 1 => (0.0, 0.0)));
+   begin
+  for I in 0 .. L - 1 loop
+ for J in 0 .. N - 1 loop
+Res.V (J) := Res.V (J) + A.V (I * N + J);
+ end loop;
+  end loop;
+  return Res;
+   end;
+
+end Loop_Optimization13;
Index: loop_optimization13.ads
===
--- loop_optimization13.ads (revision 194308)
+++ loop_optimization13.ads (working copy)
@@ -1,17 +1,17 @@
-with Ada.Numerics.Complex_Types; use Ada.Numerics.Complex_Types;
-
-package Loop_Optimization13 is
-
-   type Complex_Vector is array (Integer range <>) of Complex;
-   type Complex_Vector_Ptr is access Complex_Vector;
-
-   type Rec (Kind : Boolean := False) is record
-  case Kind is
- when True => V : Complex_Vector_Ptr;
- when False => null;
-  end case;
-   end record;
-
-   function F (A : Rec) return Rec;
-
-end Loop_Optimization13;
+with Ada.Numerics.Complex_Types; use Ada.Numerics.Complex_Types;
+
+package Loop_Optimization13 is
+
+   type Complex_Vector is array (Integer range <>) of Complex;
+   type Complex_Vector_Ptr is access Complex_Vector;
+
+   type Rec (Kind : Boolean := False) is record
+  case Kind is
+ when True => V : Com

Re: Minimize downward code motion during reassociation

[Alexandre Oliva]

On Dec  6, 2012, Richard Biener  wrote:

> On Tue, Nov 6, 2012 at 1:54 AM, Easwaran Raman  wrote:
>> I am unable to figure out the right way to handle the debug
>> statements. What I tried was to find debug statements that use the SSA
>> name defined by the statement I moved (using SSA_NAME_IMM_USE_NODE)
>> and then moved them as well at the right place. Thus, if I have to
>> move t1 = a + b down (after the definition of 'd'), I also moved all
>> debug statements that use t1 after the new position of t1. That still
>> caused use-before-def problems in ssa_verify. I noticed that the debug
>> statements got modified behind the scenes causing these issues. Any
>> hints on what is the right way to handle the debug statements would be
>> very helpful.

> I think you cannot (and should not) move debug statements.

Yup.

If you must move a DEF past a debug stmt that USEs it, resetting the
debug stmt is a (poor) option, but inserting a debug temp bound to the
expression moved down, and replacing the use in the debug stmt with a
use of the debug temp.  I.e., given:

  x_? = 
  # DEBUG y => x_?
  ...

change that to:

  # DEBUG T.?? => 
  # DEBUG y => T.??
  ...
  x_? = 

-- 
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist  Red Hat Brazil Compiler Engineer

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

[Steve Ellcey]

This is my attempt to fix PR 54061, a bug where GCC aborts while trying to
put out debug information for a co-processor register.  My understanding is
that gdb cannot access the coprocessor registers and so there is no valid
debug information that can be put out for this case.  So my fix is to remove
the assert from dbx_reg_number and change the callers to check for a
INVALID_REGNUM value coming from dbx_reg_number.  If they get this value
then they do not put out any debug information for the register.  I have
tested this on gcc.c-torture/compile/mipscop-[1234].c and it fixes the abort.

I haven't done a full regression test but will do that shortly, in the mean
time I wanted to see if this approach was considered acceptable and if not,
how I should fix it?

Steve Ellcey
sell...@mips.com


2012-12-07  Steve Ellcey  

PR target/54061
* dwarfwout.c (dbx_reg_number): Remove assert.
(reg_loc_descriptor): Check for INVALID_REGNUM.
(mem_loc_descriptor): Ditto.

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index f0256ae..7d26e7e 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -10438,7 +10438,6 @@ dbx_reg_number (const_rtx rtl)
 #endif
 
   regno = DBX_REGISTER_NUMBER (regno);
-  gcc_assert (regno != INVALID_REGNUM);
   return regno;
 }
 
@@ -10473,6 +10472,9 @@ reg_loc_descriptor (rtx rtl, enum var_init_status 
initialized)
   if (REGNO (rtl) >= FIRST_PSEUDO_REGISTER)
 return 0;
 
+  if (dbx_reg_number(rtl) == INVALID_REGNUM)
+return 0;
+
   /* We only use "frame base" when we're sure we're talking about the
  post-prologue local stack frame.  We do this by *not* running
  register elimination until this point, and recognizing the special
@@ -11931,6 +11933,8 @@ mem_loc_descriptor (rtx rtl, enum machine_mode mode,
break;
  if (REGNO (rtl) > FIRST_PSEUDO_REGISTER)
break;
+ if (dbx_reg_number (rtl) == INVALID_REGNUM)
+   break;
  type_die = base_type_for_mode (mode,
 GET_MODE_CLASS (mode) == MODE_INT);
  if (type_die == NULL)
@@ -12133,6 +12137,9 @@ mem_loc_descriptor (rtx rtl, enum machine_mode mode,
return NULL;
   if (REG_P (ENTRY_VALUE_EXP (rtl)))
{
+ if (dbx_reg_number (ENTRY_VALUE_EXP (rtl)) == INVALID_REGNUM)
+   return NULL;
+
  if (GET_MODE_CLASS (mode) != MODE_INT
  || GET_MODE_SIZE (mode) > DWARF2_ADDR_SIZE)
op0 = mem_loc_descriptor (ENTRY_VALUE_EXP (rtl), mode,

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

[H.J. Lu]

On Fri, Dec 7, 2012 at 1:59 PM, Steve Ellcey  wrote:
> This is my attempt to fix PR 54061, a bug where GCC aborts while trying to
> put out debug information for a co-processor register.  My understanding is
> that gdb cannot access the coprocessor registers and so there is no valid
> debug information that can be put out for this case.  So my fix is to remove
> the assert from dbx_reg_number and change the callers to check for a
> INVALID_REGNUM value coming from dbx_reg_number.  If they get this value
> then they do not put out any debug information for the register.  I have
> tested this on gcc.c-torture/compile/mipscop-[1234].c and it fixes the abort.
>
> I haven't done a full regression test but will do that shortly, in the mean
> time I wanted to see if this approach was considered acceptable and if not,
> how I should fix it?
>
> Steve Ellcey
> sell...@mips.com
>
>
> 2012-12-07  Steve Ellcey  
>
> PR target/54061
> * dwarfwout.c (dbx_reg_number): Remove assert.
> (reg_loc_descriptor): Check for INVALID_REGNUM.
> (mem_loc_descriptor): Ditto.
>
> diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
> index f0256ae..7d26e7e 100644
> --- a/gcc/dwarf2out.c
> +++ b/gcc/dwarf2out.c
> @@ -10438,7 +10438,6 @@ dbx_reg_number (const_rtx rtl)
>  #endif
>
>regno = DBX_REGISTER_NUMBER (regno);
> -  gcc_assert (regno != INVALID_REGNUM);
>return regno;
>  }

I added it for

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

In this bug, we used the wrong register to generate DWARF
info.  Your patch removes the assert, which may make GCC
silently generate bad DWARF info.

> @@ -10473,6 +10472,9 @@ reg_loc_descriptor (rtx rtl, enum var_init_status 
> initialized)
>if (REGNO (rtl) >= FIRST_PSEUDO_REGISTER)
>  return 0;
>
> +  if (dbx_reg_number(rtl) == INVALID_REGNUM)
> +return 0;
> +
>/* We only use "frame base" when we're sure we're talking about the
>   post-prologue local stack frame.  We do this by *not* running
>   register elimination until this point, and recognizing the special
> @@ -11931,6 +11933,8 @@ mem_loc_descriptor (rtx rtl, enum machine_mode mode,
> break;
>   if (REGNO (rtl) > FIRST_PSEUDO_REGISTER)
> break;
> + if (dbx_reg_number (rtl) == INVALID_REGNUM)
> +   break;
>   type_die = base_type_for_mode (mode,
>  GET_MODE_CLASS (mode) == MODE_INT);
>   if (type_die == NULL)
> @@ -12133,6 +12137,9 @@ mem_loc_descriptor (rtx rtl, enum machine_mode mode,
> return NULL;
>if (REG_P (ENTRY_VALUE_EXP (rtl)))
> {
> + if (dbx_reg_number (ENTRY_VALUE_EXP (rtl)) == INVALID_REGNUM)
> +   return NULL;
> +
>   if (GET_MODE_CLASS (mode) != MODE_INT
>   || GET_MODE_SIZE (mode) > DWARF2_ADDR_SIZE)
> op0 = mem_loc_descriptor (ENTRY_VALUE_EXP (rtl), mode,

I think you need a way to tell a bad register from a good register
which doesn't have DWARF register number.

-- 
H.J.

Re: libgo: ^M in source files

[Mike Stump]

On Dec 7, 2012, at 12:59 PM, Ian Lance Taylor  wrote:
> I did mark the file as binary on June 11, 2012.  I checked a current
> SVN working directory and it is marked as binary for me (use svn
> proplist and svn propget svn:mime-type to see this).

Yup, svn looks good.

> If you are using the git repository, is it possible that git is
> somehow not reflecting that change?

something seems to have messed it up for me.  I went back and checked the 
unmodified git which serves as the base for my branch, and it came up 
correctly.  Very odd.  git log seems to blame git merge.  :-(  Sounds like a 
git edge case they got wrong.  Since svn and git get the right contents, there 
isn't anything to fix that I know of.

Thanks.

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

[H.J. Lu]

On Fri, Dec 7, 2012 at 2:17 PM, H.J. Lu  wrote:
> On Fri, Dec 7, 2012 at 1:59 PM, Steve Ellcey  wrote:
>> This is my attempt to fix PR 54061, a bug where GCC aborts while trying to
>> put out debug information for a co-processor register.  My understanding is
>> that gdb cannot access the coprocessor registers and so there is no valid
>> debug information that can be put out for this case.  So my fix is to remove
>> the assert from dbx_reg_number and change the callers to check for a
>> INVALID_REGNUM value coming from dbx_reg_number.  If they get this value
>> then they do not put out any debug information for the register.  I have
>> tested this on gcc.c-torture/compile/mipscop-[1234].c and it fixes the abort.
>>
>> I haven't done a full regression test but will do that shortly, in the mean
>> time I wanted to see if this approach was considered acceptable and if not,
>> how I should fix it?
>>
>> Steve Ellcey
>> sell...@mips.com
>>
>>
>> 2012-12-07  Steve Ellcey  
>>
>> PR target/54061
>> * dwarfwout.c (dbx_reg_number): Remove assert.
>> (reg_loc_descriptor): Check for INVALID_REGNUM.
>> (mem_loc_descriptor): Ditto.
>>
>> diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
>> index f0256ae..7d26e7e 100644
>> --- a/gcc/dwarf2out.c
>> +++ b/gcc/dwarf2out.c
>> @@ -10438,7 +10438,6 @@ dbx_reg_number (const_rtx rtl)
>>  #endif
>>
>>regno = DBX_REGISTER_NUMBER (regno);
>> -  gcc_assert (regno != INVALID_REGNUM);
>>return regno;
>>  }
>
> I added it for
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52857
>
> In this bug, we used the wrong register to generate DWARF
> info.  Your patch removes the assert, which may make GCC
> silently generate bad DWARF info.
>
>> @@ -10473,6 +10472,9 @@ reg_loc_descriptor (rtx rtl, enum var_init_status 
>> initialized)
>>if (REGNO (rtl) >= FIRST_PSEUDO_REGISTER)
>>  return 0;
>>
>> +  if (dbx_reg_number(rtl) == INVALID_REGNUM)
>> +return 0;
>> +
>>/* We only use "frame base" when we're sure we're talking about the
>>   post-prologue local stack frame.  We do this by *not* running
>>   register elimination until this point, and recognizing the special
>> @@ -11931,6 +11933,8 @@ mem_loc_descriptor (rtx rtl, enum machine_mode mode,
>> break;
>>   if (REGNO (rtl) > FIRST_PSEUDO_REGISTER)
>> break;
>> + if (dbx_reg_number (rtl) == INVALID_REGNUM)
>> +   break;
>>   type_die = base_type_for_mode (mode,
>>  GET_MODE_CLASS (mode) == MODE_INT);
>>   if (type_die == NULL)
>> @@ -12133,6 +12137,9 @@ mem_loc_descriptor (rtx rtl, enum machine_mode mode,
>> return NULL;
>>if (REG_P (ENTRY_VALUE_EXP (rtl)))
>> {
>> + if (dbx_reg_number (ENTRY_VALUE_EXP (rtl)) == INVALID_REGNUM)
>> +   return NULL;
>> +
>>   if (GET_MODE_CLASS (mode) != MODE_INT
>>   || GET_MODE_SIZE (mode) > DWARF2_ADDR_SIZE)
>> op0 = mem_loc_descriptor (ENTRY_VALUE_EXP (rtl), mode,
>
> I think you need a way to tell a bad register from a good register
> which doesn't have DWARF register number.
>

Something like

#define IGNORED_DWARF_REGNUM(INVALID_REGNUM - 1)

-- 
H.J.

Re: Using -ffunction-sections and -p

[Sriraman Tallam]

I have submitted this patch.

* toplev.c (process_options): Do not warn when -ffunction-sections
and -fprofile are used together.

Index: gcc/toplev.c
===
--- gcc/toplev.c (revision 194306)
+++ gcc/toplev.c (working copy)
@@ -1478,12 +1478,6 @@ process_options (void)
  }
 }

-  if (flag_function_sections && profile_flag)
-{
-  warning (0, "-ffunction-sections disabled; it makes profiling
impossible");
-  flag_function_sections = 0;
-}
-
 #ifndef HAVE_prefetch
   if (flag_prefetch_loop_arrays > 0)
 {

Thanks,
-Sri.

On Tue, Dec 4, 2012 at 1:43 PM, Sriraman Tallam  wrote:
> On Tue, Dec 4, 2012 at 1:31 PM, Jeff Law  wrote:
>> On 12/03/2012 01:08 PM, Sriraman Tallam wrote:
>>>
>>> Hi Jeff,
>>>
>>> Wondering if you got a chance to do this?
>>
>> Hmm, thinking more about this, it couldn't have been a 32 bit HPUX issue.
>> First that port claims to not support -ffunction-sections -- which is true,
>> we can't make arbitrarily named sections, though each function is placed
>> into its own $CODE$ section/subspace.
>>
>> Second, even with each function in its own $CODE$ subspace, profiling works.
>>
>> So it couldn't have been 32 bit HPUX.
>>
>> I think Ian's plan of going forward and see if anyone complains is
>> reasonable.  Regardless, we're talking about OSs that are > 10 years old,.
>> the odds of folks building modern versions of GCC is pretty slim.  The odds
>> they're building modern versions of GCC and care about both
>> function-sections and profiling is probably approaching zero.
>>
>> Jeff
>>

Re: Using -ffunction-sections and -p

[Jeff Law]

On 12/07/2012 03:46 PM, Sriraman Tallam wrote:

I have submitted this patch.

 * toplev.c (process_options): Do not warn when -ffunction-sections
 and -fprofile are used together.

Approved.  Please install.

jeff

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

[Steve Ellcey]

On Fri, 2012-12-07 at 14:43 -0800, H.J. Lu wrote:

> > I think you need a way to tell a bad register from a good register
> > which doesn't have DWARF register number.
> >
> 
> Something like
> 
> #define IGNORED_DWARF_REGNUM(INVALID_REGNUM - 1)

The other option would be to have a new macro that returned true or
false if a register had a dbx register number.

#define VALID_DBX_REGNUM(regno) (true)

and check that instead of checking the return of dbx_reg_number().

A target would override this default definition of VALID_DBX_REGNUM
for registers it wanted to ignore.  It should probably be a target
macro but so should DBX_REGISTER_NUMBER and DWARF_FRAME_REGNUM, we
probably don't want to be making that change at this time in the release
cycle.

Steve Ellcey
sell...@mips.com

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

[H.J. Lu]

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);
-
   /* 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, mips, debug] Fix PR 54061, mips compiler aborts in testsuite

[H.J. Lu]

On Fri, Dec 7, 2012 at 2:55 PM, Steve Ellcey  wrote:
> On Fri, 2012-12-07 at 14:43 -0800, H.J. Lu wrote:
>
>> > I think you need a way to tell a bad register from a good register
>> > which doesn't have DWARF register number.
>> >
>>
>> Something like
>>
>> #define IGNORED_DWARF_REGNUM(INVALID_REGNUM - 1)
>
> The other option would be to have a new macro that returned true or
> false if a register had a dbx register number.
>
> #define VALID_DBX_REGNUM(regno) (true)
>
> and check that instead of checking the return of dbx_reg_number().
>
> A target would override this default definition of VALID_DBX_REGNUM
> for registers it wanted to ignore.  It should probably be a target
> macro but so should DBX_REGISTER_NUMBER and DWARF_FRAME_REGNUM, we
> probably don't want to be making that change at this time in the release
> cycle.

One case is a valid register without valid DWARF register
number.  The other is an invalid register.  Both have
invalid DWARF register number.  I don't think
VALID_DBX_REGNUM works here.

-- 
H.J.

Re: [lra] a patch to fix ppc bootstrap failure

[Michael Meissner]

On Thu, Dec 06, 2012 at 04:20:46PM -0500, Vladimir Makarov wrote:
> LRA should have change spilled pseudo 199 to memory.  LRA did not do
> that because the insn is in list of insns used by pseudo 199.  This
> might happen only when the insn is not recognized.
> 
> The following patch fixes the bug.
> 
> Committed as rev. 194270.
> 
> 2012-12-06  Vladimir Makarov  
> 
> * rtl.h (SUBREG_MATCH_RELOAD_P): Rename to LRA_SUBREG_P.
> * recog.c (register_operand): Check LRA_SUBREG_P.
> * lra-constraints.c (match_reload, simplify_operand_subreg): Use
> LRA_SUBREG_P.
> (emit_spill_move): Set up LRA_SUBREG_P.

Yes this fixes the bug and allows a bootstrap.  Thanks.  Note, the fortran
compiler in your branch is buggy, and I get a lot of failures when doing a make
check.  I don't get similar failures on today's branch (not using LRA).

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

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

[Steve Ellcey]

> On Fri, 2012-12-07 at 14:43 -0800, H.J. Lu wrote:
>
>> > I think you need a way to tell a bad register from a good register
>> > which doesn't have DWARF register number.

Here is a patch using your IGNORED_DWARF_REGNUM idea.

Steve Ellcey
sell...@mips.com


2012-12-07  Steve Ellcey  

PR target/54061
* rtl.h (IGNORED_DWARF_REGNUM): New.
* dwarfwout.c (reg_loc_descriptor): Check for IGNORED_DWARF_REGNUM.
(mem_loc_descriptor): Ditto.
* 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..bc99f29 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 = COP0_REG_FIRST; i <= COP3_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/dwarf2out.c b/gcc/dwarf2out.c
index f0256ae..caedb5f 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -10473,6 +10473,9 @@ reg_loc_descriptor (rtx rtl, enum var_init_status 
initialized)
   if (REGNO (rtl) >= FIRST_PSEUDO_REGISTER)
 return 0;
 
+  if (dbx_reg_number(rtl) == IGNORED_DWARF_REGNUM)
+return 0;
+
   /* We only use "frame base" when we're sure we're talking about the
  post-prologue local stack frame.  We do this by *not* running
  register elimination until this point, and recognizing the special
@@ -11931,6 +11934,8 @@ mem_loc_descriptor (rtx rtl, enum machine_mode mode,
break;
  if (REGNO (rtl) > FIRST_PSEUDO_REGISTER)
break;
+ if (dbx_reg_number(rtl) == IGNORED_DWARF_REGNUM)
+   break;
  type_die = base_type_for_mode (mode,
 GET_MODE_CLASS (mode) == MODE_INT);
  if (type_die == NULL)
@@ -12133,6 +12138,9 @@ mem_loc_descriptor (rtx rtl, enum machine_mode mode,
return NULL;
   if (REG_P (ENTRY_VALUE_EXP (rtl)))
{
+ if (dbx_reg_number (ENTRY_VALUE_EXP (rtl)) == IGNORED_DWARF_REGNUM)
+   return NULL;
+
  if (GET_MODE_CLASS (mode) != MODE_INT
  || GET_MODE_SIZE (mode) > DWARF2_ADDR_SIZE)
op0 = mem_loc_descriptor (ENTRY_VALUE_EXP (rtl), mode,
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 appearing in the INSN stream.  */
 #define INVALID_REGNUM (~(unsigned int) 0)
 
+/* REGNUM for which no debug information can be generated.  */
+#define IGNORED_DWARF_REGNUM(INVALID_REGNUM - 1)
+
 extern rtx output_constant_def (tree, int);
 extern rtx lookup_constant_def (tree);
 

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

[Cary Coutant]

> 2012-12-07  Steve Ellcey  
>
> PR target/54061
> * rtl.h (IGNORED_DWARF_REGNUM): New.
> * dwarfwout.c (reg_loc_descriptor): Check for IGNORED_DWARF_REGNUM.

Typo: s/dwarfwout/dwarf2out/

> (mem_loc_descriptor): Ditto.
> * config/mips/mips.c (mips_option_override): Set mips_dbx_regno
> coprocessor entries to IGNORED_DWARF_REGNUM.

-cary

Re: PR c++/55513: do not fold away builtins in COMPOUND_EXPRs

[Jason Merrill]

OK.

Jason

C++ PATCH for c++/55127 (bogus required typename)

[Jason Merrill]

My patch that introduced "instantiation-dependent" to the compiler 
treated all SCOPE_REFs as instantiation-dependent, on the principle that 
we might need to check accessibility at instantiation time.  But if the 
member reference is public, it will always be accessible, so we don't 
need to worry.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit d891f539e75bd20fd6fb303aff4a06a053f10ae6
Author: Jason Merrill 
Date:   Fri Dec 7 14:33:08 2012 -0500

	PR c++/55127
	* search.c (accessible_in_template_p): New.
	* cp-tree.h: Declare it.
	* pt.c (instantiation_dependent_scope_ref_p): New.
	(value_dependent_expression_p): Use it.
	(instantiation_dependent_r): Likewise.
	* semantics.c (finish_decltype_type): Handle SCOPE_REF.

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index ceac093..1733250 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -5489,6 +5489,7 @@ extern tree lookup_base (tree, tree, base_access,
 		 base_kind *, tsubst_flags_t);
 extern tree dcast_base_hint			(tree, tree);
 extern int accessible_p(tree, tree, bool);
+extern int accessible_in_template_p		(tree, tree);
 extern tree lookup_field_1			(tree, tree, bool);
 extern tree lookup_field			(tree, tree, int, bool);
 extern int lookup_fnfields_1			(tree, tree);
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 33044e0..1bc9e1b 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -19293,6 +19293,22 @@ dependent_scope_p (tree scope)
 	  && !currently_open_class (scope));
 }
 
+/* T is a SCOPE_REF; return whether we need to consider it
+instantiation-dependent so that we can check access at instantiation
+time even though we know which member it resolves to.  */
+
+static bool
+instantiation_dependent_scope_ref_p (tree t)
+{
+  if (DECL_P (TREE_OPERAND (t, 1))
+  && CLASS_TYPE_P (TREE_OPERAND (t, 0))
+  && accessible_in_template_p (TREE_OPERAND (t, 0),
+   TREE_OPERAND (t, 1)))
+return false;
+  else
+return true;
+}
+
 /* Returns TRUE if the EXPRESSION is value-dependent, in the sense of
[temp.dep.constexpr].  EXPRESSION is already known to be a constant
expression.  */
@@ -19400,10 +19416,9 @@ value_dependent_expression_p (tree expression)
   return instantiation_dependent_expression_p (expression);
 
 case SCOPE_REF:
-  /* instantiation_dependent_r treats this as dependent so that we
-	 check access at instantiation time, and all instantiation-dependent
-	 expressions should also be considered value-dependent.  */
-  return true;
+  /* All instantiation-dependent expressions should also be considered
+	 value-dependent.  */
+  return instantiation_dependent_scope_ref_p (expression);
 
 case COMPONENT_REF:
   return (value_dependent_expression_p (TREE_OPERAND (expression, 0))
@@ -19744,10 +19759,10 @@ instantiation_dependent_r (tree *tp, int *walk_subtrees,
   break;
 
 case SCOPE_REF:
-  /* Similarly, finish_qualified_id_expr builds up a SCOPE_REF in a
-	 template so that we can check access at instantiation time even
-	 though we know which member it resolves to.  */
-  return *tp;
+  if (instantiation_dependent_scope_ref_p (*tp))
+	return *tp;
+  else
+	break;
 
 default:
   break;
diff --git a/gcc/cp/search.c b/gcc/cp/search.c
index 92234a5..1cd4fc5 100644
--- a/gcc/cp/search.c
+++ b/gcc/cp/search.c
@@ -832,6 +832,19 @@ dfs_accessible_post (tree binfo, void * /*data*/)
   return NULL_TREE;
 }
 
+/* Like accessible_p below, but within a template returns true iff DECL is
+   accessible in TYPE to all possible instantiations of the template.  */
+
+int
+accessible_in_template_p (tree type, tree decl)
+{
+  int save_ptd = processing_template_decl;
+  processing_template_decl = 0;
+  int val = accessible_p (type, decl, false);
+  processing_template_decl = save_ptd;
+  return val;
+}
+
 /* DECL is a declaration from a base class of TYPE, which was the
class used to name DECL.  Return nonzero if, in the current
context, DECL is accessible.  If TYPE is actually a BINFO node,
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 491d97c..0fa251b 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -5261,7 +5261,8 @@ finish_decltype_type (tree expr, bool id_expression_or_member_access_p,
 expr = TREE_OPERAND (expr, 0);
 
   if (TREE_CODE (expr) == OFFSET_REF
-  || TREE_CODE (expr) == MEMBER_REF)
+  || TREE_CODE (expr) == MEMBER_REF
+	  || TREE_CODE (expr) == SCOPE_REF)
 /* We're only interested in the field itself. If it is a
BASELINK, we will need to see through it in the next
step.  */
diff --git a/gcc/testsuite/g++.dg/template/defarg16.C b/gcc/testsuite/g++.dg/template/defarg16.C
new file mode 100644
index 000..ba78bfb
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/defarg16.C
@@ -0,0 +1,28 @@
+// PR c++/55127
+
+struct some_class
+{
+  static const bool is_valid_type = true;
+};
+
+template< typenam