Re: RFA: PATCHes to vec.c and convert.c for c++/14179 (excessive memory consumption with array initializer)

2012-01-16 Thread Richard Guenther
On Fri, 13 Jan 2012, Jason Merrill wrote:

> While looking at the -fmem-stats results for this testcase, I noticed about
> 500MB of overhead coming from the VEC_safe_push in cp_lexer_new_main.  This is
> happening because when we allocate space for a vector, the allocator pads it
> out some, and that space ends up lost. The first patch changes the vector code
> to ask the gc allocator how much space it's really going to get, and adjust
> the number of slots to fill that space.  This reduces the VM footprint of the
> compiler for the testcase from 1704 MB to 1162 MB, an almost 32% reduction.
> 
> The second patch is derived from Jan's patch of
> 
>   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12245#c42
> 
> and further reduces the VM footprint to 967 MB, not quite back to the 2.95
> level of 717 MB, but pretty close.
> 
> Tested x86_64-pc-linux-gnu.  Are one or both of these OK for trunk?

I suppose the 2nd could be generally folding for tcc_constant, not
only integer constants (suppose an array of REAL_CSTs).

Both are IMHO ok as they address regressions.

Thanks,
Richard.


Re: [PATCH] Fix tree_function_versioning with void type DECL_RESULT (PR tree-optimization/51865)

2012-01-16 Thread Richard Guenther
On Sun, 15 Jan 2012, Jakub Jelinek wrote:

> Hi!
> 
> The recent changes in tree_function_versioning broke the following
> testcase.  If DECL_RESULT exists, but has void type, then we used to
> remap_decl it before, but now we don't, so in this case the same RESULT_DECL
> is used in two different functions, which upsets ipa-pta, but could upset
> other code too.
> 
> Fixed by calling remap_decl again for void type.  Bootstrapped/regtested
> on x86_64-linux and i686-linux (on x86_64 including ada).  Ok for trunk?

Ok.

Thanks,
Richard.

> 2012-01-15  Jakub Jelinek  
> 
>   PR tree-optimization/51865
>   * tree-inline.c (tree_function_versioning): Call remap_decl
>   on DECL_RESULT whenever it has VOID_TYPE_P type.
> 
>   * gcc.dg/pr51865.c: New test.
> 
> --- gcc/tree-inline.c.jj  2012-01-13 21:47:35.0 +0100
> +++ gcc/tree-inline.c 2012-01-15 20:00:00.350918475 +0100
> @@ -5201,9 +5201,9 @@ tree_function_versioning (tree old_decl,
>  /* Add local vars.  */
>  add_local_variables (DECL_STRUCT_FUNCTION (old_decl), cfun, &id, false);
>  
> -  if (VOID_TYPE_P (TREE_TYPE (DECL_RESULT (old_decl
> +  if (DECL_RESULT (old_decl) == NULL_TREE)
>  ;
> -  else if (skip_return)
> +  else if (skip_return && !VOID_TYPE_P (TREE_TYPE (DECL_RESULT (old_decl
>  {
>DECL_RESULT (new_decl)
>   = build_decl (DECL_SOURCE_LOCATION (DECL_RESULT (old_decl)),
> --- gcc/testsuite/gcc.dg/pr51865.c.jj 2012-01-15 20:09:00.035734459 +0100
> +++ gcc/testsuite/gcc.dg/pr51865.c2012-01-15 20:08:42.0 +0100
> @@ -0,0 +1,25 @@
> +/* PR tree-optimization/51865 */
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fipa-pta" } */
> +
> +void fn (const char *, const char *) __attribute__ ((__noreturn__));
> +int var;
> +
> +inline void
> +foo (void)
> +{
> +  if (__builtin_expect (var != 0, 0))
> +fn ("a", "b");
> +};
> +
> +void
> +bar (void)
> +{
> +  foo ();
> +};
> +
> +void
> +baz (void)
> +{
> +  foo ();
> +};
> 
>   Jakub
> 
> 

-- 
Richard Guenther 
SUSE / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer

Re: [PATCH] Fix PR33763

2012-01-16 Thread Richard Guenther
On Fri, 13 Jan 2012, Jakub Jelinek wrote:

> On Fri, Jan 13, 2012 at 11:05:36AM +0100, Richard Guenther wrote:
> > This fixes the ICEs that occur with redeclared extern inline functions
> > in some circumstances.  It avoids the cgraph confusion by _not_ merging
> > the two decls in this case but simply drops the old (extern inline)
> > one on the floor.  This causes the cgraph to be properly presented
> > with two different decls and thus two different cgraph nodes will
> > be created.  I didn't try to change name-lookup to always find
> > the extern inline copy to preserve the ever existing recursive
> > case
> > 
> > extern __inline __attribute__ ((__always_inline__))
> > void open ()
> > {
> > }
> > void open ()
> > {
> >   open ();
> > }
> > 
> > which even in 3.2 where the ICEs appearantly did not exist compiled
> > to a self-recursive open () (trivially explained by how 3.2 worked,
> > function-at-a-time).
> 
> That won't e.g. copy over any attributes from the extern inline to
> the out of line, or asm redirection, or type merging, etc.

But that's of course intended.  Attributes or redirection on the
extern inline variant are completely meaningless.

> If you want to keep olddecl as is, then IMHO we should add a new bool
> argument to merge_decls and if the flag is set, make sure we only ever
> modify newdecl and not olddecl.

I don't think that is necesary nor warranted.  What legitimate use
would break you think?

Btw, the following patch now passed bootstrap and regtest on
x86_64-unknown-linux-gnu.

Ok for trunk?

Thanks,
Richard.

2012-01-13  Richard Guenther  

PR c/33763
* c-decl.c (duplicate_decls): Do not merge re-declared extern
inline function decls with their re-declaration.
(pushdecl): Do not put extern inlines into external_scope.

* gcc.dg/torture/pr33763-1.c: New testcase.
* gcc.dg/torture/pr33763-2.c: Likewise.
* gcc.dg/torture/pr33763-3.c: Likewise.

Index: gcc/c-decl.c
===
*** gcc/c-decl.c(revision 183121)
--- gcc/c-decl.c(working copy)
*** duplicate_decls (tree newdecl, tree oldd
*** 2513,2518 
--- 2513,2536 
return false;
  }
  
+   /* If we have a redeclared extern inline function simply drop olddecl
+  on the floor instead of merging it with newdecl.  */
+   if (TREE_CODE (newdecl) == FUNCTION_DECL
+   && DECL_INITIAL (newdecl)
+   && DECL_INITIAL (olddecl)
+   && !(!(DECL_DECLARED_INLINE_P (olddecl)
+&& DECL_EXTERNAL (olddecl))
+  || (DECL_DECLARED_INLINE_P (newdecl)
+  && DECL_EXTERNAL (newdecl))
+  || (!flag_gnu89_inline
+  && (!DECL_DECLARED_INLINE_P (olddecl)
+  || !lookup_attribute ("gnu_inline",
+DECL_ATTRIBUTES (olddecl)))
+  && (!DECL_DECLARED_INLINE_P (newdecl)
+  || !lookup_attribute ("gnu_inline",
+DECL_ATTRIBUTES (newdecl))
+ return false;
+ 
merge_decls (newdecl, olddecl, newtype, oldtype);
return true;
  }
*** pushdecl (tree x)
*** 2776,2782 
  nested = true;
  x = visdecl;
}
! else
{
  bind (name, x, external_scope, /*invisible=*/true,
/*nested=*/false, locus);
--- 2794,2802 
  nested = true;
  x = visdecl;
}
! else if (TREE_CODE (x) != FUNCTION_DECL
!  || !(DECL_DECLARED_INLINE_P (x)
!   && DECL_EXTERNAL (x)))
{
  bind (name, x, external_scope, /*invisible=*/true,
/*nested=*/false, locus);
Index: gcc/testsuite/gcc.dg/torture/pr33763-1.c
===
*** gcc/testsuite/gcc.dg/torture/pr33763-1.c(revision 0)
--- gcc/testsuite/gcc.dg/torture/pr33763-1.c(revision 0)
***
*** 0 
--- 1,43 
+ /* { dg-do run } */
+ 
+ extern void abort (void);
+ 
+ extern __inline __attribute__ ((__always_inline__))
+ int foo ()
+ {
+   return 1;
+ }
+ int test1 ()
+ {
+   /* Name-lookup should find foo that returns 1.  */
+   return foo ();
+ }
+ int foo ()
+ {
+   return 0;
+ }
+ 
+ extern __inline __attribute__ ((__always_inline__))
+ int bar ()
+ {
+   return 1;
+ }
+ int bar ()
+ {
+   return 0;
+ }
+ int test2 ()
+ {
+   /* Name-lookup should find bar that returns 0.  */
+   return bar ();
+ }
+ 
+ int
+ main()
+ {
+   if (test1 () != 1)
+ abort ();
+   if (test2 () != 0)
+ abort ();
+   return 0;
+ }
Index: gcc/testsuite/gcc.dg/torture/pr33763-2.c
===
*** gcc/testsuite/gcc.dg/torture/pr33763-2.c(revision 0)
--- gcc/testsuite/gcc.dg/torture/pr33763-2.c(revision 0)
***
*** 0 
--- 1,30 
+ /* { dg-do compile 

Re: [PATCH][C] Fix PR37985

2012-01-16 Thread Richard Guenther
On Fri, 13 Jan 2012, Joseph S. Myers wrote:

> On Fri, 13 Jan 2012, Richard Guenther wrote:
> 
> > This fixes PR37985 where since 
> > http://gcc.gnu.org/ml/gcc-patches/2006-08/msg01041.html we
> > mark conversions produced by convert_to_integer with TREE_NO_WARNING.
> > This may shadow "real" stmts with no effects, thus we should
> > simply strip them again before checking for TREE_SIDE_EFFECTS.
> > 
> > Bootstrap & regtest pending on x86_64-unknown-linux-gnu.
> > 
> > Ok if that passes?
> 
> OK.

It FAILs gcc.dg/20040202-1.c (we warn about a folded memcpy).  It
looks like wrapping things in TREE_NO_WARNING NOP_EXPRs is
fragile as soon as you consider multiple warning kinds (thus, of
course the patch causing this regression is at fault).

OTOH for the regression warning on folded stmts I really wonder
why c_process_expr_stmt folds at all before emitting warnings - why
intentionally divert from the source AST here?  I'm testing
the following before giving up on this regression (which solves
the gcc.dg/20040202-1.c FAIL at least).

Richard.

2012-01-13  Richard Guenther  

PR c/37985
* c-typeck.c (emit_side_effect_warnings): Strip conversions
with TREE_NO_WARNING.
(c_process_expr_stmt): Fold the stmt after emitting warnings.

* gcc.dg/Wunused-value-4.c: New testcase.

Index: gcc/testsuite/gcc.dg/Wunused-value-4.c
===
*** gcc/testsuite/gcc.dg/Wunused-value-4.c  (revision 0)
--- gcc/testsuite/gcc.dg/Wunused-value-4.c  (revision 0)
***
*** 0 
--- 1,9 
+ /* PR c/37985 */
+ /* { dg-do compile } */
+ /* { dg-options "-Wunused-value" } */
+ 
+ unsigned char foo(unsigned char a)
+ {
+   a >> 2; /* { dg-warning "statement with no effect" } */
+   return a;
+ }
Index: gcc/c-typeck.c
===
--- gcc/c-typeck.c  (revision 183205)
+++ gcc/c-typeck.c  (working copy)
@@ -9163,6 +9163,10 @@ c_finish_bc_stmt (location_t loc, tree *
 static void
 emit_side_effect_warnings (location_t loc, tree expr)
 {
+  /* Strip conversions marked with TREE_NO_WARNING.  */
+  while (TREE_NO_WARNING (expr) && CONVERT_EXPR_P (expr))
+expr = TREE_OPERAND (expr, 0);
+
   if (expr == error_mark_node)
 ;
   else if (!TREE_SIDE_EFFECTS (expr))
@@ -9186,8 +9190,6 @@ c_process_expr_stmt (location_t loc, tre
   if (!expr)
 return NULL_TREE;
 
-  expr = c_fully_fold (expr, false, NULL);
-
   if (warn_sequence_point)
 verify_sequence_points (expr);
 
@@ -9213,6 +9215,8 @@ c_process_expr_stmt (location_t loc, tre
   || TREE_CODE (exprv) == ADDR_EXPR)
 mark_exp_read (exprv);
 
+  expr = c_fully_fold (expr, false, NULL);
+
   /* If the expression is not of a type to which we cannot assign a line
  number, wrap the thing in a no-op NOP_EXPR.  */
   if (DECL_P (expr) || CONSTANT_CLASS_P (expr))


Re: [Patch] gcc-4.7/changes.html - tone down -fcoarray=lib announcement

2012-01-16 Thread Richard Guenther
On Fri, Jan 13, 2012 at 5:52 PM, Tobias Burnus  wrote:
> Dear all,
>
> seemingly may (potential) users still do not realize that gfortran's
> multi-image coarray support is not yet usable as only the basic libcaf
> infrastructure (registering, deregistering, argument passing, syncing, start
> up/close down, error stop - and all the coindex handling routines) is
> implemented. The actual communication (pull/push coarray data, locking) does
> not yet work.
>
> Hence, although a lot of progress has been made in term of infrastructure,
> multi-images are still not usable - not even for hello world programs.
> (Unless you count "print *, this_image(),' of ', num_images; end" as a
> such.)
>
>
> I would be happy if someone could check the patch below but also the
> following pages whether it is clear that they should not yet use
> -fcoarray=lib with more than one image.
>
>
> a) Release notes (cf. patch below):
> http://gcc.gnu.org/gcc-4.7/changes.html#fortran
> b) Wiki release notes: http://gcc.gnu.org/wiki/GFortran#GCC4.7
> c) Coarrays in general: http://gcc.gnu.org/wiki/Coarray
> d) The most important page - as is describes how to compile the library
> version: http://gcc.gnu.org/wiki/CoarrayLib

Hmm, why mention it at all then?  Single-image coarrays are usable, right?

Richard.

> Tobias
>
> Index: changes.html
> ===
> RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v
> retrieving revision 1.73
> diff -u -p -r1.73 changes.html
> --- changes.html        12 Jan 2012 19:35:29 -      1.73
> +++ changes.html        13 Jan 2012 16:39:40 -
> @@ -504,7 +504,8 @@ well.
>           Additionally, preliminary support for multiple images via an
>           MPI-based http://gcc.gnu.org/wiki/CoarrayLib";>
>           coarray communication library has been added. Note:
> -          Remote coarray access is not yet possible.
> +          The library version is not yet usable as remote coarray
> +          access is not yet possible.
> 
> http://gcc.gnu.org/wiki/TS29113Status";>TS 29113:
> 


Re: Fix regression on PR46590 (slow compile with -O0)

2012-01-16 Thread Richard Guenther
On Fri, Jan 13, 2012 at 6:18 PM, Michael Matz  wrote:
> Hi,
>
> the stack-var conflict generation code needs 13 (out of 34) seconds, with
> -O0 on the second testcase of PR46590.  Most of the time is spent in
> generating the same conflicts again and again at each basic block (the
> time right now is O(nr-of-bbs * N^2) where the number of conflicts is
> O(N^2)).
>
> If we simply remember for which partitions we already generated the lower
> triangular conflict matrix we don't have to do that again, lowering the
> overall time to O(N^2).
>
> This patch does that.  Time for variable expansion now is 0.4 seconds (of
> overall 22).
>
> Regstrapping in progress on x86_64-linux, okay for trunk?

Ok.

Thanks,
Richard.

>
> Ciao,
> Michael.
>
>        * cfgexpand.c (add_scope_conflicts_1): New old_conflicts argument,
>        use it in remembering which conflicts we already created.
>        (add_scope_conflicts): Adjust call to above, (de)allocate helper
>        bitmap.
>
> Index: cfgexpand.c
> ===
> *** cfgexpand.c (revision 183155)
> --- cfgexpand.c (working copy)
> *** visit_conflict (gimple stmt ATTRIBUTE_UN
> *** 441,451 
>
>  /* Helper routine for add_scope_conflicts, calculating the active partitions
>     at the end of BB, leaving the result in WORK.  We're called to generate
> !    conflicts when FOR_CONFLICT is true, otherwise we're just tracking
> !    liveness.  */
>
>  static void
> ! add_scope_conflicts_1 (basic_block bb, bitmap work, bool for_conflict)
>  {
>    edge e;
>    edge_iterator ei;
> --- 441,452 
>
>  /* Helper routine for add_scope_conflicts, calculating the active partitions
>     at the end of BB, leaving the result in WORK.  We're called to generate
> !    conflicts when OLD_CONFLICTS is non-null, otherwise we're just tracking
> !    liveness.  If we generate conflicts then OLD_CONFLICTS stores the bits
> !    for which we generated conflicts already.  */
>
>  static void
> ! add_scope_conflicts_1 (basic_block bb, bitmap work, bitmap old_conflicts)
>  {
>    edge e;
>    edge_iterator ei;
> *** add_scope_conflicts_1 (basic_block bb, b
> *** 482,488 
>        }
>        else if (!is_gimple_debug (stmt))
>        {
> !         if (for_conflict
>              && visit == visit_op)
>            {
>              /* If this is the first real instruction in this BB we need
> --- 483,489 
>        }
>        else if (!is_gimple_debug (stmt))
>        {
> !         if (old_conflicts
>              && visit == visit_op)
>            {
>              /* If this is the first real instruction in this BB we need
> *** add_scope_conflicts_1 (basic_block bb, b
> *** 490,505 
>                 Unlike classical liveness for named objects we can't
>                 rely on seeing a def/use of the names we're interested in.
>                 There might merely be indirect loads/stores.  We'd not add any
> !                conflicts for such partitions.  */
>              bitmap_iterator bi;
>              unsigned i;
> !             EXECUTE_IF_SET_IN_BITMAP (work, 0, i, bi)
>                {
>                  unsigned j;
>                  bitmap_iterator bj;
> !                 EXECUTE_IF_SET_IN_BITMAP (work, i + 1, j, bj)
>                    add_stack_var_conflict (i, j);
>                }
>              visit = visit_conflict;
>            }
>          walk_stmt_load_store_addr_ops (stmt, work, visit, visit, visit);
> --- 491,521 
>                 Unlike classical liveness for named objects we can't
>                 rely on seeing a def/use of the names we're interested in.
>                 There might merely be indirect loads/stores.  We'd not add any
> !                conflicts for such partitions.  We know that we generated
> !                conflicts between all partitions in old_conflicts already,
> !                so we need to generate only the new ones, avoiding to
> !                repeatedly pay the O(N^2) cost for each basic block.  */
>              bitmap_iterator bi;
>              unsigned i;
> !
> !             /* First the conflicts between new and old_conflicts members.  
> */
> !             EXECUTE_IF_AND_COMPL_IN_BITMAP (work, old_conflicts, 0, i, bi)
>                {
>                  unsigned j;
>                  bitmap_iterator bj;
> !                 EXECUTE_IF_SET_IN_BITMAP (old_conflicts, 0, j, bj)
>                    add_stack_var_conflict (i, j);
>                }
> +             /* Then the conflicts between only the new members.  */
> +             EXECUTE_IF_AND_COMPL_IN_BITMAP (work, old_conflicts, 0, i, bi)
> +               {
> +                 unsigned j;
> +                 bitmap_iterator bj;
> +                 EXECUTE_IF_AND_COMPL_IN_BITMAP (work, old_conflicts, 0, j, 
> bj)
> +                   add_stack_var_conflict (i, j);
> +               }
> +             /* And remember for the next basic block.  */
> +          

Re: useless_type_conversion_p vs pointer sizes

2012-01-16 Thread Tristan Gingold

On Jan 13, 2012, at 10:59 PM, DJ Delorie wrote:

> 
>> That should not be necessary as there is a mode check below.  Do you
>> hit the issue only when the VOID_TYPE_P check is true?  In that case
>> simply delete it - it has become obsolete.
> 
> That seems to be happening, yes, but there are other checks
> that might let differing modes through...
> 
>  /* Changes in machine mode are never useless conversions unless we
> deal with aggregate types in which case we defer to later checks.  */
>  if (TYPE_MODE (inner_type) != TYPE_MODE (outer_type)
>  && !AGGREGATE_TYPE_P (inner_type))
>return false;
> 
> Later,
> 
>  else if (POINTER_TYPE_P (inner_type)
>  && POINTER_TYPE_P (outer_type))
>{
>  /* Do not lose casts to function pointer types.  */
>  if ((TREE_CODE (TREE_TYPE (outer_type)) == FUNCTION_TYPE
>  || TREE_CODE (TREE_TYPE (outer_type)) == METHOD_TYPE)
> && !(TREE_CODE (TREE_TYPE (inner_type)) == FUNCTION_TYPE
>  || TREE_CODE (TREE_TYPE (inner_type)) == METHOD_TYPE))
>   return false;
> 
>  /* We do not care for const qualification of the pointed-to types
>as const qualification has no semantic value to the middle-end.  */
> 
>  /* Otherwise pointers/references are equivalent.  */
>  return true;
>}
> 
> So two different sized pointers to aggregate types will also have a problem?

No, because pointers are not aggregate types.

> 
> I'm a little paranoid here because TPF uses different sized pointers a
> *lot* so if we can't guarantee that the rest of the logic keeps the
> conversion, I'd rather keep the explicit check.

For the record, what is TPF ?

Tristan.




Re: [PATCH] Fix PR33763

2012-01-16 Thread Jakub Jelinek
On Mon, Jan 16, 2012 at 09:35:08AM +0100, Richard Guenther wrote:
> But that's of course intended.  Attributes or redirection on the
> extern inline variant are completely meaningless.
> 
> > If you want to keep olddecl as is, then IMHO we should add a new bool
> > argument to merge_decls and if the flag is set, make sure we only ever
> > modify newdecl and not olddecl.
> 
> I don't think that is necesary nor warranted.  What legitimate use
> would break you think?

The extern inline decl gets also all the previous decl attributes
accumulated.  Asm redirection on the extern inline is meaningless.
Consider:
/* foo.h */
extern int foo (int, int) __attribute__((regparm (2))) __asm ("bar");
...
/* foo-inlines.h */
extern inline __attribute__((gnu_inline, always_inline)) void
foo (int x, int y)
{
  return something (x, y);
}
...
/* foo.c */
int
foo (int x, int y)
{
  return something (x, y);
}

You really want to have __asm ("bar") on the foo out-of-line definition,
wouldn't surprise me if this broke glibc or other packages that heavily
use asm redirection (in glibc e.g. LFS).  And the regparm attribute
is needed too.  The gnu_inline attribute isn't needed, but can be safely
copied over and ignored, the always_inline attribute and maybe artificial
attributes are the only ones that should be not copied over to the
out-of-line definition.

Jakub


Re: [Patch,testsuite]: Fix testcase that bangs long and int against void*

2012-01-16 Thread Pedro Alves
On 01/13/2012 08:21 PM, Georg-Johann Lay wrote:

> I really don't expect anyone to run test suites on any platform or target
> supported by GCC. Such an approach is completely useless because of the amount
> of time and system resources and I never proposed that.
> 
> But it appears that many of the test that are exposed to all targets are just
> dropped at the testsuite without even looking at them with respect to platform
> requirements.
> 
> The most prominent of these requirements is sizeof(int) >= 4 because the most
> PRs are reported for such platforms.
> 
> Still I think that patches that are applied to test suite should experience
> some review. Anything else will just increase annoyance and frustration of
> developers that work for platforms that are not in the center of bolide 
> hardware.
> 
> For many test cases it's already sufficient to cut down constants so that they
> fit into 16 bits, and if actually 32-bit variable is needed GCC provides magic
> ike __INT32_TYPE__.

I suggest listing these common testcase pitfalls / best practices somewhere, 
like
for example, on a gcc wiki page.  It's then easier to point people at the 
issues.

-- 
Pedro Alves


Re: [PATCH] Fix PR33763

2012-01-16 Thread Richard Guenther
On Mon, 16 Jan 2012, Jakub Jelinek wrote:

> On Mon, Jan 16, 2012 at 09:35:08AM +0100, Richard Guenther wrote:
> > But that's of course intended.  Attributes or redirection on the
> > extern inline variant are completely meaningless.
> > 
> > > If you want to keep olddecl as is, then IMHO we should add a new bool
> > > argument to merge_decls and if the flag is set, make sure we only ever
> > > modify newdecl and not olddecl.
> > 
> > I don't think that is necesary nor warranted.  What legitimate use
> > would break you think?
> 
> The extern inline decl gets also all the previous decl attributes
> accumulated.  Asm redirection on the extern inline is meaningless.
> Consider:
> /* foo.h */
> extern int foo (int, int) __attribute__((regparm (2))) __asm ("bar");
> ...
> /* foo-inlines.h */
> extern inline __attribute__((gnu_inline, always_inline)) void
> foo (int x, int y)
> {
>   return something (x, y);
> }
> ...
> /* foo.c */
> int
> foo (int x, int y)
> {
>   return something (x, y);
> }
> 
> You really want to have __asm ("bar") on the foo out-of-line definition,
> wouldn't surprise me if this broke glibc or other packages that heavily
> use asm redirection (in glibc e.g. LFS).  And the regparm attribute
> is needed too.  The gnu_inline attribute isn't needed, but can be safely
> copied over and ignored, the always_inline attribute and maybe artificial
> attributes are the only ones that should be not copied over to the
> out-of-line definition.

Ok, I suppose that requires even more adjustments of the scope/lookup
stuff for extern inlines when we see the redefinition - thus, lookup
a previous decl and merge with that instead of doing no merging.
We don't seem to have a testcase for this at least.  I'll add yours
as follows (works with 4.6, fails with my patch)

extern int foo (int, int) __asm__ ("bar");
extern inline __attribute__((gnu_inline, always_inline)) int
foo (int x, int y)
{
  return 0;
}
int
foo (int x, int y)
{
  return 0;
}
int main()
{
  return bar ();
}

Before I spend too much time on this age-old bug - Joseph, can you
agree with the proposed partial fix sofar and then with looking
through the I_SYMBOL_BINDING chain to skip the extern inline decl
to find the decl to merge with?

Thanks,
Richard.


Re: [PATCH][C] Fix PR37985

2012-01-16 Thread Richard Guenther
On Mon, 16 Jan 2012, Richard Guenther wrote:

> On Fri, 13 Jan 2012, Joseph S. Myers wrote:
> 
> > On Fri, 13 Jan 2012, Richard Guenther wrote:
> > 
> > > This fixes PR37985 where since 
> > > http://gcc.gnu.org/ml/gcc-patches/2006-08/msg01041.html we
> > > mark conversions produced by convert_to_integer with TREE_NO_WARNING.
> > > This may shadow "real" stmts with no effects, thus we should
> > > simply strip them again before checking for TREE_SIDE_EFFECTS.
> > > 
> > > Bootstrap & regtest pending on x86_64-unknown-linux-gnu.
> > > 
> > > Ok if that passes?
> > 
> > OK.
> 
> It FAILs gcc.dg/20040202-1.c (we warn about a folded memcpy).  It
> looks like wrapping things in TREE_NO_WARNING NOP_EXPRs is
> fragile as soon as you consider multiple warning kinds (thus, of
> course the patch causing this regression is at fault).
> 
> OTOH for the regression warning on folded stmts I really wonder
> why c_process_expr_stmt folds at all before emitting warnings - why
> intentionally divert from the source AST here?  I'm testing
> the following before giving up on this regression (which solves
> the gcc.dg/20040202-1.c FAIL at least).

Which works besides now FAILing gcc.dg/strncpy-fix-1.c.  We get
a "value computed is not used" warning because we are still folding
the strncpy to a memcpy because we fold all builtin calls at the very
point they are created (build_function_call_vec):

  if (name != NULL_TREE
  && !strncmp (IDENTIFIER_POINTER (name), "__builtin_", 10))
{
  if (require_constant_value)
result =
  fold_build_call_array_initializer_loc (loc, TREE_TYPE (fntype),
 function, nargs, 
argarray);
  else
result = fold_build_call_array_loc (loc, TREE_TYPE (fntype),
function, nargs, argarray);

"Fixed" by not doing that if !require_constant_value.  We'll fold
it during the c_fully_fold call anyway (and during gimplification again).

Re-testing as follows.

Richard.

2012-01-13  Richard Guenther  

PR c/37985
* c-typeck.c (emit_side_effect_warnings): Strip conversions
with TREE_NO_WARNING.
(c_process_expr_stmt): Fold the stmt after emitting warnings.
(build_function_call_vec): Do not fold calls here if we do not
require a constant value.

* gcc.dg/Wunused-value-4.c: New testcase.

Index: gcc/testsuite/gcc.dg/Wunused-value-4.c
===
*** gcc/testsuite/gcc.dg/Wunused-value-4.c  (revision 0)
--- gcc/testsuite/gcc.dg/Wunused-value-4.c  (revision 0)
***
*** 0 
--- 1,9 
+ /* PR c/37985 */
+ /* { dg-do compile } */
+ /* { dg-options "-Wunused-value" } */
+ 
+ unsigned char foo(unsigned char a)
+ {
+   a >> 2; /* { dg-warning "statement with no effect" } */
+   return a;
+ }
Index: gcc/c-typeck.c
===
*** gcc/c-typeck.c  (revision 183205)
--- gcc/c-typeck.c  (working copy)
*** build_function_call_vec (location_t loc,
*** 2826,2841 
/* Check that the arguments to the function are valid.  */
check_function_arguments (fntype, nargs, argarray);
  
!   if (name != NULL_TREE
&& !strncmp (IDENTIFIER_POINTER (name), "__builtin_", 10))
  {
!   if (require_constant_value)
!   result =
! fold_build_call_array_initializer_loc (loc, TREE_TYPE (fntype),
!function, nargs, argarray);
!   else
!   result = fold_build_call_array_loc (loc, TREE_TYPE (fntype),
!   function, nargs, argarray);
if (TREE_CODE (result) == NOP_EXPR
  && TREE_CODE (TREE_OPERAND (result, 0)) == INTEGER_CST)
STRIP_TYPE_NOPS (result);
--- 2826,2838 
/* Check that the arguments to the function are valid.  */
check_function_arguments (fntype, nargs, argarray);
  
!   if (require_constant_value
!   && name != NULL_TREE
&& !strncmp (IDENTIFIER_POINTER (name), "__builtin_", 10))
  {
!   result =
!   fold_build_call_array_initializer_loc (loc, TREE_TYPE (fntype),
!  function, nargs, argarray);
if (TREE_CODE (result) == NOP_EXPR
  && TREE_CODE (TREE_OPERAND (result, 0)) == INTEGER_CST)
STRIP_TYPE_NOPS (result);
*** c_finish_bc_stmt (location_t loc, tree *
*** 9163,9168 
--- 9160,9169 
  static void
  emit_side_effect_warnings (location_t loc, tree expr)
  {
+   /* Strip conversions marked with TREE_NO_WARNING.  */
+   while (TREE_NO_WARNING (expr) && CONVERT_EXPR_P (expr))
+ expr = TREE_OPERAND (expr, 0);
+ 
if (expr == error_mark_node)
  ;
else if (!TREE_SIDE_EFFECTS (expr))
*** c_process_expr_stmt (location_t loc, tre
*** 9186,9193 
if (!expr)
  return NULL_TREE;
  
-   expr = c_fully_fold (expr, false

Re: [PATCH] Fix PR33763

2012-01-16 Thread Richard Guenther
On Mon, 16 Jan 2012, Richard Guenther wrote:

> On Mon, 16 Jan 2012, Jakub Jelinek wrote:
> 
> > On Mon, Jan 16, 2012 at 09:35:08AM +0100, Richard Guenther wrote:
> > > But that's of course intended.  Attributes or redirection on the
> > > extern inline variant are completely meaningless.
> > > 
> > > > If you want to keep olddecl as is, then IMHO we should add a new bool
> > > > argument to merge_decls and if the flag is set, make sure we only ever
> > > > modify newdecl and not olddecl.
> > > 
> > > I don't think that is necesary nor warranted.  What legitimate use
> > > would break you think?
> > 
> > The extern inline decl gets also all the previous decl attributes
> > accumulated.  Asm redirection on the extern inline is meaningless.
> > Consider:
> > /* foo.h */
> > extern int foo (int, int) __attribute__((regparm (2))) __asm ("bar");
> > ...
> > /* foo-inlines.h */
> > extern inline __attribute__((gnu_inline, always_inline)) void
> > foo (int x, int y)
> > {
> >   return something (x, y);
> > }
> > ...
> > /* foo.c */
> > int
> > foo (int x, int y)
> > {
> >   return something (x, y);
> > }
> > 
> > You really want to have __asm ("bar") on the foo out-of-line definition,
> > wouldn't surprise me if this broke glibc or other packages that heavily
> > use asm redirection (in glibc e.g. LFS).  And the regparm attribute
> > is needed too.  The gnu_inline attribute isn't needed, but can be safely
> > copied over and ignored, the always_inline attribute and maybe artificial
> > attributes are the only ones that should be not copied over to the
> > out-of-line definition.
> 
> Ok, I suppose that requires even more adjustments of the scope/lookup
> stuff for extern inlines when we see the redefinition - thus, lookup
> a previous decl and merge with that instead of doing no merging.
> We don't seem to have a testcase for this at least.  I'll add yours
> as follows (works with 4.6, fails with my patch)
> 
> extern int foo (int, int) __asm__ ("bar");
> extern inline __attribute__((gnu_inline, always_inline)) int
> foo (int x, int y)
> {
>   return 0;
> }
> int
> foo (int x, int y)
> {
>   return 0;
> }
> int main()
> {
>   return bar ();
> }
> 
> Before I spend too much time on this age-old bug - Joseph, can you
> agree with the proposed partial fix sofar and then with looking
> through the I_SYMBOL_BINDING chain to skip the extern inline decl
> to find the decl to merge with?

The following makes all testcases collected sofar pass.

Richard.

2012-01-13  Richard Guenther  

PR c/33763
* c-decl.c (redeclared_extern_inline_fn_p): New function.
(duplicate_decls): Do not merge re-declared extern
inline function decls with their re-declaration.  Do not
merge extern inline functions with any declarations either.
(pushdecl): Do not put extern inlines into external_scope.

* gcc.dg/torture/pr33763-1.c: New testcase.
* gcc.dg/torture/pr33763-2.c: Likewise.
* gcc.dg/torture/pr33763-3.c: Likewise.
* gcc.dg/torture/pr33763-4.c: Likewise.

Index: gcc/testsuite/gcc.dg/torture/pr33763-1.c
===
*** gcc/testsuite/gcc.dg/torture/pr33763-1.c(revision 0)
--- gcc/testsuite/gcc.dg/torture/pr33763-1.c(revision 0)
***
*** 0 
--- 1,43 
+ /* { dg-do run } */
+ 
+ extern void abort (void);
+ 
+ extern __inline __attribute__ ((__always_inline__))
+ int foo ()
+ {
+   return 1;
+ }
+ int test1 ()
+ {
+   /* Name-lookup should find foo that returns 1.  */
+   return foo ();
+ }
+ int foo ()
+ {
+   return 0;
+ }
+ 
+ extern __inline __attribute__ ((__always_inline__))
+ int bar ()
+ {
+   return 1;
+ }
+ int bar ()
+ {
+   return 0;
+ }
+ int test2 ()
+ {
+   /* Name-lookup should find bar that returns 0.  */
+   return bar ();
+ }
+ 
+ int
+ main()
+ {
+   if (test1 () != 1)
+ abort ();
+   if (test2 () != 0)
+ abort ();
+   return 0;
+ }
Index: gcc/testsuite/gcc.dg/torture/pr33763-2.c
===
*** gcc/testsuite/gcc.dg/torture/pr33763-2.c(revision 0)
--- gcc/testsuite/gcc.dg/torture/pr33763-2.c(revision 0)
***
*** 0 
--- 1,30 
+ /* { dg-do compile } */
+ 
+ extern int foo (const char *, int);
+ extern int baz (const char *, int);
+ 
+ extern inline __attribute__ ((always_inline, gnu_inline)) int
+ baz (const char *x, int y)
+ {
+   return 2;
+ }
+ 
+ int
+ baz (const char *x, int y)
+ {
+   return 1;
+ }
+ 
+ int xa, xb;
+ 
+ static int
+ inl (const char *x, int y)
+ {
+   return baz (x, y);
+ }
+ 
+ int
+ foo (const char *x, int y)
+ {
+   return inl (x, y);
+ }
Index: gcc/testsuite/gcc.dg/torture/pr33763-3.c
===
*** gcc/testsuite/gcc.dg/torture/pr33763-3.c(revision 0)
--- gcc/testsuite/gcc.dg/torture/pr33763-3.c(revision 0)
***
*** 0 
--- 1,58 
+ /* { dg-do compile } */
+ 
+ typedef s

Re: Support Solaris 11/SPARC in MD_FALLBACK_FRAME_STATE_FOR (PR ada/41929)

2012-01-16 Thread Rainer Orth
Eric Botcazou  writes:

>> All EH-related tests fail with a recent upgrade on Solaris 10. Interestingly,
>> the old implementation keeps working with the upgrade.
>
> I've applied the attached patch to mainline and 4.6 branch.  It reverts back 
> to 
> the old pattern matching code in the Solaris 8+ multi-threaded case, which is 
> clearly more robust.  The rest is left unchanged.  Tested on 5 different OS 
> versions (Solaris 8, Solaris 8 Containers, Solaris 9, old Solaris 10, recent 
> Solaris 10).

Unfortunately, this version completely breaks Solaris 11.  Given that
your primary (only?) justification for this patch seems to be a 7-year
old Beta version of Solaris 10 (s10_72) nobody in his right mind should
be running right now, I suggest simply reverting this patch.

Rainer

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


Re: [PATCH][C] Fix PR37985

2012-01-16 Thread Richard Guenther
On Mon, 16 Jan 2012, Richard Guenther wrote:

> On Mon, 16 Jan 2012, Richard Guenther wrote:
> 
> > On Fri, 13 Jan 2012, Joseph S. Myers wrote:
> > 
> > > On Fri, 13 Jan 2012, Richard Guenther wrote:
> > > 
> > > > This fixes PR37985 where since 
> > > > http://gcc.gnu.org/ml/gcc-patches/2006-08/msg01041.html we
> > > > mark conversions produced by convert_to_integer with TREE_NO_WARNING.
> > > > This may shadow "real" stmts with no effects, thus we should
> > > > simply strip them again before checking for TREE_SIDE_EFFECTS.
> > > > 
> > > > Bootstrap & regtest pending on x86_64-unknown-linux-gnu.
> > > > 
> > > > Ok if that passes?
> > > 
> > > OK.
> > 
> > It FAILs gcc.dg/20040202-1.c (we warn about a folded memcpy).  It
> > looks like wrapping things in TREE_NO_WARNING NOP_EXPRs is
> > fragile as soon as you consider multiple warning kinds (thus, of
> > course the patch causing this regression is at fault).
> > 
> > OTOH for the regression warning on folded stmts I really wonder
> > why c_process_expr_stmt folds at all before emitting warnings - why
> > intentionally divert from the source AST here?  I'm testing
> > the following before giving up on this regression (which solves
> > the gcc.dg/20040202-1.c FAIL at least).
> 
> Which works besides now FAILing gcc.dg/strncpy-fix-1.c.  We get
> a "value computed is not used" warning because we are still folding
> the strncpy to a memcpy because we fold all builtin calls at the very
> point they are created (build_function_call_vec):
> 
>   if (name != NULL_TREE
>   && !strncmp (IDENTIFIER_POINTER (name), "__builtin_", 10))
> {
>   if (require_constant_value)
> result =
>   fold_build_call_array_initializer_loc (loc, TREE_TYPE (fntype),
>  function, nargs, 
> argarray);
>   else
> result = fold_build_call_array_loc (loc, TREE_TYPE (fntype),
> function, nargs, argarray);
> 
> "Fixed" by not doing that if !require_constant_value.  We'll fold
> it during the c_fully_fold call anyway (and during gimplification again).
> 
> Re-testing as follows.

Which does not work either - we seem to rely on that early folding
at least for the type-generic math stuff (gcc.dg/c99-tgmath-*.c).

I'm dropping all these patches.  There doesn't seem to be a good
way to make everything well-behaved with the patch causing the
regression installed.

Richard.


[PATCH] Fix s390 --with-mode=esa bootstrap (PR bootstrap/51860)

2012-01-16 Thread Jakub Jelinek
Hi!

We get a -fcompare-debug failure on s390 -mesa on c-common.c, the
problem is in s390_chunkify_start which behaves differently when
a call is followed by NOTE_INSN_CALL_ARG_LOCATION.
We skip the calls that are followed by that note in order to
avoid inserting jumps and literal pools in between the call and
following note, but while the call has the same INSN_ADDRESS
between -g and -g0, the following note has different INSN_ADDRESS,
which means that with -g0 we don't emit the jump + litpool after
the call, because the address hasn't reached the limit yet (and insert
it after the next insn), but with -g where we ignore the call, when
processing NOTE_INSN_CALL_ARG_LOCATION its INSN_ADDRESS reached the
limit already and thus we emit the jump + litpool after the note,
i.e. before the following real insn.

Fixed thusly, bootstrapped on s390-linux --with-mode=esa.  Ok for trunk?

2012-01-16  Jakub Jelinek  

PR bootstrap/51860
* config/s390/s390.c (s390_chunkify_start): Don't skip
call insns followed by NOTE_INSN_CALL_ARG_LOCATION note.  Skip
NOTE_INSN_VAR_LOCATION and NOTE_INSN_CALL_ARG_LOCATION notes.
If insn is followed by NOTE_INSN_VAR_LOCATION or
NOTE_INSN_CALL_ARG_LOCATION notes, insert jump after all those notes.
Don't use location of note insns.

--- gcc/config/s390/s390.c.jj   2011-12-08 16:36:51.782961666 +0100
+++ gcc/config/s390/s390.c  2012-01-16 11:49:31.457594861 +0100
@@ -6608,15 +6608,6 @@ s390_chunkify_start (void)
  pending_ltrel = pool_ref;
}
}
- /* Make sure we do not split between a call and its
-corresponding CALL_ARG_LOCATION note.  */
- if (CALL_P (insn))
-   {
- rtx next = NEXT_INSN (insn);
- if (next && NOTE_P (next)
- && NOTE_KIND (next) == NOTE_INSN_CALL_ARG_LOCATION)
-   continue;
-   }
}
 
   if (GET_CODE (insn) == JUMP_INSN || GET_CODE (insn) == CODE_LABEL)
@@ -6627,8 +6618,18 @@ s390_chunkify_start (void)
  gcc_assert (!pending_ltrel);
}
 
-  if (NOTE_P (insn) && NOTE_KIND (insn) == NOTE_INSN_SWITCH_TEXT_SECTIONS)
-   section_switch_p = true;
+  if (NOTE_P (insn))
+   switch (NOTE_KIND (insn))
+ {
+ case NOTE_INSN_SWITCH_TEXT_SECTIONS:
+   section_switch_p = true;
+   break;
+ case NOTE_INSN_VAR_LOCATION:
+ case NOTE_INSN_CALL_ARG_LOCATION:
+   continue;
+ default:
+   break;
+ }
 
   if (!curr_pool
  || INSN_ADDRESSES_SIZE () <= (size_t) INSN_UID (insn)
@@ -6674,7 +6675,7 @@ s390_chunkify_start (void)
   || curr_pool->size > S390_POOL_CHUNK_MAX
   || section_switch_p)
{
-  rtx label, jump, barrier;
+ rtx label, jump, barrier, next, prev;
 
  if (!section_switch_p)
{
@@ -6684,9 +6685,19 @@ s390_chunkify_start (void)
  if (get_attr_length (insn) == 0)
continue;
  /* Don't separate LTREL_BASE from the corresponding
-LTREL_OFFSET load.  */
+LTREL_OFFSET load.  */
  if (pending_ltrel)
continue;
+ next = insn;
+ do
+   {
+ insn = next;
+ next = NEXT_INSN (insn);
+   }
+ while (next
+&& NOTE_P (next)
+&& (NOTE_KIND (next) == NOTE_INSN_VAR_LOCATION
+|| NOTE_KIND (next) == 
NOTE_INSN_CALL_ARG_LOCATION));
}
  else
{
@@ -6699,7 +6710,14 @@ s390_chunkify_start (void)
}
 
  label = gen_label_rtx ();
- jump = emit_jump_insn_after (gen_jump (label), insn);
+ prev = insn;
+ if (prev && NOTE_P (prev))
+   prev = prev_nonnote_insn (prev);
+ if (prev)
+   jump = emit_jump_insn_after_setloc (gen_jump (label), insn,
+   INSN_LOCATOR (prev));
+ else
+   jump = emit_jump_insn_after_noloc (gen_jump (label), insn);
  barrier = emit_barrier_after (jump);
  insn = emit_label_after (label, barrier);
  JUMP_LABEL (jump) = label;

Jakub


Re: [PATCH] Fix s390 --with-mode=esa bootstrap (PR bootstrap/51860)

2012-01-16 Thread Andreas Krebbel
On 01/16/2012 02:38 PM, Jakub Jelinek wrote:
> Fixed thusly, bootstrapped on s390-linux --with-mode=esa.  Ok for trunk?
> 
> 2012-01-16  Jakub Jelinek  
> 
>   PR bootstrap/51860
>   * config/s390/s390.c (s390_chunkify_start): Don't skip
>   call insns followed by NOTE_INSN_CALL_ARG_LOCATION note.  Skip
>   NOTE_INSN_VAR_LOCATION and NOTE_INSN_CALL_ARG_LOCATION notes.
>   If insn is followed by NOTE_INSN_VAR_LOCATION or
>   NOTE_INSN_CALL_ARG_LOCATION notes, insert jump after all those notes.
>   Don't use location of note insns.

Ok. Thanks!

-Andreas-



Re: RFC: allowing fwprop to propagate subregs

2012-01-16 Thread Ulrich Weigand
Richard Kenner wrote:

> > > The problem appears to be that an RTX expression like
> > >
> > > (minus:QI (subreg:QI (reg:SI 64 [ a ]) 0)
> > >   (subreg:QI (reg:SI 66 [ b ]) 0))
> > >
> > > seems to be considered non-canonical by combine, and is instead
> > > transformed into
> > >
> > > (subreg:QI (minus:SI (reg:SI 64 [ a ])
> > >  (reg:SI 66 [ b ])) 0)
> > > On the one hand, this seems odd, as SUBREGs with a non-trivial
> > > expression inside will usually not match any insn pattern.  On
> > > the other hand, I guess this might still be useful behaviour
> > > for combine on platforms that support only word arithmetic,
> > > when the SUBREG might be considered a "split" point. 
> 
> No, I think the idea was that the outer SUBREG would be moved to the LHS
> of the assignment to make a "paradoxical SUBREG".  Except, as you point
> out, there doesn't seem to be an advantage of doing this for arithmetic
> unless you only have it in SImode (which it could, of course, check).

Right, I was mistaken about the "split" point case; this is done only
for SUBREG (MEM).  But you're correct that there is a special optimization
in simplify_set that will move the outer SUBREG to the LHS:

  /* If we have (set x (subreg:m1 (op:m2 ...) 0)) with OP being some operation,
 and X being a REG or (subreg (reg)), we may be able to convert this to
 (set (subreg:m2 x) (op)).

However, it would appear that this particular location is in fact the only
place where (subreg (op ...)) is handled; I don't see any other place where
this type of pattern would provide any benefit.

Maybe the best solution would be to remove the SUBREG case from the generic
apply_distributive_law subroutine, and instead add a special check for the
distributed subreg case right at the above place in simplify_set; i.e. to
perform the inverse distribution only if it is already guaranteed that we
will also be able to move the subreg to the LHS ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  ulrich.weig...@de.ibm.com



PR other/51165: add new adress_escapes predicate

2012-01-16 Thread Aldy Hernandez
As discussed in the PR, the problem here is that we are using 
ptr_deref_may_alias_global_p() to determine if a dereferenced address 
escapes, whereas we were previously using the now non existent 
is_call_clobbered.  The function ptr_deref_may_alias_global_p() does not 
understand SSA_NAMEs, whereas is_call_clobbered did.


Richi suggested using may_be_aliased() for DECLs.

The patch below abstracts an address_escapes_p() predicate for more 
generic use into the aliasing code.  Using this instead of 
ptr_deref_may_alias_global_p() fixes all 4 TM memory optimization 
regressions.  TM logging is now back in business.


Is this what you had in mind?  OK for trunk?
PR other/51165
* tree-ssa-alias.h: (address_escapes_p): Declare it.
* tree-ssa-alias.c (address_escapes_p): New.
* trans-mem.c (thread_private_new_memory): Use it.
(requires_barrier): Use it.

Index: testsuite/gcc.dg/tm/memopt-3.c
===
--- testsuite/gcc.dg/tm/memopt-3.c  (revision 183072)
+++ testsuite/gcc.dg/tm/memopt-3.c  (working copy)
@@ -16,5 +16,5 @@ int f()
   return lala.x[0];
 }
 
-/* { dg-final { scan-tree-dump-times "logging: lala.x\\\[i_1\\\]" 1 "tmmark" { 
xfail *-*-* }  } } */
+/* { dg-final { scan-tree-dump-times "logging: lala.x\\\[i_1\\\]" 1 "tmmark" } 
} */
 /* { dg-final { cleanup-tree-dump "tmmark" } } */
Index: testsuite/gcc.dg/tm/memopt-5.c
===
--- testsuite/gcc.dg/tm/memopt-5.c  (revision 183072)
+++ testsuite/gcc.dg/tm/memopt-5.c  (working copy)
@@ -19,5 +19,5 @@ int f()
   return lala.x[i];
 }
 
-/* { dg-final { scan-tree-dump-times "ITM_LU\[0-9\] \\\(&lala.x\\\[55\\\]" 1 
"tmedge" { xfail *-*-* } } } */
+/* { dg-final { scan-tree-dump-times "ITM_LU\[0-9\] \\\(&lala.x\\\[55\\\]" 1 
"tmedge" } } */
 /* { dg-final { cleanup-tree-dump "tmedge" } } */
Index: testsuite/gcc.dg/tm/memopt-7.c
===
--- testsuite/gcc.dg/tm/memopt-7.c  (revision 183072)
+++ testsuite/gcc.dg/tm/memopt-7.c  (working copy)
@@ -17,6 +17,6 @@ int f()
   return lala.x[asdf];
 }
 
-/* { dg-final { scan-tree-dump-times "tm_save.\[0-9_\]+ = lala" 1 "tmedge" { 
xfail *-*-* } } } */
-/* { dg-final { scan-tree-dump-times "lala = tm_save" 1 "tmedge" { xfail *-*-* 
} } } */
+/* { dg-final { scan-tree-dump-times "tm_save.\[0-9_\]+ = lala" 1 "tmedge" } } 
*/
+/* { dg-final { scan-tree-dump-times "lala = tm_save" 1 "tmedge" } } */
 /* { dg-final { cleanup-tree-dump "tmedge" } } */
Index: testsuite/gcc.dg/tm/memopt-4.c
===
--- testsuite/gcc.dg/tm/memopt-4.c  (revision 183072)
+++ testsuite/gcc.dg/tm/memopt-4.c  (working copy)
@@ -19,6 +19,6 @@ int f()
   return lala.x[i];
 }
 
-/* { dg-final { scan-tree-dump-times "tm_save.\[0-9_\]+ = lala.x\\\[55\\\]" 1 
"tmedge" { xfail *-*-* } } } */
-/* { dg-final { scan-tree-dump-times "lala.x\\\[55\\\] = tm_save" 1 "tmedge" { 
xfail *-*-* } } } */
+/* { dg-final { scan-tree-dump-times "tm_save.\[0-9_\]+ = lala.x\\\[55\\\]" 1 
"tmedge" } } */
+/* { dg-final { scan-tree-dump-times "lala.x\\\[55\\\] = tm_save" 1 "tmedge" } 
} */
 /* { dg-final { cleanup-tree-dump "tmedge" } } */
Index: tree-ssa-alias.c
===
--- tree-ssa-alias.c(revision 183072)
+++ tree-ssa-alias.c(working copy)
@@ -332,6 +332,20 @@ ptr_deref_may_alias_ref_p_1 (tree ptr, a
   return true;
 }
 
+/* Returns true if an address escapes the current function.  */
+bool
+address_escapes_p (tree x)
+{
+  x = get_base_address (x);
+  if (TREE_CODE (x) == SSA_NAME)
+return ptr_deref_may_alias_global_p (x);
+  if (TREE_CODE (x) == MEM_REF)
+return ptr_deref_may_alias_global_p (TREE_OPERAND (x, 0));
+  if (DECL_P (x))
+return may_be_aliased (x);
+  return false;
+}
+
 
 /* Dump alias information on FILE.  */
 
Index: tree-ssa-alias.h
===
--- tree-ssa-alias.h(revision 183072)
+++ tree-ssa-alias.h(working copy)
@@ -99,6 +99,7 @@ extern tree ao_ref_base (ao_ref *);
 extern alias_set_type ao_ref_alias_set (ao_ref *);
 extern bool ptr_deref_may_alias_global_p (tree);
 extern bool ptr_derefs_may_alias_p (tree, tree);
+extern bool address_escapes_p (tree);
 extern bool refs_may_alias_p (tree, tree);
 extern bool refs_may_alias_p_1 (ao_ref *, ao_ref *, bool);
 extern bool refs_anti_dependent_p (tree, tree);
Index: trans-mem.c
===
--- trans-mem.c (revision 183072)
+++ trans-mem.c (working copy)
@@ -1347,7 +1347,7 @@ thread_private_new_memory (basic_block e
   /* Search DEF chain to find the original definition of this address.  */
   do
 {
-  if (ptr_deref_may_alias_global_p (x))
+  if (address_escapes_p (x))
{
  /* Address 

Re: RFC: allowing fwprop to propagate subregs

2012-01-16 Thread Richard Kenner
> Maybe the best solution would be to remove the SUBREG case from the generic
> apply_distributive_law subroutine, and instead add a special check for the
> distributed subreg case right at the above place in simplify_set; i.e. to
> perform the inverse distribution only if it is already guaranteed that we
> will also be able to move the subreg to the LHS ...

That could indeed work.


Re: PR other/51165: add new adress_escapes predicate

2012-01-16 Thread Richard Guenther
On Mon, Jan 16, 2012 at 3:29 PM, Aldy Hernandez  wrote:
> As discussed in the PR, the problem here is that we are using
> ptr_deref_may_alias_global_p() to determine if a dereferenced address
> escapes, whereas we were previously using the now non existent
> is_call_clobbered.  The function ptr_deref_may_alias_global_p() does not
> understand SSA_NAMEs, whereas is_call_clobbered did.
>
> Richi suggested using may_be_aliased() for DECLs.
>
> The patch below abstracts an address_escapes_p() predicate for more generic
> use into the aliasing code.  Using this instead of
> ptr_deref_may_alias_global_p() fixes all 4 TM memory optimization
> regressions.  TM logging is now back in business.
>
> Is this what you had in mind?  OK for trunk?

Not really - you handle both ptr and *ptr in the same predicate and
call both "address escaped".  What I suggested was sth like

/* Return true, if the memory access X may alias with a global variable.  */

bool
access_may_refer_to_global_p (tree x)
{
  x = get_base_address (x);
  if (DECL_P (x))
return is_global_var (x);
  else if (TREE_CODE (x) == MEM_REF
 || TREE_CODE (x) == TARGET_MEM_REF)
return ptr_deref_may_alias_global_p (TREE_OPERAND (x, 0));
  return true;
}

Richard.


Re: [PATCH] PR debug/45682 - wrong struct DIE nesting with -fdebug-types-section

2012-01-16 Thread Dodji Seketeli
Cary Coutant  writes:

> gcc/testsuite/ChangeLog:
>
>   PR debug/45682
>   * g++.dg/debug/dwarf2/nested-3.C: New test.

As per this comment from Jakub in another subthread:

Just a testcase comment, I bet this will surely fail on Darwin
or other targets that aren't capable of merging string sections.
So, you should add -fno-merge-debug-strings to dg-options
and adjust the example and regexp for that, that way
it will be the same on all targets.

I have updated the test case in your patch as below.  Please note that
lines of the patch in your mail were wrapped so I had to edit the patch
by hand to have it apply.

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

Thanks.

gcc/ChangeLog:

PR debug/45682
* dwarf2out.c (copy_declaration_context): Return ref to parent
of declaration DIE, if necessary.  Update caller.
(remove_child_or_replace_with_skeleton): Add new parameter; update
caller.  Place skeleton DIE under parent DIE of original declaration.

gcc/testsuite/ChangeLog:

PR debug/45682
* g++.dg/debug/dwarf2/nested-3.C: New test.

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index f9f4295..4f6bcad 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -3302,11 +3302,12 @@ static int should_move_die_to_comdat (dw_die_ref);
 static dw_die_ref clone_as_declaration (dw_die_ref);
 static dw_die_ref clone_die (dw_die_ref);
 static dw_die_ref clone_tree (dw_die_ref);
-static void copy_declaration_context (dw_die_ref, dw_die_ref);
+static dw_die_ref copy_declaration_context (dw_die_ref, dw_die_ref);
 static void generate_skeleton_ancestor_tree (skeleton_chain_node *);
 static void generate_skeleton_bottom_up (skeleton_chain_node *);
 static dw_die_ref generate_skeleton (dw_die_ref);
 static dw_die_ref remove_child_or_replace_with_skeleton (dw_die_ref,
+ dw_die_ref,
  dw_die_ref);
 static void break_out_comdat_types (dw_die_ref);
 static dw_die_ref copy_ancestor_tree (dw_die_ref, dw_die_ref, htab_t);
@@ -7075,11 +7076,12 @@ clone_as_declaration (dw_die_ref die)
AT_specification attribute, it also includes attributes and children
attached to the specification.  */
 
-static void
+static dw_die_ref
 copy_declaration_context (dw_die_ref unit, dw_die_ref die)
 {
   dw_die_ref decl;
   dw_die_ref new_decl;
+  dw_die_ref new_parent = NULL;
 
   decl = get_AT_ref (die, DW_AT_specification);
   if (decl == NULL)
@@ -7090,6 +7092,10 @@ copy_declaration_context (dw_die_ref unit, dw_die_ref 
die)
   dw_die_ref c;
   dw_attr_ref a;
 
+  /* The original DIE will be changed to a declaration, and must
+ be moved to be a child of the original declaration DIE.  */
+  new_parent = decl->die_parent;
+
   /* Copy the type node pointer from the new DIE to the original
  declaration DIE so we can forward references later.  */
   decl->die_id.die_type_node = die->die_id.die_type_node;
@@ -7118,6 +7124,8 @@ copy_declaration_context (dw_die_ref unit, dw_die_ref die)
   add_AT_specification (die, new_decl);
 }
 }
+
+  return new_parent;
 }
 
 /* Generate the skeleton ancestor tree for the given NODE, then clone
@@ -7201,7 +7209,7 @@ generate_skeleton (dw_die_ref die)
   return node.new_die;
 }
 
-/* Remove the DIE from its parent, possibly replacing it with a cloned
+/* Remove the CHILD DIE from its parent, possibly replacing it with a cloned
declaration.  The original DIE will be moved to a new compile unit
so that existing references to it follow it to the new location.  If
any of the original DIE's descendants is a declaration, we need to
@@ -7209,7 +7217,8 @@ generate_skeleton (dw_die_ref die)
declarations back into the skeleton tree.  */
 
 static dw_die_ref
-remove_child_or_replace_with_skeleton (dw_die_ref child, dw_die_ref prev)
+remove_child_or_replace_with_skeleton (dw_die_ref child, dw_die_ref prev,
+  dw_die_ref new_parent)
 {
   dw_die_ref skeleton;
 
@@ -7219,7 +7228,16 @@ remove_child_or_replace_with_skeleton (dw_die_ref child, 
dw_die_ref prev)
   else
 {
   skeleton->die_id.die_type_node = child->die_id.die_type_node;
-  replace_child (child, skeleton, prev);
+
+  /* If the original DIE was a specification, we need to put
+ the skeleton under the parent DIE of the declaration.  */
+  if (new_parent != NULL)
+   {
+ remove_child_with_prev (child, prev);
+ add_child_die (new_parent, skeleton);
+   }
+  else
+   replace_child (child, skeleton, prev);
 }
 
   return skeleton;
@@ -7247,7 +7265,7 @@ break_out_comdat_types (dw_die_ref die)
 next = (c == first ? NULL : c->die_sib);
 if (should_move_die_to_comdat (c))
   {
-dw_die_ref replacement;
+dw_die_ref replacement, new_parent;
comdat_type_node_ref type_node;
 
 

Re: [PATCH, PR 50444] Decrease MEM_REF TYPE_ALIGN in build_ref_for_offset

2012-01-16 Thread Richard Guenther
On Thu, 12 Jan 2012, Martin Jambor wrote:

> Hi,
> 
> On Thu, Jan 12, 2012 at 03:23:31PM +0100, Richard Guenther wrote:
> > On Thu, 12 Jan 2012, Martin Jambor wrote:
> > 
> > > Hi,
> > > 
> > > I tend to believe that this is the SRA part of a fix for PR 50444 (and
> > > possibly some strict alignment SRA-related bugs too.  What it does is
> > > that it decreases the alignment of the built MEM_REF type if it seems
> > > necessary.  That is in cases when the alignment of the type as it
> > > arrived in the parameter is larger than the alignment of the base we
> > > are building the MEM_REF on top of or the MEM_REF we are replacing or
> > > when it is larger than the biggest power of two that divides the
> > > offset we are adding, if it is non zero).
> > > 
> > > This patch alone fixes the testcase on i686, on x86_64 the testcase
> > > stops segfaulting but the final comparison does not go well and the
> > > testcase returns non-zero exit code.  However, I belive that is most
> > > probably an expansion problem, rather than SRA's.  Perhaps it should
> > > be also noted that if I revert SRA's build_ref_for_model to what it
> > > was in revision 164280 and SRA creates only a MEM_REF rather than a
> > > COMPONENT_REF on top of a MEM_REF which it does now, the assignment
> > > expansion takes the "optab_handler (movmisalign_optab, mode)" route
> > > and the testcase is compiled well, with both the segfault gone and
> > > comparison yielding the correct result.  I plan to have a look at what
> > > goes on in expansion with the current build_ref_for_model shortly but
> > > thought I'd post this for review and comments before that.
> > > 
> > > A similar patch has passed bootstrap and testsuite on x86_64-linux,
> > > this exact one is undergoing the same as I'm writing this.  Is it the
> > > good direction, should I commit the patch (to trunk and the 4.6
> > > branch) if it passes?
> > 
> > I don't think this is a suitable place to discover the alignment
> > for the access.  In fact what we should do is use the same alignment
> > that was used for the access we replicate/decompose (or is the
> > 'base' argument to build_ref_for_offset always the original access?)
> 
> No, it often it is not.  And I am not sure what that same alignment
> above is.  Let me explain the crux of the problem with the testcase.
> The data structures look like this:
> 
>   typedef struct {
>   uint32_t v[4];
>   } a4x32;
>   
>   typedef struct {
>   __m128i m;
> } a1xm128i;
> 
>   typedef struct  {
>   a1xm128i key;
>   a4x32 c;
>   size_t elem;
>   a4x32 v;
>   } Engine;
> 
> And we have a local aggregate of type a4x32 but which is accessed as
> __m128i, therefore its scalar replacement has type __m128i.  Any store
> of that type requires 128bit alignment.

I don't see that a4x32 accessed as __m128i - that is what SRA
generates but not what is present in the IL before SRA.

> The problem is that the original a4x32 aggregate is stored into the v
> field of a structure of type Engine which is pointed to by a pointer
> parameter.  Field v has offset 40 and therefore any store to it in the
> __m128i type without fiddling with its alignment is illegal (the
> Engine structure itself is 128bit aligned because of field key).
> 
> Specifically, before SRA it all looks like this.  D.4781 and D.4792
> are local a4x32 structures, e points to a struct Engine):
> 
>   MEM[(struct  *)&D.4792].m = vector_ssa_name;
>   D.4781 = D.4792;
>   e_1(D)->v = D.4781;
> 
> If I want to replace the local aggregates D.4781 and D.4792 with
> vectors and make them go away completely (and I do believe people
> would complain if I did not, especially if they are used in more
> computations elsewhere in the function), I have to store the vecor to
> the unaligned position.
> 
> If we want to make D.4781 disappear completely, there is no original
> access we are replicating/decomposing and we have to take into account
> the offset 40, which however is a property of this particular memory
> access and nothing else.  Therefore I thought this was the proper
> place to deal with it.

I see it that already the

  MEM[(char * {ref-all})&c4x32] = MEM[(char * {ref-all})&c1x128];
  D.1760 = c4x32;

to

  MEM[(struct  *)&D.1760].m = c4x32$m_15;

replacement SRA performs is bogus.  D.1760 is a4x32 but SRA
generates a c1x128 store into it.

Richard.

> > 
> > Also ...
> > 
> > > Thanks,
> > > 
> > > Martin
> > > 
> > > 
> > > 2012-01-12  Martin Jambor  
> > > 
> > >   PR tree-optimization/50444
> > >   * tree-sra.c (build_ref_for_offset): Decrease the alignment of the
> > >   type of the created MEM_REF if necessary.
> > > 
> > > Index: src/gcc/tree-sra.c
> > > ===
> > > --- src.orig/gcc/tree-sra.c
> > > +++ src/gcc/tree-sra.c
> > > @@ -1458,9 +1458,10 @@ build_ref_for_offset (location_t loc, tr
> > > tree exp_type, gimple_stmt_iterator *gsi,
> > > bool insert_a

Re: PR other/51165: add new adress_escapes predicate

2012-01-16 Thread Aldy Hernandez



Not really - you handle both ptr and *ptr in the same predicate and
call both "address escaped".  What I suggested was sth like


I think I confused myself and you by asking the wrong question in the 
first place.


Actually, what I want is to handle VAR_DECL correctly, and your original 
suggestion of using may_be_aliased() fits the bill.  The other calls to 
ptr_deref_may_alias_global_p() were fine because we have an SSA_NAME.


We're now down to a one-liner :).

How about this?  All TM memory optimization tests fixed, and no regressions.
PR other/51165
* trans-mem.c (requires_barrier): Call may_be_aliased.
testsuite/
PR other/51165
* gcc.dg/tm/memopt-3.c: Remove xfail.
* gcc.dg/tm/memopt-4.c: Remove xfail.
* gcc.dg/tm/memopt-5.c: Remove xfail.
* gcc.dg/tm/memopt-7.c: Remove xfail.

Index: testsuite/gcc.dg/tm/memopt-3.c
===
--- testsuite/gcc.dg/tm/memopt-3.c  (revision 183072)
+++ testsuite/gcc.dg/tm/memopt-3.c  (working copy)
@@ -16,5 +16,5 @@ int f()
   return lala.x[0];
 }
 
-/* { dg-final { scan-tree-dump-times "logging: lala.x\\\[i_1\\\]" 1 "tmmark" { 
xfail *-*-* }  } } */
+/* { dg-final { scan-tree-dump-times "logging: lala.x\\\[i_1\\\]" 1 "tmmark" } 
} */
 /* { dg-final { cleanup-tree-dump "tmmark" } } */
Index: testsuite/gcc.dg/tm/memopt-5.c
===
--- testsuite/gcc.dg/tm/memopt-5.c  (revision 183072)
+++ testsuite/gcc.dg/tm/memopt-5.c  (working copy)
@@ -19,5 +19,5 @@ int f()
   return lala.x[i];
 }
 
-/* { dg-final { scan-tree-dump-times "ITM_LU\[0-9\] \\\(&lala.x\\\[55\\\]" 1 
"tmedge" { xfail *-*-* } } } */
+/* { dg-final { scan-tree-dump-times "ITM_LU\[0-9\] \\\(&lala.x\\\[55\\\]" 1 
"tmedge" } } */
 /* { dg-final { cleanup-tree-dump "tmedge" } } */
Index: testsuite/gcc.dg/tm/memopt-7.c
===
--- testsuite/gcc.dg/tm/memopt-7.c  (revision 183072)
+++ testsuite/gcc.dg/tm/memopt-7.c  (working copy)
@@ -17,6 +17,6 @@ int f()
   return lala.x[asdf];
 }
 
-/* { dg-final { scan-tree-dump-times "tm_save.\[0-9_\]+ = lala" 1 "tmedge" { 
xfail *-*-* } } } */
-/* { dg-final { scan-tree-dump-times "lala = tm_save" 1 "tmedge" { xfail *-*-* 
} } } */
+/* { dg-final { scan-tree-dump-times "tm_save.\[0-9_\]+ = lala" 1 "tmedge" } } 
*/
+/* { dg-final { scan-tree-dump-times "lala = tm_save" 1 "tmedge" } } */
 /* { dg-final { cleanup-tree-dump "tmedge" } } */
Index: testsuite/gcc.dg/tm/memopt-4.c
===
--- testsuite/gcc.dg/tm/memopt-4.c  (revision 183072)
+++ testsuite/gcc.dg/tm/memopt-4.c  (working copy)
@@ -19,6 +19,6 @@ int f()
   return lala.x[i];
 }
 
-/* { dg-final { scan-tree-dump-times "tm_save.\[0-9_\]+ = lala.x\\\[55\\\]" 1 
"tmedge" { xfail *-*-* } } } */
-/* { dg-final { scan-tree-dump-times "lala.x\\\[55\\\] = tm_save" 1 "tmedge" { 
xfail *-*-* } } } */
+/* { dg-final { scan-tree-dump-times "tm_save.\[0-9_\]+ = lala.x\\\[55\\\]" 1 
"tmedge" } } */
+/* { dg-final { scan-tree-dump-times "lala.x\\\[55\\\] = tm_save" 1 "tmedge" } 
} */
 /* { dg-final { cleanup-tree-dump "tmedge" } } */
Index: trans-mem.c
===
--- trans-mem.c (revision 183072)
+++ trans-mem.c (working copy)
@@ -1498,7 +1498,7 @@ requires_barrier (basic_block entry_bloc
 lower_sequence_tm altogether.  */
  needs_to_live_in_memory (x)
  /* X escapes.  */
- || ptr_deref_may_alias_global_p (x))
+ || may_be_aliased (x))
return true;
   else
{


Re: [libitm, build] Clear hardware capabilities on libitm.so with Sun ld

2012-01-16 Thread Rainer Orth
Richard Henderson  writes:

> On 11/21/2011 09:23 AM, Rainer Orth wrote:
>> Richard Henderson  writes:
>> 
>>> This is only ok if the compiler and library are build with default options.
>>> If you use --with-arch=corei7-avx then we may well use AVX insns all through
>>> the library, not just in the one interface that will only be used if the 
>>> user of the library is using avx.
>>>
>>> Can you auto-foo this based on CC+CFLAGS?  E.g.  compile-time tests for the
>>> various __SSE__ / __AVX__ macros?
>> 
>> Probably, but it occured to me that it might be easier to just apply the
>> mapfile to x86_avx.o unconditionally before linking libitm.la.
>
> Possibly.  Though you'd want to do the same thing for x86_sse.o too.
> Again, that file is only used if the main program uses SSE.

The ld -r route for x86_avx.o has failed completely due to several
libtool bugs, so I'm back to your suggestion.  I didn't check for
__SSE__, though: Solaris 10 is the first release where both as and ld
have hwcap support, and it requires SSE-capable hardware to run.

The following patch has been bootstrapped without regressions on
i386-pc-solaris2.11 with as/ld, gas/ld, and gas/gld and fixes the
hwcap-related execution failures in the first case.  Besides, I've
configured libitm with CFLAGS='-g -O2 -mavx' and verified that
LDFLAGS_HWCAP is cleared/not applied in this case.

I've kept the LIBITM_CHECK_LINKER_HWCAP test and the __AVX__ check
separate since the former is generic (with the exception of the mapfile
name), while the latter is strictly libitm-specific.

Ok for mainline?

Rainer


2011-11-18  Rainer Orth  

* clearcap.map: New file.
* acinclude.m4 (LIBITM_CHECK_LINKER_HWCAP): New test.
* configure.ac: Call it.
Clear HWCAP_LDFLAGS if defaulting to -mavx.
* Makefile.am (AM_LDFLAGS): Add $(HWCAP_LDFLAGS)
* configure: Regenerate.
* Makefile.in: Regenerate.
* testsuite/Makefile.in: Regenerate.

# HG changeset patch
# Parent 645b88e3e02144a637127f3a7c4842ef8afb2bcb
Clear hardware capabilities on libitm.so with Sun ld

diff --git a/libitm/Makefile.am b/libitm/Makefile.am
--- a/libitm/Makefile.am
+++ b/libitm/Makefile.am
@@ -21,7 +21,7 @@ AM_CFLAGS = $(XCFLAGS)
 AM_CXXFLAGS = $(XCFLAGS) -std=gnu++0x -funwind-tables -fno-exceptions \
 	-fno-rtti $(abi_version)
 AM_CCASFLAGS = $(XCFLAGS)
-AM_LDFLAGS = $(XLDFLAGS) $(SECTION_LDFLAGS) $(OPT_LDFLAGS)
+AM_LDFLAGS = $(XLDFLAGS) $(SECTION_LDFLAGS) $(OPT_LDFLAGS) $(HWCAP_LDFLAGS)
 
 toolexeclib_LTLIBRARIES = libitm.la
 nodist_toolexeclib_HEADERS = libitm.spec
diff --git a/libitm/acinclude.m4 b/libitm/acinclude.m4
--- a/libitm/acinclude.m4
+++ b/libitm/acinclude.m4
@@ -261,6 +261,36 @@ AC_DEFUN([LIBITM_CHECK_LINKER_FEATURES],
 
 
 dnl
+dnl Check if the linker used supports linker maps to clear hardware
+dnl capabilities.  This is only supported by Sun ld at the moment.
+dnl
+dnl Defines:
+dnl  HWCAP_LDFLAGS='-Wl,-M,clearcap.map' if possible
+dnl  LD (as a side effect of testing)
+dnl
+AC_DEFUN([LIBITM_CHECK_LINKER_HWCAP], [
+  test -z "$HWCAP_LDFLAGS" && HWCAP_LDFLAGS=''
+  AC_REQUIRE([AC_PROG_LD])
+
+  ac_save_LDFLAGS="$LDFLAGS"
+  LDFLAGS="$LFLAGS -Wl,-M,$srcdir/clearcap.map"
+
+  AC_MSG_CHECKING([for ld that supports -Wl,-M,mapfile])
+  AC_TRY_LINK([], [return 0;], [ac_hwcap_ldflags=yes],[ac_hwcap_ldflags=no])
+  if test "$ac_hwcap_ldflags" = "yes"; then
+HWCAP_LDFLAGS="-Wl,-M,$srcdir/clearcap.map $HWCAP_LDFLAGS"
+  fi
+  AC_MSG_RESULT($ac_hwcap_ldflags)
+
+  LDFLAGS="$ac_save_LDFLAGS"
+
+  AC_SUBST(HWCAP_LDFLAGS)
+
+  AM_CONDITIONAL(HAVE_HWCAP, test $ac_hwcap_ldflags != no)
+])
+
+
+dnl
 dnl Add version tags to symbols in shared library (or not), additionally
 dnl marking other symbols as private/local (or not).
 dnl
diff --git a/libitm/clearcap.map b/libitm/clearcap.map
new file mode 100644
--- /dev/null
+++ b/libitm/clearcap.map
@@ -0,0 +1,14 @@
+# Clear hardware capabilities emitted by Sun as: calls to the x86_avx.c
+# functions are only emitted with -mavx.
+#
+# The v1 mapfile syntax has no support for clearing specific capabilities,
+# so clear everything.
+#
+hwcap_1 = V0x0 OVERRIDE;
+#
+# If we can assume mapfile v2 syntax, we can specificially clear AVX.
+#
+#$mapfile_version 2
+#CAPABILITY {
+#	HW -= AVX;
+#};
diff --git a/libitm/configure.ac b/libitm/configure.ac
--- a/libitm/configure.ac
+++ b/libitm/configure.ac
@@ -1,5 +1,5 @@
 # Process this file with autoreconf to produce a configure script.
-#   Copyright (C) 2011 Free Software Foundation, Inc.
+#   Copyright (C) 2011, 2012 Free Software Foundation, Inc.
 
 # This program is free software; you can redistribute it and/or modify
 # it under the terms of the GNU General Public License as published by
@@ -208,12 +208,17 @@ GCC_LINUX_FUTEX(:)
 # See if we support thread-local storage.
 GCC_CHECK_TLS
 
-# See what sort of export controls are availible.
+# See what sort of export controls are available.
 LIBITM_CHECK_ATTRIBUTE_VISIBILITY
 LIBITM_CHECK_ATT

[PATCH][Cilkplus] Added a int cast

2012-01-16 Thread Iyer, Balaji V
Hello Everyone,
This patch is for the Cilkplus branch. It adds a "(int)" cast for a for 
loop condition which uses VEC_length.

Thanking You,

Yours Sincerely,

Balaji V. Iyer. diff --git a/gcc/ChangeLog.cilk b/gcc/ChangeLog.cilk
index b51ddcd..8d65ca2 100644
--- a/gcc/ChangeLog.cilk
+++ b/gcc/ChangeLog.cilk
@@ -1,3 +1,8 @@
+2011-01-16  Balaji V. Iyer  
+
+   * cilk.c (cilk_remove_annotated_functions): Added a int cast for
+   VEC_length in for-loop condition.
+
 2011-12-25  Balaji V. Iyer  
 
* c-array-notations.c (find_rank): Added a check for CALL_EXPR and
diff --git a/gcc/cilk.c b/gcc/cilk.c
index 6b97a6a..cc4ddcd 100644
--- a/gcc/cilk.c
+++ b/gcc/cilk.c
@@ -1155,7 +1155,7 @@ cilk_remove_annotated_functions (rtx first)
}
}
 }
-  for (ii = 0; ii < VEC_length (rtx, rtx_delete_list); ii++)
+  for (ii = 0; ii < (int)VEC_length (rtx, rtx_delete_list); ii++)
 remove_insn (VEC_index (rtx, rtx_delete_list, ii));
   
   return;


Re: [libitm, build] Support sun symbol versioning

2012-01-16 Thread Rainer Orth
Torvald Riegel  writes:

> On Mon, 2011-11-21 at 15:06 +0100, Rainer Orth wrote:
>> * _ITM_getThreadnum is the only symbol in libitm.map that isn't present
>>   in the library.  It's documented as missing and should perhaps be
>>   removed from the map?
>
> Yes, this is not supported anymore.

Here's the patch that removes it.  I think this should go in before
4.7.0 is released: if the function is added later, it would incorrectly
end up in the LIBITM_1.0, defeating the purpose of symbol versioning.

Bootstrapped without regressions on i386-pc-solaris2.11 and verified
that the symbol version info is unchanged.

Ok for mainline?

Rainer


2012-01-14  Rainer Orth  

* libitm.h (_ITM_getThreadnum): Remove.
* libitm.map (_ITM_getThreadnum): Remove from LIBITM_1.0.

# HG changeset patch
# Parent e9235a85428f1c332d0b4346142aabc0d3c3990c
Remove _ITM_getThreadnum

diff --git a/libitm/libitm.h b/libitm/libitm.h
--- a/libitm/libitm.h
+++ b/libitm/libitm.h
@@ -1,4 +1,4 @@
-/* Copyright (C) 2008, 2009, 2011 Free Software Foundation, Inc.
+/* Copyright (C) 2008, 2009, 2011, 2012 Free Software Foundation, Inc.
Contributed by Richard Henderson .
 
This file is part of the GNU Transactional Memory Library (libitm).
@@ -149,8 +149,6 @@ extern void _ITM_addUserCommitAction(_IT
 
 extern void _ITM_addUserUndoAction(_ITM_userUndoFunction, void *) ITM_REGPARM;
 
-extern int _ITM_getThreadnum(void) ITM_REGPARM;
-
 extern void _ITM_dropReferences (void *, size_t) ITM_REGPARM ITM_PURE;
 
 extern void *_ITM_malloc (size_t)
diff --git a/libitm/libitm.map b/libitm/libitm.map
--- a/libitm/libitm.map
+++ b/libitm/libitm.map
@@ -8,7 +8,6 @@ LIBITM_1.0 {
 	_ITM_commitTransaction;
 	_ITM_commitTransactionEH;
 	_ITM_error;
-	_ITM_getThreadnum;
 	_ITM_getTransactionId;
 	_ITM_inTransaction;
 	_ITM_libraryVersion;


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


[libitm] Link eh-1.exe with -shared-libgcc on Solaris (PR libitm/51822)

2012-01-16 Thread Rainer Orth
As reported in PR libitm/51822, the libitm.c++/eh-1.C test FAILs on
Solaris with 

terminate called after throwing an instance of 'int'

I found that the failures are for two different reasons:

* Enabling ld.so.1 debugging (LD_DEBUG=bindings), it turned out that the
  64-bit failures on Solaris 10 and 11 happen since
  _Unwind_RaiseException from libc is used:

25243: 1: binding file=../../../gcc/amd64/libgcc_s.so.1 
(0xfd7fc21e6910:0x16910) at plt[27]:full to file=/lib/64/libc.so.1 
(0xfd7fff05a250:0x12a250): symbol '_Unwind_RaiseException'

  Unlike SPARC and the 32-bit libc, the 64-bit one provides an
  implementation of the unwinder, which seems to break this test.
  Linking the test with -shared-libgcc fixes it.

* The 32-bit failures on Solaris 8 to 10 have a different root cause:
  _Unwind_Find_FDE returns NULL for an address in _ZGTtL2f1v (f1()).  It
  turns out that there are two copies of the unwinder in eh-1.exe: one
  from libgcc_s.so.1, and another one from libgcc_eh.a.  eh-1.o has a
  reference to _Unwind_Resume (don't yet know why), which is resolved
  from libgcc_eh.a.  This doesn't happen on Solaris 11, which uses the
  dl_iterate_phdr based unwinder, thus no __register_frame_info_bases.

  Again, linking with shared-libgcc allows the testcase to succeed.

Bootstrapped without regressions on i386-pc-solaris2.11.

Ok for mainline?

Rainer


2012-01-15  Rainer Orth  

PR libitm/51822
* testsuite/libitm.c++/eh-1.C: Add -shared-libgcc on *-*-solaris2*.

# HG changeset patch
# Parent b41d70648bc4d3ba4c7930a694c0100973a1ed01
Link eh-1.exe with -shared-libgcc on Solaris (PR libitm/51822)

diff --git a/libitm/testsuite/libitm.c++/eh-1.C b/libitm/testsuite/libitm.c++/eh-1.C
--- a/libitm/testsuite/libitm.c++/eh-1.C
+++ b/libitm/testsuite/libitm.c++/eh-1.C
@@ -1,4 +1,5 @@
 // { dg-do run }
+// { dg-options "-shared-libgcc" { target *-*-solaris2* } }
 
 extern "C" void abort ();
 


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


[libitm] Skip static_ctor.C test (PR libitm/51173)

2012-01-16 Thread Rainer Orth
As suggested in the PR, it would be better to just skip the test to
avoid noise in mail-report.log:

WARNING: libitm.c++/static_ctor.C compilation failed to produce executable

The following patch does just that, and simplifies the dg-skip-if on the
way.

Bootstrapped without regressions on i386-pc-solaris2.11.

Ok for mainline?

Rainer


2012-01-15  Rainer Orth  

PR libitm/51173
* testsuite/libitm.c++/static_ctor.C: Skip test, note PR, remove
include, exclude options.

# HG changeset patch
# Parent c013b883e9b76d625eab175a405af3115e16708c
Skip static_ctor.C test (PR libitm/???)

diff --git a/libitm/testsuite/libitm.c++/static_ctor.C b/libitm/testsuite/libitm.c++/static_ctor.C
--- a/libitm/testsuite/libitm.c++/static_ctor.C
+++ b/libitm/testsuite/libitm.c++/static_ctor.C
@@ -1,6 +1,6 @@
 /* { dg-do run } */
 /* { dg-options "-pthread" } */
-/* { dg-xfail-if "" { *-*-* } { "*" } { "" } } */
+/* { dg-skip-if "PR libitm/51822" { *-*-* } } */
 /* Tests static constructors inside of transactional code.  */
 
 #include 


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


[Patch, Fortran] PR 50981 Fix simpler issues of optional + elemental

2012-01-16 Thread Tobias Burnus

Dear all,

PR 50981 is about passing an absent argument to an elemental procedure.

a) Passing an absent optional dummy as actual.
4.4-4.7 Regression, fixed for 4.7; backporting pending.

b) Passing an unallocated allocatable or not associated pointer as actual
F2008/GCC 4.6 feature. Fixed by this patch.

c) Handling polymorphic scalars/arrays with elemental procedures
Some draft patch available, but needs more work. That's a 4.7/4.8 item.

The attached patch solves (b).

Build and regtested on x86-64-linux.
OK for the trunk? (And [together with (a)] for the 4.6 branch?)

Tobias
2012-01-16  Mikael Morin  
	Tobias Burnus  

	PR fortran/50981
	* trans-array.c (gfc_walk_elemental_function_args): Fix
	passing of deallocated allocatables/pointers as absent argument. 

2012-01-16  Mikael Morin  
	Tobias Burnus  

	PR fortran/50981
	* gfortran.dg/elemental_optional_args_3.f90: New
	* gfortran.dg/elemental_optional_args_4.f90: New

Index: gcc/fortran/trans-array.c
===
--- gcc/fortran/trans-array.c	(revision 183208)
+++ gcc/fortran/trans-array.c	(working copy)
@@ -8399,9 +8399,10 @@ gfc_walk_elemental_function_args (gfc_ss * ss, gfc
 
 	  if (dummy_arg != NULL
 	  && dummy_arg->sym->attr.optional
-	  && arg->expr->symtree
-	  && arg->expr->symtree->n.sym->attr.optional
-	  && arg->expr->ref == NULL)
+	  && arg->expr->expr_type == EXPR_VARIABLE
+	  && (gfc_expr_attr (arg->expr).optional
+		  || gfc_expr_attr (arg->expr).allocatable
+		  || gfc_expr_attr (arg->expr).pointer))
 	newss->info->data.scalar.can_be_null_ref = true;
 	}
   else
Index: gcc/testsuite/gfortran.dg/elemental_optional_args_3.f90
===
--- gcc/testsuite/gfortran.dg/elemental_optional_args_3.f90	(revision 0)
+++ gcc/testsuite/gfortran.dg/elemental_optional_args_3.f90	(working copy)
@@ -0,0 +1,85 @@
+! { dg-do run }
+!
+! PR fortran/50981
+! The program used to dereference a NULL pointer when trying to access
+! a pointer dummy argument to be passed to an elemental subprocedure.
+!
+! Original testcase from Andriy Kostyuk 
+
+PROGRAM test
+  IMPLICIT NONE
+  REAL(KIND=8), DIMENSION(2) :: aa, rr
+  INTEGER, TARGET  :: c
+  INTEGER, POINTER :: b
+
+  aa(1)=10.
+  aa(2)=11.
+
+  b=>c
+  b=1
+
+  ! WRITE(*,*) 'Both f1 and ff work if the optional parameter is present:'
+
+  rr=f1(aa,b)
+  ! WRITE(*,*) ' rr(1)=', rr(1), '  rr(2)=', rr(2)
+  IF (ANY(rr /= (/ 110, 132 /))) CALL ABORT
+
+  rr=0
+  rr=ff(aa,b)
+  ! WRITE(*,*) ' rr(1)=', rr(1), '  rr(2)=', rr(2)
+  IF (ANY(rr /= (/ 110, 132 /))) CALL ABORT
+
+
+  b => NULL()
+  ! WRITE(*,*) 'But only f1 works if the optional parameter is absent:'
+
+  rr=0
+  rr=f1(aa, b)
+  ! WRITE(*,*) ' rr(1)=', rr(1), '  rr(2)=', rr(2)
+  IF (ANY(rr /= (/ 110, 132 /))) CALL ABORT
+
+  rr = 0
+  rr=ff(aa, b)
+  ! WRITE(*,*) ' rr(1)=', rr(1), '  rr(2)=', rr(2)
+  IF (ANY(rr /= (/ 110, 132 /))) CALL ABORT
+
+
+CONTAINS 
+
+FUNCTION ff(a,b)
+  IMPLICIT NONE
+  REAL(KIND=8), INTENT(IN) :: a(:)
+  REAL(KIND=8), DIMENSION(SIZE(a)) :: ff
+  INTEGER, INTENT(IN), POINTER :: b
+  REAL(KIND=8), DIMENSION(2, SIZE(a)) :: ac
+  ac(1,:)=a
+  ac(2,:)=a**2
+  ff=SUM(gg(ac,b), dim=1)
+END FUNCTION ff
+
+FUNCTION f1(a,b)
+  IMPLICIT NONE
+  REAL(KIND=8), INTENT(IN) :: a(:)
+  REAL(KIND=8), DIMENSION(SIZE(a)) :: f1
+  INTEGER, INTENT(IN), POINTER :: b
+  REAL(KIND=8), DIMENSION(2, SIZE(a)) :: ac
+  ac(1,:)=a
+  ac(2,:)=a**2
+  f1=gg(ac(1,:),b)+gg(ac(2,:),b) ! This is the same as in ff, but without using the elemental feature of gg
+END FUNCTION f1
+
+ELEMENTAL REAL(KIND=8) FUNCTION gg(a,b)
+  IMPLICIT NONE
+  REAL(KIND=8), INTENT(IN) :: a
+  INTEGER, INTENT(IN), OPTIONAL :: b
+  INTEGER ::b1
+  IF(PRESENT(b)) THEN
+b1=b
+  ELSE
+b1=1
+  ENDIF
+  gg=a**b1
+END FUNCTION gg
+
+
+END PROGRAM test
Index: gcc/testsuite/gfortran.dg/elemental_optional_args_4.f90
===
--- gcc/testsuite/gfortran.dg/elemental_optional_args_4.f90	(revision 0)
+++ gcc/testsuite/gfortran.dg/elemental_optional_args_4.f90	(working copy)
@@ -0,0 +1,84 @@
+! { dg-do run }
+!
+! PR fortran/50981
+! The program used to dereference a NULL pointer when trying to access
+! an allocatable dummy argument to be passed to an elemental subprocedure.
+!
+! Original testcase from Andriy Kostyuk 
+
+PROGRAM test
+  IMPLICIT NONE
+  REAL(KIND=8), DIMENSION(2) :: aa, rr
+  INTEGER, ALLOCATABLE :: b
+
+  aa(1)=10.
+  aa(2)=11.
+
+  ALLOCATE(b)
+  b=1
+
+  ! WRITE(*,*) 'Both f1 and ff work if the optional parameter is present:'
+
+  rr=f1(aa,b)
+  ! WRITE(*,*) ' rr(1)=', rr(1), '  rr(2)=', rr(2)
+  IF (ANY(rr /= (/ 110, 132 /))) CALL ABORT
+
+  rr=0
+  rr=ff(aa,b)
+  ! WRITE(*,*) ' rr(1)=', rr(1), '  rr(2)=', rr(2)
+  IF (ANY(rr /= (/ 

[C++ Patch] PR 51777

2012-01-16 Thread Paolo Carlini

Hi,

in this diagnostic issue we incorrectly print unsigned template 
arguments as signed. The fix seems straightforward: just use the very 
same algorithm used in dump_generic_node for INTEGER_CST, thus dispatch 
to either pp_wide_integer or  pp_unsigned_wide_integer.


Booted and tested C++ (testing in progress for C etc.)

Ok for mainline?

Thanks,
Paolo.

///
2012-01-16  Paolo Carlini  

PR c++/51777
* c-pretty-print.c (pp_c_integer_constant): For unsigned constants
use pp_unsigned_wide_integer.
Index: c-pretty-print.c
===
--- c-pretty-print.c(revision 183211)
+++ c-pretty-print.c(working copy)
@@ -910,8 +910,10 @@ pp_c_integer_constant (c_pretty_printer *pp, tree
 ? TYPE_CANONICAL (TREE_TYPE (i))
 : TREE_TYPE (i);
 
-  if (TREE_INT_CST_HIGH (i) == 0)
+  if (host_integerp (i, 0))
 pp_wide_integer (pp, TREE_INT_CST_LOW (i));
+  else if (host_integerp (i, 1))
+pp_unsigned_wide_integer (pp, TREE_INT_CST_LOW (i));
   else
 {
   unsigned HOST_WIDE_INT low = TREE_INT_CST_LOW (i);


Re: libgo patch committed: Update to weekly.2011-12-22

2012-01-16 Thread Rainer Orth
Ian Lance Taylor  writes:

> I have committed a patch to libgo to update it to the weekly.2011-12-22
> release.  As usual I am not including all the changes here, only the
> ones to files which are specific to gccgo.  Bootstrapped and ran Go
> testsuite on x86_64-unknown-linux-gnu.  Committed to mainline.

The patch introduced a couple of other problems:

* There's a warning during libgo configure:

checking for --enable-version-specific-runtime-libs... no
/vol/gcc/src/hg/trunk/solaris/libgo/configure[13514]: test: argument expected
checking whether -fsplit-stack is supported... no

  Fixed as follows:

diff --git a/libgo/configure.ac b/libgo/configure.ac
--- a/libgo/configure.ac
+++ b/libgo/configure.ac
@@ -126,6 +126,7 @@ is_darwin=no
 is_freebsd=no
 is_irix=no
 is_linux=no
+is_netbsd=no
 is_rtems=no
 is_solaris=no
 GOOS=unknown

* Bootstrap on Solaris < 11 is broken:

/vol/gcc/src/hg/trunk/local/libgo/runtime/mem.c:73:2: error: implicit 
declaration of function 'madvise' [-Werror=implicit-function-declaration]

  The madvise declaration in  is only visible if
  !(_XOPEN_SOURCE > 420).  Since _XOPEN_SOURCE is necessary for other
  compilations, I've #undef'ed the symbol at the beginning of this
  particular file:

diff --git a/libgo/runtime/mem.c b/libgo/runtime/mem.c
--- a/libgo/runtime/mem.c
+++ b/libgo/runtime/mem.c
@@ -1,3 +1,7 @@
+/* Defining _XOPEN_SOURCE hides the declaration of madvise() on Solaris <
+   11 and the MADV_DONTNEED definition on IRIX 6.5.  */
+#undef _XOPEN_SOURCE
+
 #include 
 #include 
 
  As the comment states, IRIX has a similar problem, but that could be
  fixed in a different way.

* The IRIX libgo build is broken like this:

/vol/gcc/src/hg/trunk/local/libgo/runtime/go-map-delete.c: In function 
'__go_map_delete':
/vol/gcc/src/hg/trunk/local/libgo/runtime/go-map-delete.c:38:11: error: 
assignment from incompatible pointer type [-Werror]

/vol/gcc/src/hg/trunk/local/libgo/runtime/go-map-index.c:36:10: error: 
assignment from incompatible pointer type [-Werror]

  On IRIX, size_t and uintptr_t differ, so I'm changing the prototypes
  above to match what's in go-type.h.

/vol/gcc/src/hg/trunk/local/libgo/runtime/mem.c:70:25: error: unused parameter 
'v' [-Werror=unused-parameter]
/vol/gcc/src/hg/trunk/local/libgo/runtime/mem.c:70:36: error: unused parameter 
'n' [-Werror=unused-parameter]

  As mentioned above, MADV_DONTNEED may be unavailable, so the args need
  to be marked unused to avoid the warning.

diff --git a/libgo/runtime/go-map-delete.c b/libgo/runtime/go-map-delete.c
--- a/libgo/runtime/go-map-delete.c
+++ b/libgo/runtime/go-map-delete.c
@@ -20,7 +20,7 @@ __go_map_delete (struct __go_map *map, c
   const struct __go_map_descriptor *descriptor;
   const struct __go_type_descriptor *key_descriptor;
   uintptr_t key_offset;
-  _Bool (*equalfn) (const void*, const void*, size_t);
+  _Bool (*equalfn) (const void*, const void*, uintptr_t);
   size_t key_hash;
   size_t key_size;
   size_t bucket_index;
diff --git a/libgo/runtime/go-map-index.c b/libgo/runtime/go-map-index.c
--- a/libgo/runtime/go-map-index.c
+++ b/libgo/runtime/go-map-index.c
@@ -21,7 +21,7 @@ __go_map_rehash (struct __go_map *map)
   const struct __go_type_descriptor *key_descriptor;
   uintptr_t key_offset;
   size_t key_size;
-  size_t (*hashfn) (const void *, size_t);
+  uintptr_t (*hashfn) (const void *, uintptr_t);
   uintptr_t old_bucket_count;
   void **old_buckets;
   uintptr_t new_bucket_count;
@@ -80,7 +80,7 @@ __go_map_index (struct __go_map *map, co
   const struct __go_map_descriptor *descriptor;
   const struct __go_type_descriptor *key_descriptor;
   uintptr_t key_offset;
-  _Bool (*equalfn) (const void*, const void*, size_t);
+  _Bool (*equalfn) (const void*, const void*, uintptr_t);
   size_t key_hash;
   size_t key_size;
   size_t bucket_index;
diff --git a/libgo/runtime/mem.c b/libgo/runtime/mem.c
--- a/libgo/runtime/mem.c
+++ b/libgo/runtime/mem.c
@@ -71,7 +71,7 @@ runtime_SysAlloc(uintptr n)
 }
 
 void
-runtime_SysUnused(void *v, uintptr n)
+runtime_SysUnused(void *v __attribute__ ((unused)), uintptr n __attribute__ 
((unused)))
 {
 #ifdef MADV_DONTNEED
runtime_madvise(v, n, MADV_DONTNEED);

With those changes, I was able to get libgo to build again on IRIX 6.5
and Solaris 10.

Rainer

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


[Patch, Fortran] PR 51809 Fix ICE with __vtab

2012-01-16 Thread Tobias Burnus

Dear all,

current gfortran uses FL_PARAMETER for _vtab and _init_def; 
unfortunately, that will fail sometimes to properly read the symbols; in 
the PR _vtab->_extension's symbol is not properly read, depending on the 
USE statement order.


I tried to debug it, but I was not very successful. In principle, the 
fixup mechanism should work. On the other hand, the internally generated 
code is not valid: _vtab is a variable of a derived type with pointer 
components (so far so good).


However, Fortran does not allow one to mark such a variable as 
PARAMETER. The main reason is that one could use TRANSFER on the 
parameter - and TRANSFER is back to a pointer somewhere else. That's 
only possible if the value is known at compilation time. However, 
pointer addresses are only known at run time. That does not rule out 
that one uses a PARAMETER internally, but it reduces the incentive to 
debug the issue as it can only affect __vtab/__def_init.


Thus, I decided to backout the patch Rev. 181199 (cf. PR, comment 1) - 
and implement a simple TREE_READONLY in trans-decl.c.


Build and regtested on x86-64-linux.
OK for the 4.7 trunk?

Tobias
2012-01-16  Tobias Burnus  

	PR fortran/51809
	* class.c (gfc_find_derived_vtab): Mark __vtab and
	__def_init as FL_VARIABLE not as FL_PARAMETER.
	* expr.c (gfc_simplify_expr): Remove special
	handling of __vtab.
	* resolve.c (resolve_values): Ditto.
	* trans-decl.c (gfc_get_symbol_decl): Mark __vtab
	and __def_init as TREE_READONLY.

2012-01-16  Tobias Burnus  

	PR fortran/51809
	* gfortran.dg/use_20.f90: New

diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c
index a17fc0a..5e5de14 100644
--- a/gcc/fortran/class.c
+++ b/gcc/fortran/class.c
@@ -588,7 +588,7 @@ gfc_find_derived_vtab (gfc_symbol *derived)
 	{
 	  gfc_get_symbol (name, ns, &vtab);
 	  vtab->ts.type = BT_DERIVED;
-	  if (gfc_add_flavor (&vtab->attr, FL_PARAMETER, NULL,
+	  if (gfc_add_flavor (&vtab->attr, FL_VARIABLE, NULL,
 	  &gfc_current_locus) == FAILURE)
 	goto cleanup;
 	  vtab->attr.target = 1;
@@ -682,7 +682,7 @@ gfc_find_derived_vtab (gfc_symbol *derived)
 		  def_init->attr.target = 1;
 		  def_init->attr.save = SAVE_IMPLICIT;
 		  def_init->attr.access = ACCESS_PUBLIC;
-		  def_init->attr.flavor = FL_PARAMETER;
+		  def_init->attr.flavor = FL_VARIABLE;
 		  gfc_set_sym_referenced (def_init);
 		  def_init->ts.type = BT_DERIVED;
 		  def_init->ts.u.derived = derived;
diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index a6baa68..8f04c73 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -1883,8 +1883,7 @@ gfc_simplify_expr (gfc_expr *p, int type)
 	 initialization expression, or we want a subsection.  */
   if (p->symtree->n.sym->attr.flavor == FL_PARAMETER
 	  && (gfc_init_expr_flag || p->ref
-	  || p->symtree->n.sym->value->expr_type != EXPR_ARRAY)
-	  && !p->symtree->n.sym->attr.vtab)
+	  || p->symtree->n.sym->value->expr_type != EXPR_ARRAY))
 	{
 	  if (simplify_parameter_variable (p, type) == FAILURE)
 	return FAILURE;
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 352d22d..c169b9e 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -9637,7 +9637,7 @@ resolve_values (gfc_symbol *sym)
 {
   gfc_try t;
 
-  if (sym->value == NULL || sym->attr.use_assoc)
+  if (sym->value == NULL)
 return;
 
   if (sym->value->expr_type == EXPR_STRUCTURE)
@@ -12195,7 +12195,7 @@ resolve_fl_parameter (gfc_symbol *sym)
   /* Make sure the types of derived parameters are consistent.  This
  type checking is deferred until resolution because the type may
  refer to a derived type from the host.  */
-  if (sym->ts.type == BT_DERIVED && sym->value
+  if (sym->ts.type == BT_DERIVED
   && !gfc_compare_types (&sym->ts, &sym->value->ts))
 {
   gfc_error ("Incompatible derived type in PARAMETER at %L",
diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index 0761ebb..e8e54c7 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -1485,7 +1485,10 @@ gfc_get_symbol_decl (gfc_symbol * sym)
 
   if (sym->attr.vtab
   || (sym->name[0] == '_' && strncmp ("__def_init", sym->name, 10) == 0))
-GFC_DECL_PUSH_TOPLEVEL (decl) = 1;
+{
+  TREE_READONLY (decl) = 1;
+  GFC_DECL_PUSH_TOPLEVEL (decl) = 1;
+}
 
   return decl;
 }
--- /dev/null	2012-01-16 08:28:57.351763035 +0100
+++ gcc/gcc/testsuite/gfortran.dg/use_20.f90	2012-01-16 18:41:44.0 +0100
@@ -0,0 +1,49 @@
+! { dg-do compile }
+!
+! PR fortran/51809
+!
+! Contributed by Kacper Kowalik
+!
+module foo
+   implicit none
+
+   type foo_t
+   contains
+  procedure :: func_foo
+   end type foo_t
+
+contains
+
+   subroutine func_foo(this)
+  implicit none
+  class(foo_t), intent(in) :: this
+   end subroutine func_foo
+
+end module foo
+
+module bar
+   use foo,   only: foo_t
+
+   implicit none
+
+   type, extends(foo_t) :: bar_t
+   contains
+  procedure :: func_bar
+   end type bar_t
+
+contains
+

Re: [libitm] Skip static_ctor.C test (PR libitm/51173)

2012-01-16 Thread Mike Stump
On Jan 16, 2012, at 9:14 AM, Rainer Orth wrote:
> As suggested in the PR, it would be better to just skip the test to
> avoid noise in mail-report.log:

Usually we avoid noise in the testing log files by making testcases pass?  I 
know, this one is kinda inelegant, but I'd just leave it as is.  If it doesn't 
pass on any useful target, I suppose skipping or just removing the testcase 
would be fine, with the idea that the testcases is added back or reenabled when 
the PR is fixed.  Let's give the TM people a chance to weigh in, if they'd 
like, but, if they don't, I'll Ok it if you prefer to disable or remove it.


Re: [Patch, Fortran] PR 51809 Fix ICE with __vtab

2012-01-16 Thread Paul Richard Thomas
Dear Tobias,


> Thus, I decided to backout the patch Rev. 181199 (cf. PR, comment 1) - and
> implement a simple TREE_READONLY in trans-decl.c.

I think that was a very sensible decision :-)

>
> Build and regtested on x86-64-linux.
> OK for the 4.7 trunk?
>

OK, thanks for the patch.

Paul


Re: [Patch, Fortran] PR 50981 Fix simpler issues of optional + elemental

2012-01-16 Thread Paul Richard Thomas
Dear Tobias,

> Build and regtested on x86-64-linux.
> OK for the trunk? (And [together with (a)] for the 4.6 branch?)

OK - thanks!

Paul


C++ PATCH for c++/51868 (static_cast, rvalue refs and bit-fields)

2012-01-16 Thread Jason Merrill
There were two problems with build_static_cast_1's handling of this 
testcase:


1) We weren't using unlowered_expr_type to get the type of the 
expression, so we were comparing int to the internal bit-field type, 
which doesn't match.


2) We were trying to bind an lvalue reference to a bit-field in the 
process of converting to rvalue reference, which doesn't work; for 
bit-fields, we should convert to an rvalue temporary and then bind the 
rvalue reference to that.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit 1e5a058d0b7b0226a5956ee991b9a47757d2aedd
Author: Jason Merrill 
Date:   Mon Jan 16 13:12:26 2012 -0500

	PR c++/51868
	* typeck.c (build_static_cast_1): Handle bit-fields properly.

diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index 11edeee..91e7a0a 100644
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -5812,11 +5812,12 @@ build_static_cast_1 (tree type, tree expr, bool c_cast_p,
 {
   tree intype;
   tree result;
+  cp_lvalue_kind clk;
 
   /* Assume the cast is valid.  */
   *valid_p = true;
 
-  intype = TREE_TYPE (expr);
+  intype = unlowered_expr_type (expr);
 
   /* Save casted types in the function's used types hash table.  */
   used_types_insert (type);
@@ -5882,22 +5883,29 @@ build_static_cast_1 (tree type, tree expr, bool c_cast_p,
  cv2 T2 if cv2 T2 is reference-compatible with cv1 T1 (8.5.3)."  */
   if (TREE_CODE (type) == REFERENCE_TYPE
   && TYPE_REF_IS_RVALUE (type)
-  && real_lvalue_p (expr)
+  && (clk = real_lvalue_p (expr))
   && reference_related_p (TREE_TYPE (type), intype)
   && (c_cast_p || at_least_as_qualified_p (TREE_TYPE (type), intype)))
 {
-  /* Handle the lvalue case here by casting to lvalue reference and
-	 then changing it to an rvalue reference.  Casting an xvalue to
-	 rvalue reference will be handled by the main code path.  */
-  tree lref = cp_build_reference_type (TREE_TYPE (type), false);
-  result = (perform_direct_initialization_if_possible
-		(lref, expr, c_cast_p, complain));
-  result = cp_fold_convert (type, result);
-  /* Make sure we don't fold back down to a named rvalue reference,
-	 because that would be an lvalue.  */
-  if (DECL_P (result))
-	result = build1 (NON_LVALUE_EXPR, type, result);
-  return convert_from_reference (result);
+  if (clk == clk_ordinary)
+	{
+	  /* Handle the (non-bit-field) lvalue case here by casting to
+	 lvalue reference and then changing it to an rvalue reference.
+	 Casting an xvalue to rvalue reference will be handled by the
+	 main code path.  */
+	  tree lref = cp_build_reference_type (TREE_TYPE (type), false);
+	  result = (perform_direct_initialization_if_possible
+		(lref, expr, c_cast_p, complain));
+	  result = cp_fold_convert (type, result);
+	  /* Make sure we don't fold back down to a named rvalue reference,
+	 because that would be an lvalue.  */
+	  if (DECL_P (result))
+	result = build1 (NON_LVALUE_EXPR, type, result);
+	  return convert_from_reference (result);
+	}
+  else
+	/* For a bit-field or packed field, bind to a temporary.  */
+	expr = rvalue (expr);
 }
 
   /* Resolve overloaded address here rather than once in
diff --git a/gcc/testsuite/g++.dg/cpp0x/rv-bitfield.C b/gcc/testsuite/g++.dg/cpp0x/rv-bitfield.C
new file mode 100644
index 000..a269a76
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/rv-bitfield.C
@@ -0,0 +1,13 @@
+// { dg-options -std=c++0x }
+
+struct A
+{
+  int i : 1;
+};
+
+int main()
+{
+  A a;
+  static_cast(a.i);
+}
+
diff --git a/gcc/testsuite/g++.dg/cpp0x/rv-bitfield2.C b/gcc/testsuite/g++.dg/cpp0x/rv-bitfield2.C
new file mode 100644
index 000..e054151
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/rv-bitfield2.C
@@ -0,0 +1,17 @@
+// PR c++/51868
+// { dg-options -std=c++0x }
+
+struct A {
+  A() {}
+  A(const A&) {}
+  A(A&&) {}
+};
+
+struct B {
+  A a;
+  int f : 1;
+};
+
+B func() {
+  return B();
+}


[v3] RFC libstdc++11convenience.la

2012-01-16 Thread Benjamin Kosnik

This breaks separates the libstdc++ source files for C++11 from the
C++03 sources, and puts C++11 files in a new source directory,
src-c++11, which is compiled into libstdc++11convenience.a, and linked
in to libstdc++ in the same manner that libsupc++ uses.

Thus, no change to user-level or tool-level linking. To use C++11,
you'd still just link in libstdc++. To use C++03, you'd still just link
in libstdc++. 

The build rules for C++11 were established early on. This seems like a
useful abstraction now that so many of the sources have to be built
with C++11 flags. 

At some point, the continued ad hoc nature of
src/Makefile.am's current approach will break down.

At some other point, we might want to start building a libstdc++11
library with different flags from src/c++03. This is how to get there.

tested x86/linux

-benjamin2012-01-16  Benjamin Kosnik  

	Add libstdc++11convenience.la.
	* src-c++11: New directory.
	* acinclude.m4: (GLIBCXX_CONFIGURE): Add src-c++11.
	* configure: Regenerated.
	* Makefile.am (hosted_source): Add src-c++11 to SUBDIRS.
	* Makefile.in: Regenerate.
	* libsupc++/Makefile.am (AM_CXXFLAGS): USe XTEMPLATE_FLAGS for
	-fno-implicit-templates.
	* libsupc++/Makefile.in: Regenerate.
	* src/Makefile.am (inst_sources): Move... C++11 files into
	separate directory for libstdc++11convenience.la. Files are:
	fstream-inst.cc, string-inst.cc, wlocale-inst.cc, wstring-inst.cc).
	(sources): Move C++11 files. Files are: compatibility-c++0x.cc,
	compatibility-atomic-c++0x.cc, debug.cc, functexcept.cc,
	functional.cc, hash_c++0x.cc, hashtable_c++0x.cc, limits.cc,
	system_error.cc, placeholders.cc, regex.cc, shared_ptr.cc,
	mutex.cc, condition_variable.cc, chrono.cc, thread.cc, future.cc.
	* src/Makefile.in: Regenerate.
	* src-c++11/Makefile.am: New.
	* src-c++11/Makefile.in: Generate.


diff --git a/libstdc++-v3/Makefile.am b/libstdc++-v3/Makefile.am
index f1b5b07..02d60e1 100644
--- a/libstdc++-v3/Makefile.am
+++ b/libstdc++-v3/Makefile.am
@@ -24,7 +24,7 @@
 include $(top_srcdir)/fragment.am
 
 if GLIBCXX_HOSTED
-  hosted_source = doc src po testsuite
+  hosted_source = src-c++11 src doc po testsuite
 endif
 
 ## Keep this list sync'd with acinclude.m4:GLIBCXX_CONFIGURE.
diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index 9d08178..0bb4d63 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -49,7 +49,7 @@ AC_DEFUN([GLIBCXX_CONFIGURE], [
   # Keep these sync'd with the list in Makefile.am.  The first provides an
   # expandable list at autoconf time; the second provides an expandable list
   # (i.e., shell variable) at configure time.
-  m4_define([glibcxx_SUBDIRS],[include libsupc++ python src doc po testsuite])
+  m4_define([glibcxx_SUBDIRS],[include libsupc++ python src-c++11 src doc po testsuite])
   SUBDIRS='glibcxx_SUBDIRS'
 
   # These need to be absolute paths, yet at the same time need to
diff --git a/libstdc++-v3/libsupc++/Makefile.am b/libstdc++-v3/libsupc++/Makefile.am
index fb5c26f..b27725d 100644
--- a/libstdc++-v3/libsupc++/Makefile.am
+++ b/libstdc++-v3/libsupc++/Makefile.am
@@ -104,8 +104,8 @@ libsupc__convenience_la_SOURCES = $(sources) $(c_sources)
 # OPTIMIZE_CXXFLAGS on the compile line so that -O2 can be overridden
 # as the occasion call for it.
 AM_CXXFLAGS = \
-	-fno-implicit-templates \
 	$(LIBSUPCXX_PICFLAGS) \
+	$(XTEMPLATE_FLAGS) \
 	$(WARN_CXXFLAGS) \
 	$(OPTIMIZE_CXXFLAGS) \
 	$(CONFIG_CXXFLAGS)
diff --git a/libstdc++-v3/src/Makefile.am b/libstdc++-v3/src/Makefile.am
index eefa6e2..681f365 100644
--- a/libstdc++-v3/src/Makefile.am
+++ b/libstdc++-v3/src/Makefile.am
@@ -1,7 +1,7 @@
-## Makefile for the src subdirectory of the GNU C++ Standard library.
+## Makefile for the C++11 sources of the GNU C++ Standard library.
 ##
 ## Copyright (C) 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005
-## 2006, 2007, 2008, 2009, 2010, 2011
+## 2006, 2007, 2008, 2009, 2010, 2011, 2012
 ## Free Software Foundation, Inc.
 ##
 ## This file is part of the libstdc++ version 3 distribution.
@@ -171,7 +171,6 @@ inst_sources = \
 	allocator-inst.cc \
 	concept-inst.cc \
 	ext-inst.cc \
-	fstream-inst.cc \
 	ios-inst.cc \
 	iostream-inst.cc \
 	istream-inst.cc \
@@ -180,9 +179,7 @@ inst_sources = \
 	ostream-inst.cc \
 	sstream-inst.cc \
 	streambuf-inst.cc \
-	string-inst.cc \
-	wlocale-inst.cc \
-	wstring-inst.cc
+	wlocale-inst.cc
 else
 XTEMPLATE_FLAGS =
 inst_sources =
@@ -195,27 +192,19 @@ sources = \
 	mt_allocator.cc \
 	codecvt.cc \
 	compatibility.cc \
-	compatibility-c++0x.cc \
-	compatibility-atomic-c++0x.cc \
 	compatibility-debug_list.cc \
 	compatibility-debug_list-2.cc \
 	compatibility-list.cc \
 	compatibility-list-2.cc \
 	complex_io.cc \
 	ctype.cc \
-	debug.cc \
-	functexcept.cc \
-	functional.cc \
 	globals_io.cc \
-	hash_c++0x.cc \
 	hash_tr1.cc \
-	hashtable_c++0x.cc \
 	hashtable_tr1.cc \
 	ios.cc \
 	ios_failure.cc \
 	ios_init.cc \
 	ios_locale.cc \
-	limits.cc \
 	list.cc \
 	locale.cc \
 	locale_init.cc \
@@ -225,18 

Re: useless_type_conversion_p vs pointer sizes

2012-01-16 Thread DJ Delorie

Ah!  I read that as "pointer to aggregate" :-P


Re: useless_type_conversion_p vs pointer sizes

2012-01-16 Thread DJ Delorie

> For the record, what is TPF ?

One of IBM's s390x operating systems.  ../gcc/configure --target=tpf


Re: PING: Re: [PATCH] small build fix

2012-01-16 Thread Robert Millan
El 27 de desembre de 2011 12:25, Robert Millan  ha escrit:
> El 19 de desembre de 2011 21:04, Robert Millan  ha escrit:
>> This small patch fixes a build regression on GNU/kFreeBSD.
>
> Ping!

Ping again.  Please note that Gerald Pfeifer has volunteered to commit
the patch once it is approved.

-- 
Robert Millan
2011-12-19  Robert Millan  

Fix build regression on GNU/kFreeBSD.

* config/kfreebsd-gnu.h (GNU_USER_DYNAMIC_LINKERX32): New macro.

--- a/src/gcc/config/kfreebsd-gnu.h~2011-07-21 17:31:44.0 +0200
+++ b/src/gcc/config/kfreebsd-gnu.h 2011-12-19 20:20:26.961301396 +0100
@@ -33,3 +33,4 @@
 #define GNU_USER_DYNAMIC_LINKERGLIBC_DYNAMIC_LINKER
 #define GNU_USER_DYNAMIC_LINKER32  GLIBC_DYNAMIC_LINKER32
 #define GNU_USER_DYNAMIC_LINKER64  GLIBC_DYNAMIC_LINKER64
+#define GNU_USER_DYNAMIC_LINKERX32 GLIBC_DYNAMIC_LINKERX32


Re: PING: Re: [PATCH] small build fix

2012-01-16 Thread Jakub Jelinek
On Mon, Jan 16, 2012 at 07:37:43PM +, Robert Millan wrote:
> El 27 de desembre de 2011 12:25, Robert Millan  ha escrit:
> > El 19 de desembre de 2011 21:04, Robert Millan  ha escrit:
> >> This small patch fixes a build regression on GNU/kFreeBSD.
> >
> > Ping!
> 
> Ping again.  Please note that Gerald Pfeifer has volunteered to commit
> the patch once it is approved.

Ok.

> 2011-12-19  Robert Millan  
> 
>   Fix build regression on GNU/kFreeBSD.
> 
>   * config/kfreebsd-gnu.h (GNU_USER_DYNAMIC_LINKERX32): New macro.
> 
> --- a/src/gcc/config/kfreebsd-gnu.h~  2011-07-21 17:31:44.0 +0200
> +++ b/src/gcc/config/kfreebsd-gnu.h   2011-12-19 20:20:26.961301396 +0100
> @@ -33,3 +33,4 @@
>  #define GNU_USER_DYNAMIC_LINKERGLIBC_DYNAMIC_LINKER
>  #define GNU_USER_DYNAMIC_LINKER32  GLIBC_DYNAMIC_LINKER32
>  #define GNU_USER_DYNAMIC_LINKER64  GLIBC_DYNAMIC_LINKER64
> +#define GNU_USER_DYNAMIC_LINKERX32 GLIBC_DYNAMIC_LINKERX32

Jakub


C++ PATCH for c++/51854 (ICE with complex literal in function signature)

2012-01-16 Thread Jason Merrill
The mangling code didn't handle complex literals, leading to a crash. 
Jakub's patch implements the standard ABI mangling for them; I just 
added a testcase.


Tested x86_64-pc-linux-gnu, applying to trunk.  It is a regression in 
4.4, 4.5, and 4.6 as well, as 4.3 gave a sorry about mangling call_expr, 
but I'm reluctant to touch the mangling code in other release branches; 
I think I'll just add a sorry there.


commit 68dafc7d4b8c4433ad21149ff60f64a848bef299
Author: Jason Merrill 
Date:   Mon Jan 16 15:18:50 2012 -0500

	PR c++/51854
	* mangle.c (write_template_arg_literal): Handle complex.

diff --git a/gcc/cp/mangle.c b/gcc/cp/mangle.c
index 15b1aca..34f19ef 100644
--- a/gcc/cp/mangle.c
+++ b/gcc/cp/mangle.c
@@ -2927,6 +2927,25 @@ write_template_arg_literal (const tree value)
 	write_real_cst (value);
 	break;
 
+  case COMPLEX_CST:
+	if (TREE_CODE (TREE_REALPART (value)) == INTEGER_CST
+	&& TREE_CODE (TREE_IMAGPART (value)) == INTEGER_CST)
+	  {
+	write_integer_cst (TREE_REALPART (value));
+	write_char ('_');
+	write_integer_cst (TREE_IMAGPART (value));
+	  }
+	else if (TREE_CODE (TREE_REALPART (value)) == REAL_CST
+		 && TREE_CODE (TREE_IMAGPART (value)) == REAL_CST)
+	  {
+	write_real_cst (TREE_REALPART (value));
+	write_char ('_');
+	write_real_cst (TREE_IMAGPART (value));
+	  }
+	else
+	  gcc_unreachable ();
+	break;
+
   case STRING_CST:
 	sorry ("string literal in function template signature");
 	break;
diff --git a/gcc/testsuite/g++.dg/abi/mangle60.C b/gcc/testsuite/g++.dg/abi/mangle60.C
new file mode 100644
index 000..f7e893a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/abi/mangle60.C
@@ -0,0 +1,20 @@
+// PR c++/51854
+// { dg-options "" }
+
+template  struct A;
+
+template 
+char foo(U, V);
+
+// { dg-final { scan-assembler "_Z3barIiEvP1AIXszcl3foocvT__ELCi0_42" } }
+template 
+void bar(A *);
+
+// { dg-final { scan-assembler "_Z3bazIiEvP1AIXszcl3foocvT__ELCf_" } }
+template 
+void baz(A *);
+
+int main() {
+   bar(0);
+   baz(0);
+}


C++ PATCH for c++/51827 (mangling error with PCH and LTO)

2012-01-16 Thread Jason Merrill
When outputting PCH/LTO, the compiler tries to generate mangled names 
for all decls before discarding language-specific data.  But that 
doesn't make sense for templates, and leads to conflicts in this case. 
Fixed by refusing to mangle templates.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit f984ce6e04c376a9eb7a2a69706489f5aa330573
Author: Jason Merrill 
Date:   Mon Jan 16 14:19:32 2012 -0500

	PR c++/51827
	* mangle.c (mangle_decl): Don't mangle uninstantiated templates.

diff --git a/gcc/cp/mangle.c b/gcc/cp/mangle.c
index 5f2fa15..15b1aca 100644
--- a/gcc/cp/mangle.c
+++ b/gcc/cp/mangle.c
@@ -3330,7 +3330,21 @@ get_mangled_id (tree decl)
 void
 mangle_decl (const tree decl)
 {
-  tree id = get_mangled_id (decl);
+  tree id;
+  bool dep;
+
+  /* Don't bother mangling uninstantiated templates.  */
+  ++processing_template_decl;
+  if (TREE_CODE (decl) == TYPE_DECL)
+dep = dependent_type_p (TREE_TYPE (decl));
+  else
+dep = (DECL_LANG_SPECIFIC (decl) && DECL_TEMPLATE_INFO (decl)
+	   && any_dependent_template_arguments_p (DECL_TI_ARGS (decl)));
+  --processing_template_decl;
+  if (dep)
+return;
+
+  id = get_mangled_id (decl);
   SET_DECL_ASSEMBLER_NAME (decl, id);
 
   if (G.need_abi_warning
diff --git a/gcc/testsuite/g++.dg/pch/mangle1.C b/gcc/testsuite/g++.dg/pch/mangle1.C
new file mode 100644
index 000..504fa2d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pch/mangle1.C
@@ -0,0 +1,3 @@
+// { dg-options -std=c++11 }
+
+#include "mangle1.Hs"
diff --git a/gcc/testsuite/g++.dg/pch/mangle1.Hs b/gcc/testsuite/g++.dg/pch/mangle1.Hs
new file mode 100644
index 000..4d48c2e
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pch/mangle1.Hs
@@ -0,0 +1,8 @@
+// PR c++/51827
+// { dg-options "-flto -std=c++0x" }
+
+template struct S { };
+template struct T {
+  template  T(S );
+};
+inline void f(T) { }


Re: [ARM] Implement vec_perm for NEON

2012-01-16 Thread Ramana Radhakrishnan
On 6 January 2012 04:59, Richard Henderson  wrote:
> Ping.  Reposting the patch as it required updates to HEAD.

This appears to have caused PR51876. Could you take a quick look ?

cheers
Ramana


>
>
> r~


Re: [C++ Patch] PR 51777

2012-01-16 Thread Jason Merrill

OK.

Jason


Re: [C++ Patch] PR 51225

2012-01-16 Thread Jason Merrill
So, the issue here is that fold_non_dependent_expr_sfinae checks 
potential_constant_expression, and doesn't fold anything which isn't one.


One approach would be to only guard cxx_constant_value with 
require_potential_constant_expression within a template.


Another approach would be to check potential_constant_expression at the 
same place that we check type/value_dependent_expression_p, i.e. in 
cp_finish_decl and convert_template_argument.


Jason


[PATCH] Fix PR 33512 Folding of x & ((~x) | y) into x & y on the tree level

2012-01-16 Thread Andrew Pinski
Hi,
  This adds the folding of x & ((~x) | y)) into x & y on the tree
level via fold-const.c
There is already partly done on the RTL level but it would be a good
thing for the tree level also.


OK for 4.8 (yes I know we have not branched yet but I thought I would
send it out so I don't forget about it)?
Bootstrapped and tested on x86_64-linux-gnu with no regressions.

Thanks,
Andrew Pinski

ChangeLog:
* fold-const.c (fold_binary_loc ): Add folding of x
& (~x | y) into x & y.

testsuite/ChangeLog:
* gcc.dg/tree-ssa/andor-3.c: New testcase.
Index: fold-const.c
===
--- fold-const.c(revision 183228)
+++ fold-const.c(working copy)
@@ -11378,6 +11378,43 @@ fold_binary_loc (location_t loc,
  fold_build1_loc (loc, BIT_NOT_EXPR, type, tem),
  fold_convert_loc (loc, type, arg0));
}
+  /* Fold X & (~X | Y) as X & Y. */
+  if (TREE_CODE (arg1) == BIT_IOR_EXPR
+ && TREE_CODE (TREE_OPERAND (arg1, 0)) == BIT_NOT_EXPR
+ && operand_equal_p (arg0, TREE_OPERAND (TREE_OPERAND (arg1, 0), 0), 
0))
+   {
+ tem = fold_convert_loc (loc, type, TREE_OPERAND (arg1, 1));
+ return fold_build2_loc (loc, BIT_AND_EXPR, type,
+ fold_convert_loc (loc, type, arg0), tem);
+   }
+  /* Fold X & (Y | ~X) as X & Y. */
+  if (TREE_CODE (arg1) == BIT_IOR_EXPR
+ && TREE_CODE (TREE_OPERAND (arg1, 1)) == BIT_NOT_EXPR
+ && operand_equal_p (arg0, TREE_OPERAND (TREE_OPERAND (arg1, 1), 0), 
0))
+   {
+ tem = fold_convert_loc (loc, type, TREE_OPERAND (arg1, 0));
+ return fold_build2_loc (loc, BIT_AND_EXPR, type,
+ fold_convert_loc (loc, type, arg0), tem);
+   }
+  /* Fold (~X | Y) & X as X & Y. */
+  if (TREE_CODE (arg0) == BIT_IOR_EXPR
+ && TREE_CODE (TREE_OPERAND (arg0, 0)) == BIT_NOT_EXPR
+ && operand_equal_p (arg1, TREE_OPERAND (TREE_OPERAND (arg0, 0), 0), 
0))
+   {
+ tem = fold_convert_loc (loc, type, TREE_OPERAND (arg0, 1));
+ return fold_build2_loc (loc, BIT_AND_EXPR, type,
+ fold_convert_loc (loc, type, arg1), tem);
+   }
+  /* Fold (Y | ~X) & X as  Y & X. */
+  if (TREE_CODE (arg0) == BIT_IOR_EXPR
+ && TREE_CODE (TREE_OPERAND (arg0, 1)) == BIT_NOT_EXPR
+ && operand_equal_p (arg1, TREE_OPERAND (TREE_OPERAND (arg0, 1), 0), 
0))
+   {
+ tem = fold_convert_loc (loc, type, TREE_OPERAND (arg0, 0));
+ return fold_build2_loc (loc, BIT_AND_EXPR, type,
+ tem, fold_convert_loc (loc, type, arg1));
+   }
+
 
   /* For constants M and N, if M == (1LL << cst) - 1 && (N & M) == M,
 ((A & N) + B) & M -> (A + B) & M
Index: testsuite/gcc.dg/tree-ssa/andor-3.c
===
--- testsuite/gcc.dg/tree-ssa/andor-3.c (revision 0)
+++ testsuite/gcc.dg/tree-ssa/andor-3.c (revision 0)
@@ -0,0 +1,24 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-original" } */
+
+int f(int y, int x)
+{
+  return x & ((~x) | y);
+}
+int f1(int y, int x)
+{
+  return x & (y | (~x));
+}
+int f2(int y, int x)
+{
+  return ((~x) | y) & x;
+}
+int f3(int y, int x)
+{
+  return (y | (~x)) & x;
+}
+
+
+/* { dg-final { scan-tree-dump-times "~x" 0 "original" } } */
+/* { dg-final { scan-tree-dump-times "x \& y" 4 "original" } } */
+/* { dg-final { cleanup-tree-dump "original" } } */