Re: fix left-over debug insns in DCE

[Alexandre Oliva]

On Jun  3, 2011, Eric Botcazou  wrote:

> Does the same logic need to be replicated in all passes that do?  On
> the other hand, these passes call into DF when they remove insns, so
> DF is a central place here.

I went over (again?) a number of passes that call delete_insn directly
or indirectly.  The problem is that, at that point, it's not possible to
tell whether:

- equivalent DEFs are going to be re-emitted at the same place (say, a
split), so debug insns are to be left alone,

- whether they're being re-emitted elsewhere (say a move), so *some*
debug insns may have to be adjusted

- whether DEFs are really being removed, in which case debug temps may
have to be emitted; and the uses, adjusted; and other reaching defs also
followed by binding of the same debug temps

- whether many chained insns are being deleted (say an entire BB, or
part of a BB found to be shared between multiple BBs), in which case
debug insns may have to be left alone or adjusted depending on the
CFG adjustments to be made later

Given this analysis, I'm still of the opinion that passes that remove
insns that may be used by debug insns ought to decide on their own how
to make the adjustments (or not), as they currently do, but that we
should have better shared infrastructure to propagate
defs-to-be-removed, which is currently done in an ad hoc manner in
several passes.

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

Re: fix left-over debug insns in DCE

[Eric Botcazou]

> It might be too late for DF to do anything sensible to preserve the
> debug info rather than just throw it away, as your partial approval
> suggests.

OK, let me think about this a little more.

> Indeed, sorry, I misread it.

Mind installing these bits separately?  My understanding is that they are 
independent correctness fixes.

-- 
Eric Botcazou

Re: [lto] Unify decl and type registration (issue4515186)

[Richard Guenther]

On Fri, 3 Jun 2011, Diego Novillo wrote:

> 
> As discussed in http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00063.html,
> this patch moves decl registration in symbol tables to the LTO front
> end.  It makes type and symbol registration happen at the same time in
> uniquify_nodes.
> 
> Tested with LTO profiledbootstrap on x86_64.  Committed to trunk.
> 
> 
> Diego.
> 
> 
> 2011-06-03  Diego Novillo  
> 
>   * lto-streamer-in.c (get_resolution): Move to lto/lto.c.
>   (lto_register_var_decl_in_symtab): Likewise.
>   (lto_register_function_decl_in_symtab): Likewise.
>   (lto_read_tree): Move VAR_DECL and FUNCTION_DECL registration
>   logic to lto_read_decls.
> 
> lto/ChangeLog
> 
>   * lto.c (get_resolution): Move from lto-streamer-in.c.
>   (lto_register_var_decl_in_symtab): Likewise.
>   (lto_register_function_decl_in_symtab): Likewise.
>   (uniquify_nodes): Call lto_register_var_decl and
>   lto_register_function_decl_in_symtab after reading a new
>   VAR_DECL or FUNCTION_DECL.
> 
> diff --git a/gcc/lto-streamer-in.c b/gcc/lto-streamer-in.c
> index 88966f2..a0c5509 100644
> --- a/gcc/lto-streamer-in.c
> +++ b/gcc/lto-streamer-in.c
> @@ -1533,31 +1533,6 @@ lto_input_constructors_and_inits (struct 
> lto_file_decl_data *file_data,
>  }
>  
>  
> -/* Return the resolution for the decl with index INDEX from DATA_IN. */
> -
> -static enum ld_plugin_symbol_resolution
> -get_resolution (struct data_in *data_in, unsigned index)
> -{
> -  if (data_in->globals_resolution)
> -{
> -  ld_plugin_symbol_resolution_t ret;
> -  /* We can have references to not emitted functions in
> -  DECL_FUNCTION_PERSONALITY at least.  So we can and have
> -  to indeed return LDPR_UNKNOWN in some cases.   */
> -  if (VEC_length (ld_plugin_symbol_resolution_t,
> -   data_in->globals_resolution) <= index)
> - return LDPR_UNKNOWN;
> -  ret = VEC_index (ld_plugin_symbol_resolution_t,
> -data_in->globals_resolution,
> -index);
> -  return ret;
> -}
> -  else
> -/* Delay resolution finding until decl merging.  */
> -return LDPR_UNKNOWN;
> -}
> -
> -
>  /* Unpack all the non-pointer fields of the TS_BASE structure of
> expression EXPR from bitpack BP.  */
>  
> @@ -2473,117 +2448,6 @@ lto_input_tree_pointers (struct lto_input_block *ib, 
> struct data_in *data_in,
>  }
>  
>  
> -/* Register DECL with the global symbol table and change its
> -   name if necessary to avoid name clashes for static globals across
> -   different files.  */
> -
> -static void
> -lto_register_var_decl_in_symtab (struct data_in *data_in, tree decl)
> -{
> -  tree context;
> -
> -  /* Variable has file scope, not local. Need to ensure static variables
> - between different files don't clash unexpectedly.  */
> -  if (!TREE_PUBLIC (decl)
> -  && !((context = decl_function_context (decl))
> -&& auto_var_in_fn_p (decl, context)))
> -{
> -  /* ??? We normally pre-mangle names before we serialize them
> -  out.  Here, in lto1, we do not know the language, and
> -  thus cannot do the mangling again. Instead, we just
> -  append a suffix to the mangled name.  The resulting name,
> -  however, is not a properly-formed mangled name, and will
> -  confuse any attempt to unmangle it.  */
> -  const char *name = IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (decl));
> -  char *label;
> -
> -  ASM_FORMAT_PRIVATE_NAME (label, name, DECL_UID (decl));
> -  SET_DECL_ASSEMBLER_NAME (decl, get_identifier (label));
> -  rest_of_decl_compilation (decl, 1, 0);
> -
> -  VEC_safe_push (tree, gc, lto_global_var_decls, decl);
> -}
> -
> -  /* If this variable has already been declared, queue the
> - declaration for merging.  */
> -  if (TREE_PUBLIC (decl))
> -{
> -  unsigned ix;
> -  if (!lto_streamer_cache_lookup (data_in->reader_cache, decl, &ix))
> - gcc_unreachable ();
> -  lto_symtab_register_decl (decl, get_resolution (data_in, ix),
> - data_in->file_data);
> -}
> -}
> -
> -
> -
> -/* Register DECL with the global symbol table and change its
> -   name if necessary to avoid name clashes for static globals across
> -   different files.  DATA_IN contains descriptors and tables for the
> -   file being read.  */
> -
> -static void
> -lto_register_function_decl_in_symtab (struct data_in *data_in, tree decl)
> -{
> -  /* Need to ensure static entities between different files
> - don't clash unexpectedly.  */
> -  if (!TREE_PUBLIC (decl))
> -{
> -  /* We must not use the DECL_ASSEMBLER_NAME macro here, as it
> -  may set the assembler name where it was previously empty.  */
> -  tree old_assembler_name = decl->decl_with_vis.assembler_name;
> -
> -  /* FIXME lto: We normally pre-mangle names before we serialize
> -  them out.  Here, in lto1, we do not know the language, and
> -  thus cannot 

Re: [PATH] PR/49139 fix always_inline failures diagnostics

[Christian Bruel]

OK, the only difference is that we don't have the node analyzed here, so
externally_visible, etc are not set. With the initial proposal the warning
was emitted only if the function could not be inlined. Now it will be
emitted for each  DECL_COMDAT (decl)&&  !DECL_DECLARED_INLINE_P (decl)) even
if not preemptible, so conservatively we don't want to duplicate the
availability check.


Hm, I'm confused.  Do all DECL_COMDAT functions have the
always_inline attribute set?  I would have expected

+  if (lookup_attribute ("always_inline", DECL_ATTRIBUTES (decl)))
+   {
+ if (!DECL_DECLARED_INLINE_P (decl))
+   warning (OPT_Wattributes,
+"always_inline not declared inline might not be 
inlinable");
+   }



I meant !DECL_COMDAT || !DECL_DECLARED_INLINE_P. but I was 
overprecautious. Didn't realize that member functions was already marked 
with DECLARED_INLINED_P even if not explicitly set. So OK one check is 
enough



do you get excessive warnings with this?



No I don't. That's enough to catch the original issue

Cheers

Christian

Ping Re: Create common hooks structure shared between driver and cc1

[Joseph S. Myers]

Ping.  This patch 
 is pending 
review.

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

Ping Re: Move option-related hooks to common structure

[Joseph S. Myers]

Ping.  This patch 
 is pending 
review (as is the patch on which it depends).

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

Re: [build] Move ENABLE_EXECUTE_STACK to toplevel libgcc

[Rainer Orth]

Paolo Bonzini  writes:

>> * Except for Darwin, the code uses TRAMPOLINE_SIZE.  This only exists in
>>the backend headers.  While it could be duplicated somewhere in the
>>libgcc configury, I'd rather propose that gcc define
>>__TRAMPOLINE_SIZE__ (in gcc/c-family/c-cppbuiltin.c (c_cpp_builtins)
>>to avoid this.  On PowerPC Darwin, one cannot use TRAMPOLINE_SIZE
>>definition right now since the macro calls the rs6000_trampoline_size
>>function in rs6000/rs6000.c.  This would be solved nicely by
>>__TRAMPOLINE_SIZE__.
>
> Good idea.

Included in the revised patch below.  This part will need Joseph's approval.

>> * FreeBSD and Solaris use a check_enabling function to check if
>>__enable_execute_stack needs to run at all.  Initially, I had
>>enable-execute-stack-{freebsd, netbsd, sol2}.c, all including a common
>>enable-execute-stack-mprotect.c to avoid code duplication.  I now
>>consider that ugly and hard to read, and merged everything into a
>>common enable-execute-stack-mprotect.c below.  Right now, the file
>>uses __FreeBSD__, __NetBSD__, and __sun__&&  __svr4__ to select the
>>right code, but this could be autoconf'ed if desired.  There are a
>>couple of FIXME comments in the code.
>
> Please avoid putting the ((constructor)) in common code.  You can put
>
> static int i = 1;
>
> in the #else case, and leave
>
> static int i;
>
> in common code.

Ok, done.

>> * NetBSD is extremely careful to avoid namespace pollution and uses
>>private __sysctl (declared privately) to avoid using getpagesize.
>>Either this is an issue, and we might do something similar on all
>>platforms, or it's not and we should avoid special-casing NetBSD
>>here.
>
> Perhaps it has to do with getpagesize not being available for old versions
> of NetBSD.  No idea, but I'd leave it as is.

I've now included the relevant comments from the old
ENABLE_EXECUTE_STACK definitions where it's claimed this is done for
namespace cleanliness.

>> * Windows32 calls abort when VirtualProtect fails.  With the exception
>>of Darwin and NetBSD, all others call perror, which seems to be
>>frowned upon.  We should be consistent here.
>
> I think it should either abort() or do nothing, consistently across all
> platforms.

I'm going for abort then.  Silently failing here is bad IMO since the
user will have to debug an issue in the runtime library.  libgcc2.c is
already using abort in a couple of places, so there's a precedent.

>> * gcc/config/i386/mingw32.h has
>>
>> #ifdef IN_LIBGCC2
>> #include
>> #endif
>>
>>I strongly suspect that this is only to declare VirtualQuery and
>>VirtualProtect and can go if ENABLE_EXECUTE_STACK is removed?
>
> Yes, it should go.

Done.

>> * Finally, __enable_execute_stack is only used on those NetBSD targets
>> that actually define HAVE_ENABLE_EXECUTE_STACK, while OpenBSD uses it
>> everywhere.  config.host could be simplyfied if NetBSD behaved the
>> same.
>
> I would add it to all NetBSDs, and perhaps all FreeBSDs too?  Do you know
> why SPARC is special?

I've no idea.  Given that OpenBSD uses the same implementation across
all targets, I'm treating the two other BSDs the same now, unless the
maintainers objects.

I've removed a couple of FIXME comments I had in the last version:

* Instead of __FreeBSD__, one could use HAVE_SYSCTLBYNAME instead, but
  that would need a new libgcc config.h header.  In addition, we might
  have to check for kern.stackprot to make sure the code really works.

* Similarly, instead of testing __sun__ && __svr4__, one could check
  _SC_STACK_PROT.

* Last, rather than checking __NetBSD__, one could go for HAVE___SYSCTL.

* __sysctl is currently declared manully.  AFAICS there's no header for
  that.  At least the FreeBSD libc declares it itself in two places:
  lib/libc/sys/stack_protector.c and lib/libc/gen/sysctl.c.

Given that this is closely tied to the various platforms, it seems
appropriate to continue to use the OS defines.

Here's the full patch, regtested without regressions on
i386-pc-solaris2.11.

Ok for mainline?

Rainer


2011-05-29  Rainer Orth  

gcc:
* config/alpha/netbsd.h (ENABLE_EXECUTE_STACK): Remove.
(HAVE_ENABLE_EXECUTE_STACK): Define.
* config/alpha/osf5.h (ENABLE_EXECUTE_STACK): Remove.
(HAVE_ENABLE_EXECUTE_STACK): Define.
* config/darwin.h (ENABLE_EXECUTE_STACK): Remove.
(HAVE_ENABLE_EXECUTE_STACK): Define.
* config/i386/mingw32.h (MINGW_ENABLE_EXECUTE_STACK): Remove.
(ENABLE_EXECUTE_STACK): Remove.
(HAVE_ENABLE_EXECUTE_STACK): Define.
[IN_LIBGCC2]: Don't include .
* config/i386/netbsd-elf.h (ENABLE_EXECUTE_STACK): Remove.
(HAVE_ENABLE_EXECUTE_STACK): Define.
* config/i386/netbsd64.h (ENABLE_EXECUTE_STACK): Remove.
(HAVE_ENABLE_EXECUTE_STACK): Define.
* config/netbsd.h (NETBSD_ENABLE_EXECUTE_STACK): Remove.
* config/openbsd.h (ENABL

Re: [build] Move ENABLE_EXECUTE_STACK to toplevel libgcc

[Paolo Bonzini]

On 06/06/2011 11:17 AM, Rainer Orth wrote:

* Instead of __FreeBSD__, one could use HAVE_SYSCTLBYNAME instead, but
   that would need a new libgcc config.h header.  In addition, we might
   have to check for kern.stackprot to make sure the code really works.

* Similarly, instead of testing __sun__&&  __svr4__, one could check
   _SC_STACK_PROT.

* Last, rather than checking __NetBSD__, one could go for HAVE___SYSCTL.

* __sysctl is currently declared manully.  AFAICS there's no header for
   that.  At least the FreeBSD libc declares it itself in two places:
   lib/libc/sys/stack_protector.c and lib/libc/gen/sysctl.c.

Given that this is closely tied to the various platforms, it seems
appropriate to continue to use the OS defines.


Agreed, it would be a worse can of worms when bootstrapping a target 
(i.e. no target headers are available).


Parts I can approve are good.  Thanks!

Paolo

Re: [PATCH] Fix fold_stmt ICE (PR c++/49264)

[Richard Guenther]

On Fri, Jun 3, 2011 at 3:55 PM, Jakub Jelinek  wrote:
> Hi!
>
> If memcpy is folded into an assignment, that assignment can be for C++
> folded into nothing (if it is copying of 1 byte from or to empty C++ class).
> gimple-fold.c was changed to handle that case in some spots, but not all,
> particularly if that memcpy is the last stmt in a basic block (which can
> happen e.g. during inlining), gsi_stmt (*gsi) in fold_stmt_1 will ICE.
> The gimple-fold.c hunks fix this (and also make sure that even when it
> isn't the last stmt in a bb, we won't try to fold lhs of next stmt
> if it folded/gimplified into nothing).  With that fix the testcase ICEs
> shortly afterwards, the tree-inline.c hunk is supposed to fix that.
> I'd use cgraph_remove_edge there, but I'd have to handle all clones too,
> so I'm calling cgraph_update_edges_for_call_stmt with a dummy stmt
> instead (perhaps NULL could be used instead with adjustment of the
> cgraph_update_edges_for_call_stmt{,_node} routines?).
> The cgraph.c change is just in case the edge isn't there, we'd do useless
> work and crash while doing that.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk/4.6?

Ok, but ... Honza, can you suggest sth better for ...

> 2011-06-03  Jakub Jelinek  
>
>        PR c++/49264
>        * gimple-fold.c (fold_stmt_1): Don't try to fold *& on the lhs
>        if stmt folded into nothing.
>        * tree-inline.c (fold_marked_statements): If a builtin at the
>        end of a bb folded into nothing, just update cgraph edges
>        and move to next bb.
>        * cgraph.c (cgraph_update_edges_for_call_stmt_node): Don't compute
>        count and frequency if new_call is NULL.
>
>        * g++.dg/opt/pr49264.C: New test.
>
> --- gcc/gimple-fold.c.jj        2011-05-24 23:34:28.0 +0200
> +++ gcc/gimple-fold.c   2011-06-03 09:13:34.0 +0200
> @@ -1577,6 +1577,11 @@ fold_stmt_1 (gimple_stmt_iterator *gsi,
>   bool changed = false;
>   gimple stmt = gsi_stmt (*gsi);
>   unsigned i;
> +  gimple_stmt_iterator gsinext = *gsi;
> +  gimple next_stmt;
> +
> +  gsi_next (&gsinext);
> +  next_stmt = gsi_end_p (gsinext) ? NULL : gsi_stmt (gsinext);
>
>   /* Fold the main computation performed by the statement.  */
>   switch (gimple_code (stmt))
> @@ -1665,10 +1670,19 @@ fold_stmt_1 (gimple_stmt_iterator *gsi,
>     default:;
>     }
>
> +  /* If stmt folds into nothing and it was the last stmt in a bb,
> +     don't call gsi_stmt.  */
> +  if (gsi_end_p (*gsi))
> +    {
> +      gcc_assert (next_stmt == NULL);
> +      return changed;
> +    }
> +
>   stmt = gsi_stmt (*gsi);
>
> -  /* Fold *& on the lhs.  */
> -  if (gimple_has_lhs (stmt))
> +  /* Fold *& on the lhs.  Don't do this if stmt folded into nothing,
> +     as we'd changing the next stmt.  */
> +  if (gimple_has_lhs (stmt) && stmt != next_stmt)
>     {
>       tree lhs = gimple_get_lhs (stmt);
>       if (lhs && REFERENCE_CLASS_P (lhs))
> --- gcc/tree-inline.c.jj        2011-06-02 10:15:20.0 +0200
> +++ gcc/tree-inline.c   2011-06-03 09:29:15.0 +0200
> @@ -4108,6 +4108,14 @@ fold_marked_statements (int first, struc
>                  if (fold_stmt (&gsi))
>                    {
>                      gimple new_stmt;
> +                     /* If a builtin at the end of a bb folded into nothing,
> +                        the following loop won't work.  */
> +                     if (gsi_end_p (gsi))
> +                       {
> +                         cgraph_update_edges_for_call_stmt (old_stmt, 
> old_decl,
> +                                                            gimple_build_nop 
> ());

This?  Esp. I don't like the gimple_build_nop () here too much.

Thanks,
Richard.

> +                         break;
> +                       }
>                      if (gsi_end_p (i2))
>                        i2 = gsi_start_bb (BASIC_BLOCK (first));
>                      else
> --- gcc/cgraph.c.jj     2011-05-11 19:39:03.0 +0200
> +++ gcc/cgraph.c        2011-06-03 09:40:02.0 +0200
> @@ -1277,7 +1277,7 @@ cgraph_update_edges_for_call_stmt_node (
>          frequency = e->frequency;
>          cgraph_remove_edge (e);
>        }
> -      else
> +      else if (new_call)
>        {
>          /* We are seeing new direct call; compute profile info based on BB.  
> */
>          basic_block bb = gimple_bb (new_stmt);
> --- gcc/testsuite/g++.dg/opt/pr49264.C.jj       2011-06-03 09:35:50.0 
> +0200
> +++ gcc/testsuite/g++.dg/opt/pr49264.C  2011-06-03 08:50:33.0 +0200
> @@ -0,0 +1,19 @@
> +// PR c++/49264
> +// { dg-do compile }
> +// { dg-options "-O2" }
> +
> +struct B { };
> +struct A { char a[sizeof (B) + 1]; } a;
> +
> +static inline void
> +foo (const B &b)
> +{
> +  __builtin_memcpy (&a, &b, sizeof (b));
> +}
> +
> +void
> +bar ()
> +{
> +  B c;
> +  foo (c);
> +}
>
>        Jakub
>

[build] Use crtfastmath.c on IRIX 6

[Rainer Orth]

On top of the IRIX 6 toplevel libgcc move, I noticed that IRIX doesn't
use crtfastmath.o yet.  This patch corrects this, bootstrapped without
regressions on mips-sgi-irix6.5.

While doing this, I noticed that libgcc/config/mips/t-crtfm is identical
(modulo $(cpu_type)) to the generic libgcc/config/t-crtfm, so I've
changed the other mips targets that used it, too.

Ok for mainline?

Rainer


2011-05-21  Rainer Orth  

gcc:
* config/mips/iris6.h (ENDFILE_SPEC): Use crtfastmath.o if
-ffast-math etc.

libgcc:
* config.host (mips-sgi-irix6.5*): Add t-crtfm to tmake_file.
Add crtfastmath.o to extra_parts.
(mips64*-*-linux*, mips*-*-linux*): Use t-crtfm instead of
mips/t-crtfm.
* config/mips/t-crtfm: Remove.

diff --git a/gcc/config/mips/iris6.h b/gcc/config/mips/iris6.h
--- a/gcc/config/mips/iris6.h
+++ b/gcc/config/mips/iris6.h
@@ -256,7 +256,8 @@ along with GCC; see the file COPYING3.  
 
 #undef ENDFILE_SPEC
 #define ENDFILE_SPEC \
-  "crtend.o%s irix-crtn.o%s \
+  "%{Ofast|ffast-math|funsafe-math-optimizations:crtfastmath.o%s} \
+   crtend.o%s irix-crtn.o%s \
%{!shared: \
  %{mabi=n32:%{mips4:/usr/lib32/mips4/crtn.o%s}\
%{!mips4:/usr/lib32/mips3/crtn.o%s}}\
diff --git a/libgcc/config.host b/libgcc/config.host
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -438,19 +438,19 @@ microblaze*-*-*)
 tmake_file="microblaze/t-microblaze"
;;
 mips-sgi-irix6.5*)
-   tmake_file="mips/t-irix6 t-slibgcc mips/t-slibgcc-irix"
-   extra_parts="crtbegin.o crtend.o irix-crti.o irix-crtn.o"
+   tmake_file="mips/t-irix6 t-crtfm t-slibgcc mips/t-slibgcc-irix"
+   extra_parts="crtbegin.o crtend.o crtfastmath.o irix-crti.o irix-crtn.o"
;;
 mips*-*-netbsd*)   # NetBSD/mips, either endian.
;;
 mips64*-*-linux*)
extra_parts="$extra_parts crtfastmath.o"
-   tmake_file="{$tmake_file} mips/t-crtfm"
+   tmake_file="{$tmake_file} t-crtfm"
md_unwind_header=mips/linux-unwind.h
;;
 mips*-*-linux*)# Linux MIPS, either endian.
extra_parts="$extra_parts crtfastmath.o"
-   tmake_file="{$tmake_file} mips/t-crtfm"
+   tmake_file="{$tmake_file} t-crtfm"
md_unwind_header=mips/linux-unwind.h
;;
 mips*-*-openbsd*)
diff --git a/libgcc/config/mips/t-crtfm b/libgcc/config/mips/t-crtfm
deleted file mode 100644
--- a/libgcc/config/mips/t-crtfm
+++ /dev/null
@@ -1,3 +0,0 @@
-crtfastmath.o: $(gcc_srcdir)/config/mips/crtfastmath.c
-   $(gcc_compile) -c $(gcc_srcdir)/config/mips/crtfastmath.c
-


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

Re: [PATCH] Only run pr48377.c testcase on i?86/x86_64

[Richard Guenther]

On Fri, Jun 3, 2011 at 3:59 PM, Jakub Jelinek  wrote:
> Hi!
>
> This limits this testcase to i?86/x86_64 (moving to gcc.target/ would
> be harder because it relies on all the weirdo vectorization options to be
> passed), because apparently on strict alignment targets we don't handle
> aligned (1) non-aggregates correctly.  Or should it be instead xfailed
> just on selected strict-aligned targets?

This has come up in the past, I think we should have an
strict-align target capability in our dejagnu harness (possibly
just white-listing all patterns we know).  So we can
dg-skip this test for strict-align ones.  Would you mind implementing
that?

Thanks,
Richard.

> 2011-06-03  Jakub Jelinek  
>
>        PR tree-optimization/48377
>        * gcc.dg/vect/pr48377.c: Only run the test to i?86/x86_64.
>
> --- gcc/testsuite/gcc.dg/vect/pr48377.c.jj      2011-05-02 18:39:10.0 
> +0200
> +++ gcc/testsuite/gcc.dg/vect/pr48377.c 2011-06-03 13:19:53.0 +0200
> @@ -1,4 +1,5 @@
>  /* PR tree-optimization/48377 */
> +/* { dg-do run { target i?86-*-* x86_64-*-* } } */
>
>  typedef unsigned int U __attribute__((__aligned__ (1), __may_alias__));
>
>
>        Jakub
>

Re: [vta, graphite?] propagate degenerate phi nodes into debug stmts

[Richard Guenther]

On Fri, Jun 3, 2011 at 4:33 PM, Alexandre Oliva  wrote:
> According to http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00999.html
> on Nov 19, 2009, Richard Guenther  wrote:
>
>> On Thu, Nov 19, 2009 at 4:05 AM, Alexandre Oliva  wrote:
>>> On Nov 17, 2009, Richard Guenther  wrote:
>>>
>> This looks odd.  SSA DEF operand iteration should walk the PHI defs
>> as well, so the change should not be necessary.
>>>
> I thought so, too, but by the time we get there, the operands of the PHI
> stmt have already been disconnected.
>>>
 It shouldn't be.  Please try to figure out why instead.
>>>
>>> Gotta use a different FOR_EACH macro to handle PHI nodes.
>>>
>>> s/FOR_EACH_SSA_DEF_OPERAND/FOR_EACH_PHI_OR_STMT_DEF/ fixed it.
>>>
>>> In order to make sure no other such mistakes had been made in GCC, I
>>> added an assertion check in the iterator initializer and adjusted the
>>> uses of GIMPLE_PHI nodes that triggered the assertion, but that would
>>> have done nothing whatsoever in its absence.  I haven't looked into
>>> whether doing nothing is correct.
>>>
>>> Should I check this in?
>
>> I think we should rather let num_ssa_operands and delink_stmt_imm_use
>> ICE on PHIs, but I'd rather do this in stage1 - can you queue this
>> patch until then?
>
> You meant 4.6 stage1, but I missed it.  How's it for 4.7 stage1?
> Regstrapped on x86_64-linux-gnu and i686-linux-gnu.

Isn't exactly ICEing for num_ssa_operands/delink_stmt_imm_use.

So, the op_iter_init change is ok, the other two not - they should
either ICE or work for PHIs (by using FOR_EACH_PHI_OR_STMT_USE
in them).

Thanks,
Richard.

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

Re: don't dump decl_uid with TDF_NOUID

[Richard Guenther]

On Fri, Jun 3, 2011 at 4:17 PM, Alexandre Oliva  wrote:
> A recent change introduced decl_uid in the “;; Function ” header in dump
> files.  This breaks -fcompare-debug (and bootstrap-debug-lean), because
> decl uids aren't kept in sync between -g and non-g compilations.
>
> This patch rearranges the header so that decl_uid is omitted when
> dumping with NOUID, and it prints the header for the -fcompare-debug
> final dump with NOUID.
>
> Regstrapped on x86_64-linux-gnu and i686-linux-gnu.  Ok?

Ok.

Thanks,
Richard.

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

Re: [testsuite] Run TLS torture tests with -fpic etc.

[Rainer Orth]

Jakub Jelinek  writes:

> On Fri, Jun 03, 2011 at 09:38:31PM +0200, Rainer Orth wrote:
>> Rainer Orth  writes:
>> Jakub, any suggestion how to properly test for -fpie/-fPIE support?
>> Otherwise, I'll remove that part of the patch for now and just commit
>> the -fpic/-fPIC one.
>
> You want to compile/link the program with -pie -fpie rather than just -fpie,
> if it links, otherwise you are testing just linking PIC code into normal
> executables.

Ok, thanks.  Unfortunately, this didn't work out of the box since for
targets where the linker doesn't support -pie, gcc silently ignores it
which I think is bad style.

The following patch corrects this by rejecting -pie in this case.  I've
also added a effective-target keyword pie for testsuite use, both below
and in the revised TLS torture tests to be submitted separately.

I didn't introduce a separte fpie keyword since e.g. gcc.dg/tls/pie-1.c
uses fpic for that purpose, but maybe I should?

One other question: gcc.target/i386/pr39013-[12].c is currently
restricted to *-*-linux*.  Any particular reason for that?

Bootstrapped without regressions on i386-pc-solaris2.11 with Sun ld (no
-pie support, pie-link becomes UNSUPPORTED) and with GNU ld 2.21 (-pie
support, 32-bit pie-link works, 64-bit pie-link becomes unsupported:

/vol/gcc/bin/gld-2.21: /usr/lib/amd64/crt1.o: relocation R_X86_64_32S against 
`_DYNAMIC' can not be used when making a shared object; recompile with -fPIC
/usr/lib/amd64/crt1.o: could not read symbols: Bad value

).  Ok for mainline?

Thanks.
Rainer


2011-06-04  Rainer Orth  

gcc:
* gcc.c [!HAVE_LD_PIE] (LINK_PIE_SPEC): Reject -pie.
* doc/sourcebuild.texi (Effective-Target Keywords, pie): Document it.

gcc/testsuite:
* lib/target-supports.exp (check_effective_target_pie): New proc.
* gcc.dg/pie-link.c: Use target pie.
Add -pie to dg-options.

diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -1782,6 +1782,9 @@ Target defines @code{PCC_BITFIELD_TYPE_M
 @item pe_aligned_commons
 Target supports @option{-mpe-aligned-commons}.
 
+@item pie
+Target supports @option{-pie}, @option{-fpie} and @option{-fPIE}.
+
 @item section_anchors
 Target supports section anchors.
 
diff --git a/gcc/gcc.c b/gcc/gcc.c
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -612,7 +612,7 @@ proper position among the other output f
 #ifdef HAVE_LD_PIE
 #define LINK_PIE_SPEC "%{pie:-pie} "
 #else
-#define LINK_PIE_SPEC "%{pie:} "
+#define LINK_PIE_SPEC "%{pie:%e-pie is not supported in this configuration} "
 #endif
 #endif
 
diff --git a/gcc/testsuite/gcc.dg/pie-link.c b/gcc/testsuite/gcc.dg/pie-link.c
--- a/gcc/testsuite/gcc.dg/pie-link.c
+++ b/gcc/testsuite/gcc.dg/pie-link.c
@@ -1,5 +1,5 @@
-/* { dg-do link { target *-*-darwin[912]* *-*-linux* } } */
-/* { dg-options "-fpie" } */
+/* { dg-do link { target pie } } */
+/* { dg-options "-pie -fpie" } */
 
 int main(void)
 {
diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -788,6 +788,18 @@ proc check_effective_target_fpic { } {
 return 0
 }
 
+# Return 1 if -pie, -fpie and -fPIE are supported, as in no warnings or errors
+# emitted, 0 otherwise.
+
+proc check_effective_target_pie { } {
+if [check_no_compiler_messages pie executable {
+   int main (void) { return 0; }
+} "-pie -fpie"] {
+   return 1
+}
+return 0
+}
+
 # Return true if the target supports -mpaired-single (as used on MIPS).
 
 proc check_effective_target_mpaired_single { } {


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

Re: [build] Use crtfastmath.c on IRIX 6

[Paolo Bonzini]

On 06/06/2011 11:32 AM, Rainer Orth wrote:

On top of the IRIX 6 toplevel libgcc move, I noticed that IRIX doesn't
use crtfastmath.o yet.  This patch corrects this, bootstrapped without
regressions on mips-sgi-irix6.5.

While doing this, I noticed that libgcc/config/mips/t-crtfm is identical
(modulo $(cpu_type)) to the generic libgcc/config/t-crtfm, so I've
changed the other mips targets that used it, too.

Ok for mainline?

Rainer


2011-05-21  Rainer Orth

gcc:
* config/mips/iris6.h (ENDFILE_SPEC): Use crtfastmath.o if
-ffast-math etc.

libgcc:
* config.host (mips-sgi-irix6.5*): Add t-crtfm to tmake_file.
Add crtfastmath.o to extra_parts.
(mips64*-*-linux*, mips*-*-linux*): Use t-crtfm instead of
mips/t-crtfm.
* config/mips/t-crtfm: Remove.

diff --git a/gcc/config/mips/iris6.h b/gcc/config/mips/iris6.h
--- a/gcc/config/mips/iris6.h
+++ b/gcc/config/mips/iris6.h
@@ -256,7 +256,8 @@ along with GCC; see the file COPYING3.

  #undef ENDFILE_SPEC
  #define ENDFILE_SPEC \
-  "crtend.o%s irix-crtn.o%s \
+  "%{Ofast|ffast-math|funsafe-math-optimizations:crtfastmath.o%s} \
+   crtend.o%s irix-crtn.o%s \
 %{!shared: \
   %{mabi=n32:%{mips4:/usr/lib32/mips4/crtn.o%s}\
 %{!mips4:/usr/lib32/mips3/crtn.o%s}}\
diff --git a/libgcc/config.host b/libgcc/config.host
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -438,19 +438,19 @@ microblaze*-*-*)
  tmake_file="microblaze/t-microblaze"
;;
  mips-sgi-irix6.5*)
-   tmake_file="mips/t-irix6 t-slibgcc mips/t-slibgcc-irix"
-   extra_parts="crtbegin.o crtend.o irix-crti.o irix-crtn.o"
+   tmake_file="mips/t-irix6 t-crtfm t-slibgcc mips/t-slibgcc-irix"
+   extra_parts="crtbegin.o crtend.o crtfastmath.o irix-crti.o irix-crtn.o"
;;
  mips*-*-netbsd*)  # NetBSD/mips, either endian.
;;
  mips64*-*-linux*)
extra_parts="$extra_parts crtfastmath.o"
-   tmake_file="{$tmake_file} mips/t-crtfm"
+   tmake_file="{$tmake_file} t-crtfm"
md_unwind_header=mips/linux-unwind.h
;;
  mips*-*-linux*)   # Linux MIPS, either endian.
extra_parts="$extra_parts crtfastmath.o"
-   tmake_file="{$tmake_file} mips/t-crtfm"
+   tmake_file="{$tmake_file} t-crtfm"
md_unwind_header=mips/linux-unwind.h
;;
  mips*-*-openbsd*)
diff --git a/libgcc/config/mips/t-crtfm b/libgcc/config/mips/t-crtfm
deleted file mode 100644
--- a/libgcc/config/mips/t-crtfm
+++ /dev/null
@@ -1,3 +0,0 @@
-crtfastmath.o: $(gcc_srcdir)/config/mips/crtfastmath.c
-   $(gcc_compile) -c $(gcc_srcdir)/config/mips/crtfastmath.c
-


Ok.

Paolo

Re: [PATCH] Only run pr48377.c testcase on i?86/x86_64

[Rainer Orth]

Richard Guenther  writes:

> On Fri, Jun 3, 2011 at 3:59 PM, Jakub Jelinek  wrote:
>> Hi!
>>
>> This limits this testcase to i?86/x86_64 (moving to gcc.target/ would
>> be harder because it relies on all the weirdo vectorization options to be
>> passed), because apparently on strict alignment targets we don't handle
>> aligned (1) non-aggregates correctly.  Or should it be instead xfailed
>> just on selected strict-aligned targets?
>
> This has come up in the past, I think we should have an
> strict-align target capability in our dejagnu harness (possibly
> just white-listing all patterns we know).  So we can
> dg-skip this test for strict-align ones.  Would you mind implementing
> that?

That list is quite long, though: there are currently 28 instances of

#define STRICT_ALIGNMENT 1

in gcc/config, with a couple of others being variable.  Wouldn't it be
better to have a proper testcase instead?

Rainer

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

Re: [ARM] TLS Descriptor support

[Nathan Sidwell]

On 06/03/11 23:50, Ramana Radhakrishnan wrote:


How are things handled for Thumb1 in case someone builds a routine for
Thumb1 which uses tlsdesc ? I went and read the doc and didn't see any
difference between T1 and T2 in the specification . Would the linker
and everyone else do the right thing or should we have the blx
instruction for TARGET_THUMB and v5t . I have a feeling that I'm
missing something here .


You're asking how does the thumb1 bl instruction get handled?  The linker emits 
a veneer -- a variant of the t<->a veneers it already deals with.


If you're asking something else, can you rephrase the question?

nathan

--
Nathan Sidwell

Re: [ARM] TLS Descriptor support

[Ramana Radhakrishnan]

> If you're asking something else, can you rephrase the question?

Sorry if I wasn't too clear.  My question really should have read "why
do we have to special case Thumb2" ? The linker should be able to
veneer the t-> a calls either through the veneering sequence (in case
of T1 without blx) or convert the bl to a blx (modulo the case with
out of range branches). As I said I'm probably missing something here.

cheers
Ramana

>
> nathan
>
> --
> Nathan Sidwell
>
>

Re: [PATH] PR/49139 fix always_inline failures diagnostics

[Richard Guenther]

On Mon, Jun 6, 2011 at 10:58 AM, Christian Bruel  wrote:
>
>
>>> OK, the only difference is that we don't have the node analyzed here, so
>>> externally_visible, etc are not set. With the initial proposal the
>>> warning
>>> was emitted only if the function could not be inlined. Now it will be
>>> emitted for each  DECL_COMDAT (decl)&&  !DECL_DECLARED_INLINE_P (decl))
>>> even
>>> if not preemptible, so conservatively we don't want to duplicate the
>>> availability check.
>>
>> Hm, I'm confused.  Do all DECL_COMDAT functions have the
>> always_inline attribute set?  I would have expected
>>
>> +      if (lookup_attribute ("always_inline", DECL_ATTRIBUTES (decl)))
>> +       {
>> +         if (!DECL_DECLARED_INLINE_P (decl))
>> +           warning (OPT_Wattributes,
>> +                    "always_inline not declared inline might not be
>> inlinable");
>> +       }
>>
>
> I meant !DECL_COMDAT || !DECL_DECLARED_INLINE_P. but I was overprecautious.
> Didn't realize that member functions was already marked with
> DECLARED_INLINED_P even if not explicitly set. So OK one check is enough
>
>> do you get excessive warnings with this?
>>
>
> No I don't. That's enough to catch the original issue

Ok.  The patch is ok with the !DECL_DECLARED_INLINE_P check
if it still passes bootstrap & regtest.

Thanks,
Richard.

> Cheers
>
> Christian
>

Re: [ARM] TLS Descriptor support

[Nathan Sidwell]

On 06/06/11 10:53, Ramana Radhakrishnan wrote:

If you're asking something else, can you rephrase the question?


Sorry if I wasn't too clear.  My question really should have read "why
do we have to special case Thumb2" ? The linker should be able to
veneer the t->  a calls either through the veneering sequence (in case
of T1 without blx) or convert the bl to a blx (modulo the case with
out of range branches). As I said I'm probably missing something here.


Maybe we don't.  It just seems neater to emit blx on arches that have it.

nathan
--
Nathan Sidwell

[Ada] Fix ICE on Taft amendment types with -g

[Eric Botcazou]

Taft amendment types are incomplete types declared in a package spec whose 
completion is declared in the body.  This means that other units don't have 
access to their full view at all and treat them as incomplete types.  This is 
problematic when debugging information is requested because their compilation 
might be finalized in the wrong context, i.e. from within a subprogram.

Fixed thusly, tested on i586-suse-linux, applied on the mainline.


2011-06-06  Eric Botcazou  

* gcc-interface/utils.c: Include diagnostic.h.
(gnat_write_global_declarations): Output debug information for all
global type declarations before finalizing the compilation unit.
* gcc-interface/Make-lang.in (ada/utils.o): Add dependency.


2011-06-06  Eric Botcazou  

* gnat.dg/test_tamdt.adb: Rename to...
* gnat.dg/taft_type1.adb: ...this.
* gnat.dg/tamdt.ad[sb]: Rename to...
* gnat.dg/taft_type1_pkg1.ad[sb]: ...this.
* gnat.dg/tamdt_aux.ads: Rename to...
* gnat.dg/taft_type1_pkg2.ads: ...this.
* gnat.dg/taft_type2.ad[sb]: New test.
* gnat.dg/taft_type2_pkg.ads: New helper.
* gnat.dg/taft_type3.adb: New test.
* gnat.dg/taft_type3_pkg.ads: New helper.


-- 
Eric Botcazou
-- { dg-do compile }
-- { dg-options "-g" }

with Taft_Type2_Pkg; use Taft_Type2_Pkg;

package body Taft_Type2 is

   procedure Proc is
  A : T;

  function F return T is
 My_T : T;
  begin
 My_T := Open;
 return My_T;
  end;

   begin
  A := F;
   end;

end Taft_Type2;
package Taft_Type2 is

   procedure Proc;

end Taft_Type2;
package Taft_Type2_Pkg  is

   type T is private;

   function Open return T;

private

   type Buffer_T;
   type T is access Buffer_T;

end Taft_Type2_Pkg;
-- { dg-do compile }
-- { dg-options "-g" }

with Taft_Type3_Pkg; use Taft_Type3_Pkg;

procedure Taft_Type3 is

  subtype S is String (1..32);

  Empty : constant S := (others => ' ');

  procedure Proc (Data : in out T) is begin null; end;

  task type Task_T is
entry Send (Data : in out T);
  end;

  task body Task_T is
type List_T is array (1 .. 4) of S;
L : List_T := (others => Empty);
  begin
accept Send (Data : in out T) do
  Proc (Data);
end;
  end;

begin
  null;
end;
package Taft_Type3_Pkg is

  type T is private;

private

  type Buffer_T;
  type T is access Buffer_T;

end Taft_Type3_Pkg;
Index: gcc-interface/utils.c
===
--- gcc-interface/utils.c	(revision 174631)
+++ gcc-interface/utils.c	(working copy)
@@ -38,6 +38,7 @@
 #include "target.h"
 #include "langhooks.h"
 #include "cgraph.h"
+#include "diagnostic.h"
 #include "tree-dump.h"
 #include "tree-inline.h"
 #include "tree-iterator.h"
@@ -4756,6 +4757,9 @@ static GTY (()) tree dummy_global;
 void
 gnat_write_global_declarations (void)
 {
+  unsigned int i;
+  tree iter;
+
   /* If we have declared types as used at the global level, insert them in
  the global hash table.  We use a dummy variable for this purpose.  */
   if (!VEC_empty (tree, types_used_by_cur_var_decl))
@@ -4773,13 +4777,28 @@ gnat_write_global_declarations (void)
 	}
 }
 
+  /* Output debug information for all global type declarations first.  This
+ ensures that global types whose compilation hasn't been finalized yet,
+ for example pointers to Taft amendment types, have their compilation
+ finalized in the right context.  */
+  FOR_EACH_VEC_ELT (tree, global_decls, i, iter)
+if (TREE_CODE (iter) == TYPE_DECL)
+  debug_hooks->global_decl (iter);
+
   /* Proceed to optimize and emit assembly.
  FIXME: shouldn't be the front end's responsibility to call this.  */
   cgraph_finalize_compilation_unit ();
 
-  /* Emit debug info for all global declarations.  */
-  emit_debug_global_declarations (VEC_address (tree, global_decls),
-  VEC_length (tree, global_decls));
+  /* After cgraph has had a chance to emit everything that's going to
+ be emitted, output debug information for the rest of globals.  */
+  if (!seen_error ())
+{
+  timevar_push (TV_SYMOUT);
+  FOR_EACH_VEC_ELT (tree, global_decls, i, iter)
+	if (TREE_CODE (iter) != TYPE_DECL)
+	  debug_hooks->global_decl (iter);
+  timevar_pop (TV_SYMOUT);
+}
 }
 
 /* 
Index: gcc-interface/Make-lang.in
===
--- gcc-interface/Make-lang.in	(revision 174631)
+++ gcc-interface/Make-lang.in	(working copy)
@@ -1237,7 +1237,7 @@ ada/trans.o : ada/gcc-interface/trans.c
 
 ada/utils.o : ada/gcc-interface/utils.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \
$(TM_H) $(TREE_H) $(FLAGS_H) toplev.h $(RTL_H) output.h debug.h convert.h \
-   $(TARGET_H) function.h langhooks.h $(CGRAPH_H) \
+   $(TARGET_H) function.h langhooks.h $(CGRAPH_H) $(DIAGNOSTIC_H) \
$(TREE_DUMP_H) $(TREE_INLINE_H) tree-iterat

Re: fix left-over debug insns in DCE

[Alexandre Oliva]

On Jun  6, 2011, Eric Botcazou  wrote:

>> Indeed, sorry, I misread it.

> Mind installing these bits separately?

Nope.  Testing it separately now.

> My understanding is that they are 
> independent correctness fixes.

Yeah, I guess they are.  They won't make debug info any worse, although
they may remove incorrect debug info, and they won't preserve debug info
that we currently discard, which the other part of the patch retains.

Here's what I'm going to check in if regstrapping succeeds.

for  gcc/ChangeLog
from  Alexandre Oliva  

	* dce.c (reset_unmarked_insns_debug_uses): New.
	(delete_unmarked_insns): Skip debug insns.
	(prescan_insns_for_dce): Likewise.
	(rest_of_handle_ud_dce): Reset debug uses of removed sets.
	* reg-stack.c (subst_stack_regs_in_debug_insn): Signal when no
	active reg can be found.
	(subst_all_stack_regs_in_debug_insn): New.  Reset debug insn then.
	(convert_regs_1): Use it.

Index: gcc/dce.c
===
--- gcc/dce.c.orig	2011-05-26 05:03:08.552989108 -0300
+++ gcc/dce.c	2011-05-27 03:09:07.711388764 -0300
@@ -493,6 +493,43 @@ remove_reg_equal_equiv_notes_for_defs (r
 remove_reg_equal_equiv_notes_for_regno (DF_REF_REGNO (*def_rec));
 }
 
+/* Scan all BBs for debug insns and reset those that reference values
+   defined in unmarked insns.  */
+
+static void
+reset_unmarked_insns_debug_uses (void)
+{
+  basic_block bb;
+  rtx insn, next;
+
+  FOR_EACH_BB_REVERSE (bb)
+FOR_BB_INSNS_REVERSE_SAFE (bb, insn, next)
+  if (DEBUG_INSN_P (insn))
+	{
+	  df_ref *use_rec;
+
+	  for (use_rec = DF_INSN_USES (insn); *use_rec; use_rec++)
+	{
+	  df_ref use = *use_rec;
+	  struct df_link *defs;
+	  for (defs = DF_REF_CHAIN (use); defs; defs = defs->next)
+		{
+		  rtx insn;
+		  if (DF_REF_IS_ARTIFICIAL (defs->ref))
+		continue;
+		  insn = DF_REF_INSN (defs->ref);
+		  if (!marked_insn_p (insn))
+		break;
+		}
+	  if (!defs)
+		continue;
+	  /* ??? FIXME could we propagate the values assigned to
+		 each of the DEFs?  */
+	  INSN_VAR_LOCATION_LOC (insn) = gen_rtx_UNKNOWN_VAR_LOC ();
+	  df_insn_rescan_debug_internal (insn);
+	}
+	}
+}
 
 /* Delete every instruction that hasn't been marked.  */
 
@@ -505,7 +542,7 @@ delete_unmarked_insns (void)
 
   FOR_EACH_BB_REVERSE (bb)
 FOR_BB_INSNS_REVERSE_SAFE (bb, insn, next)
-  if (INSN_P (insn))
+  if (NONDEBUG_INSN_P (insn))
 	{
 	  /* Always delete no-op moves.  */
 	  if (noop_move_p (insn))
@@ -579,7 +616,7 @@ prescan_insns_for_dce (bool fast)
   FOR_EACH_BB (bb)
 {
   FOR_BB_INSNS_REVERSE_SAFE (bb, insn, prev)
-	if (INSN_P (insn))
+	if (NONDEBUG_INSN_P (insn))
 	  {
 	/* Don't mark argument stores now.  They will be marked
 	   if needed when the associated CALL is marked.  */
@@ -713,6 +750,9 @@ rest_of_handle_ud_dce (void)
 }
   VEC_free (rtx, heap, worklist);
 
+  if (MAY_HAVE_DEBUG_INSNS)
+reset_unmarked_insns_debug_uses ();
+
   /* Before any insns are deleted, we must remove the chains since
  they are not bidirectional.  */
   df_remove_problem (df_chain);
Index: gcc/reg-stack.c
===
--- gcc/reg-stack.c.orig	2011-05-26 05:03:08.554989112 -0300
+++ gcc/reg-stack.c	2011-05-27 03:11:23.756589358 -0300
@@ -1333,6 +1333,11 @@ subst_stack_regs_in_debug_insn (rtx *loc
 return 0;
 
   hard_regno = get_hard_regnum (regstack, *loc);
+
+  /* If we can't find an active register, reset this debug insn.  */
+  if (hard_regno == -1)
+return 1;
+
   gcc_assert (hard_regno >= FIRST_STACK_REG);
 
   replace_reg (loc, hard_regno);
@@ -1340,6 +1345,23 @@ subst_stack_regs_in_debug_insn (rtx *loc
   return -1;
 }
 
+/* Substitute hardware stack regs in debug insn INSN, using stack
+   layout REGSTACK.  If we can't find a hardware stack reg for any of
+   the REGs in it, reset the debug insn.  */
+
+static void
+subst_all_stack_regs_in_debug_insn (rtx insn, struct stack_def *regstack)
+{
+  int ret = for_each_rtx (&INSN_VAR_LOCATION_LOC (insn),
+			  subst_stack_regs_in_debug_insn,
+			  regstack);
+
+  if (ret == 1)
+INSN_VAR_LOCATION_LOC (insn) = gen_rtx_UNKNOWN_VAR_LOC ();
+  else
+gcc_checking_assert (ret == 0);
+}
+
 /* Substitute new registers in PAT, which is part of INSN.  REGSTACK
is the current register layout.  Return whether a control flow insn
was deleted in the process.  */
@@ -2947,8 +2969,7 @@ convert_regs_1 (basic_block block)
 	debug_insns_with_starting_stack++;
 	  else
 	{
-	  for_each_rtx (&PATTERN (insn), subst_stack_regs_in_debug_insn,
-			®stack);
+	  subst_all_stack_regs_in_debug_insn (insn, ®stack);
 
 	  /* Nothing must ever die at a debug insn.  If something
 		 is referenced in it that becomes dead, it should have
@@ -2986,8 +3007,7 @@ convert_regs_1 (basic_block block)
 	continue;
 
 	  debug_insns_with_starting_stack--;
-	  for_each_rtx (&PATTERN (insn), subst_stack_reg

[Ada] Fix ICE on deferred constant with tagged type

[Eric Botcazou]

This is again the compiler trying to create a temporary for a VIEW_CONVERT_EXPR 
and the type doesn't allow it.  Fixed by not generating the VIEW_CONVERT_EXPR 
in the first place.

Tested on i586-suse-linux, applied on the mainline


2011-06-06  Eric Botcazou  

* gcc-interface/trans.c (Identifier_to_gnu): Also handle deferred
constants whose full view has discriminants specially.


2011-06-06  Eric Botcazou  

* gnat.dg/deferred_const4.ad[sb]: New test.
* gnat.dg/deferred_const4_pkg.ads: New helper.


-- 
Eric Botcazou
Index: gcc-interface/trans.c
===
--- gcc-interface/trans.c	(revision 174631)
+++ gcc-interface/trans.c	(working copy)
@@ -906,9 +906,11 @@ Identifier_to_gnu (Node_Id gnat_node, tr
  attribute Position, generated for dispatching code (see Make_DT in
  exp_disp,adb). In that case we need the type itself, not is parent,
  in particular if it is a derived type  */
-  if (Is_Private_Type (gnat_temp_type)
-  && Has_Unknown_Discriminants (gnat_temp_type)
-  && Ekind (gnat_temp) == E_Constant
+  if (Ekind (gnat_temp) == E_Constant
+  && Is_Private_Type (gnat_temp_type)
+  && (Has_Unknown_Discriminants (gnat_temp_type)
+	  || (Present (Full_View (gnat_temp_type))
+ 	  && Has_Discriminants (Full_View (gnat_temp_type
   && Present (Full_View (gnat_temp)))
 {
   gnat_temp = Full_View (gnat_temp);
-- { dg-do compile }

package body Deferred_Const4 is

  function F return My_Q.T is
R : My_Q.T;
  begin
R := My_Q.Null_T;
return R;
  end;

end Deferred_Const4;
generic

  type User_T is private;

package Deferred_Const4_Pkg is

  type T is private;

  Null_T : constant T;

private

  type T (Valid : Boolean := False) is record
case Valid is
  when True  => Value : User_T;
  when False => null;
end case;
  end record;

  Null_T : constant T := (Valid => False);

end Deferred_Const4_Pkg;
with Deferred_Const4_Pkg;

package Deferred_Const4 is

  type R1 is tagged record
I1 : Integer;
  end record;

  type R2 is new R1 with record
I2 : Integer;
  end record;

  package My_Q is new Deferred_Const4_Pkg (R2);

  function F return My_Q.T;

end Deferred_Const4;

[Ada] Fix ICE on conditional expression with unconstrained type

[Eric Botcazou]

This is again the compiler trying to create a temporary, for an unconstrained 
type hence whose size isn't fixed.  Fixed by not creating the temporary as it 
is superfluous here.

Tested on i586-suse-linux, applied on the mainline


2011-06-06  Eric Botcazou  

* gcc-interface/utils2.c (gnat_stabilize_reference) :
Fix thinko.


2011-06-06  Eric Botcazou  

* gnat.dg/specs/cond_expr1.ads: New test.


-- 
Eric Botcazou
-- { dg-do compile }
-- { dg-options "-gnat12 -gnato" }

package Cond_Expr1 is

   function Tail (S : String) return String is
 (if S'Last <= S'First then "" else S (S'First + 1 .. S'Last));

end Cond_Expr1;
Index: gcc-interface/utils2.c
===
--- gcc-interface/utils2.c	(revision 174631)
+++ gcc-interface/utils2.c	(working copy)
@@ -2518,8 +2518,8 @@ gnat_stabilize_reference (tree ref, bool
   result = build2 (COMPOUND_EXPR, type,
 		   gnat_stabilize_reference (TREE_OPERAND (ref, 0), force,
 		 success),
-		   gnat_stabilize_reference_1 (TREE_OPERAND (ref, 1),
-		   force));
+		   gnat_stabilize_reference (TREE_OPERAND (ref, 1), force,
+		 success));
   break;
 
 case CONSTRUCTOR:

[Ada] Propagate TREE_THIS_NOTRAP flag

[Eric Botcazou]

Self-explanatory.  Tested on i586-suse-linux, applied on the mainline.


2011-06-06  Eric Botcazou  

* gcc-interface/utils2.c (gnat_stabilize_reference): Propagate
TREE_THIS_NOTRAP flag.


-- 
Eric Botcazou
Index: gcc-interface/utils2.c
===
--- gcc-interface/utils2.c	(revision 174690)
+++ gcc-interface/utils2.c	(working copy)
@@ -2570,5 +2570,8 @@ gnat_stabilize_reference (tree ref, bool
   TREE_SIDE_EFFECTS (result) |= TREE_SIDE_EFFECTS (ref);
   TREE_THIS_VOLATILE (result) = TREE_THIS_VOLATILE (ref);
 
+  if (code == INDIRECT_REF || code == ARRAY_REF || code == ARRAY_RANGE_REF)
+TREE_THIS_NOTRAP (result) = TREE_THIS_NOTRAP (ref);
+
   return result;
 }

Re: [PATCH] gimple_val_nonnegative_real_p (PR46728 patch 7 of 7)

[Richard Guenther]

On Wed, Jun 1, 2011 at 9:27 PM, William J. Schmidt
 wrote:
> This patch cleans up the FIXME logic in gimple_expand_builtin_pow by
> introducing gimple_val_nonnegative_real_p for the same purpose that
> tree_expr_nonnegative_p served in the expand logic.  This completes the
> work for PR46728.
>
> Bootstrapped/regtested on powerpc64-linux.
>
>
> 2011-06-01  Bill Schmidt  
>
>        PR tree-optimization/46728
>        * tree-ssa-math-opts.c (gimple_expand_builtin_pow): Change FIXME
>        to use gimple_val_nonnegative_real_p.
>        * gimple-fold.c (gimple_val_nonnegative_real_p): New function.
>        * gimple.h (gimple_val_nonnegative_real_p): New declaration.
>
>
> Index: gcc/tree-ssa-math-opts.c
> ===
> --- gcc/tree-ssa-math-opts.c    (revision 174535)
> +++ gcc/tree-ssa-math-opts.c    (working copy)
> @@ -1172,13 +1172,7 @@ gimple_expand_builtin_pow (gimple_stmt_iterator *g
>
>   if (flag_unsafe_math_optimizations
>       && cbrtfn
> -      /* FIXME: The following line was originally
> -        && (tree_expr_nonnegative_p (arg0) || !HONOR_NANS (mode)),
> -        but since arg0 is a gimple value, the first predicate
> -        will always return false.  It needs to be replaced with a
> -        call to a similar gimple_val_nonnegative_p function to be
> -         added in gimple-fold.c.  */
> -      && !HONOR_NANS (mode)
> +      && (gimple_val_nonnegative_real_p (arg0) || !HONOR_NANS (mode))
>       && REAL_VALUES_EQUAL (c, dconst1_3))
>     return build_and_insert_call (gsi, loc, &target, cbrtfn, arg0);
>
> @@ -1190,13 +1184,7 @@ gimple_expand_builtin_pow (gimple_stmt_iterator *g
>   if (flag_unsafe_math_optimizations
>       && sqrtfn
>       && cbrtfn
> -      /* FIXME: The following line was originally
> -        && (tree_expr_nonnegative_p (arg0) || !HONOR_NANS (mode)),
> -        but since arg0 is a gimple value, the first predicate
> -        will always return false.  It needs to be replaced with a
> -        call to a similar gimple_val_nonnegative_p function to be
> -         added in gimple-fold.c.  */
> -      && !HONOR_NANS (mode)
> +      && (gimple_val_nonnegative_real_p (arg0) || !HONOR_NANS (mode))
>       && optimize_function_for_speed_p (cfun)
>       && hw_sqrt_exists
>       && REAL_VALUES_EQUAL (c, dconst1_6))
> @@ -1270,13 +1258,7 @@ gimple_expand_builtin_pow (gimple_stmt_iterator *g
>
>   if (flag_unsafe_math_optimizations
>       && cbrtfn
> -      /* FIXME: The following line was originally
> -        && (tree_expr_nonnegative_p (arg0) || !HONOR_NANS (mode)),
> -        but since arg0 is a gimple value, the first predicate
> -        will always return false.  It needs to be replaced with a
> -        call to a similar gimple_val_nonnegative_p function to be
> -         added in gimple-fold.c.  */
> -      && !HONOR_NANS (mode)
> +      && (gimple_val_nonnegative_real_p (arg0) || !HONOR_NANS (mode))
>       && real_identical (&c2, &c)
>       && optimize_function_for_speed_p (cfun)
>       && powi_cost (n / 3) <= POWI_MAX_MULTS)
> Index: gcc/gimple-fold.c
> ===
> --- gcc/gimple-fold.c   (revision 174535)
> +++ gcc/gimple-fold.c   (working copy)
> @@ -3433,3 +3433,224 @@ fold_const_aggregate_ref (tree t)
>  {
>   return fold_const_aggregate_ref_1 (t, NULL);
>  }
> +
> +/* Return true iff VAL is a gimple expression that is known to be
> +   non-negative.  Restricted to floating-point inputs.  When changing
> +   this function, review fold-const.c:tree_expr_nonnegative_p to see
> +   whether similar changes are required.  */
> +
> +bool
> +gimple_val_nonnegative_real_p (tree val)
> +{
> +  gimple def_stmt;
> +
> +  /* Use existing logic for non-gimple trees.  */
> +  if (tree_expr_nonnegative_p (val))
> +    return true;
> +
> +  if (TREE_CODE (val) != SSA_NAME)
> +    return false;
> +
> +  def_stmt = SSA_NAME_DEF_STMT (val);
> +
> +  if (is_gimple_assign (def_stmt))
> +    {
> +      tree op0, op1;
> +
> +      /* If this is just a copy between SSA names, check the RHS.  */
> +      if (gimple_assign_ssa_name_copy_p (def_stmt))
> +       {
> +         op0 = gimple_assign_rhs1 (def_stmt);
> +         return gimple_val_nonnegative_real_p (op0);
> +       }

If handled then do so as SSA_NAME: case below.

> +      switch (gimple_assign_rhs_code (def_stmt))
> +       {
> +       case ABS_EXPR:
> +         /* Always true for floating-point operands.  */
> +         return true;

You don't verify anywhere that the input is FP.

As the depth of the expression we look at is unbound it is probably
easy to construct a testcase that exhibits quadratic compile-time
behavior like pow(pow(pow(pow(...,0.5), 0.5), 0.5), 0.5).  I originally
thought of just looking at the immediate defining statement but
never at its operands (simply return false when only the operand
would tell).  And I still think that is the way to go and should still
catch 99% of the useful ca

Re: Dump before flag

[Richard Guenther]

On Wed, Jun 1, 2011 at 11:23 PM, Xinliang David Li  wrote:
> On Wed, Jun 1, 2011 at 2:12 PM, Basile Starynkevitch
>  wrote:
>> On Wed, 1 Jun 2011 13:26:24 -0700
>> Xinliang David Li  wrote:
>>
>>> Hi, this is a simple patch that support dump_before flag. E.g,
>>>
>>> -fdump-tree-pre-before
>>>
>>> This is useful for diffing the the IR before and after a pass.
>>
>> Perhaps you forgot to actually attach the patch?
>
> Right -- attached in a follow up email.
>>
>>> Gcc dumping needs more cleanups -- such as allowing IR only dump,
>>> allowing IR dumping for a particular function etc. The exposure of
>>> 'dumpfile' (instead of a dumping_level () function) makes those change
>>> a little messy, but can be done.
>>
>> I don't understand what you mean by a dumping_level () function. What
>> should that hypothetical function do? (I'm wrongly guessing it would
>> return an integer, but IIRC dumpfile is a FILE*)
>
> THere are two sources of dump:
>
> 1) IR dump performed by pass manager
> 2) pass specific debugging dump (the verbosity is controlled by -details 
> flag).
>
> 2) is the part that is messy and needs cleanup. Every pass just checks
> if dump_file is null or not and decide to dump the debugging info --
> there is no easy way to turn it on and off. Ideally, individual pass
> should call
>
>  int debug_dump_level () -- dumps when it returns > 0.
>
> With that in place, the dump flag -fdump-xxx-yyy-ir_only can be easily
> implemented -- it only turns on pass manager dump, but lowers the
> debug dump level to 0.

Well.  There is just no distinction in the current design between
the "pass manager managed dump" and the "pass managed dump".
Instead the pass requests the function to be dumped before/after
it is run via the TODO flags.

Your patch doesn't really improve this but adds to the confusion.

+  /* Override dump TODOs.  */
+  if (dump_file && (pass->todo_flags_finish & TODO_dump_func)
+  && (dump_flags & TDF_BEFORE))
+{
+  pass->todo_flags_finish &= ~TODO_dump_func;
+  pass->todo_flags_start |= TODO_dump_func;
+}

and certainly writing to pass is not ok.  And the TDF_BEFORE flag
looks misplaced as it controls TODOs, not dumping behavior.
Yes, it's a mess right now but the above looks like a hack ontop
of that mess (maybe because of it, but well ...).

At least I would have expected to also get the dump after the
pass, not only the one before it with this dump flag.

Now, why can't you look at the previous pass output for the
before-dump (as I do usually)?

Richard.

Re: [PATCH] make attribute((returns_twice)) actually work (PR tree-optimization/49243)

[Richard Guenther]

On Thu, Jun 2, 2011 at 2:02 PM, Mikael Pettersson  wrote:
> GCC has attribute((returns_twice)) which is supposed to allow the safe
> use of alternate implementations of setjmp-like functions.  In particular,
> a function that calls a setjmp-like function must itself not be inlined,
> because that would enable unsafe optimizations.  This works for calls to
> "setjmp" (a few alternate spellings are allowed), but not to e.g. "my_setjmp"
> even if that function is declared with attribute((returns_twice)).  This
> bug affects the entire gcc-4.x series, gcc-3.x worked; see PR49243.
>
> A function that calls "setjmp" is marked non-inlinable because setjmp_call_p
> is applied to the function position, and it deduces via special_function_p
> that the callee is ECF_RETURNS_TWICE.  But special_function_p only looks at
> the name, so setjmp_call_p fails to detect attribute((returns_twice)) callees.
>
> The fix is to have setjmp_call_p also check if the returns_twice attribute
> is present, via DECL_IS_RETURNS_TWICE.  It could call flags_from_decl_or_type
> instead, but that would perform quite a bit of redundant work for this case.
>
> The test case uses -Winline to check that gcc refuses to inline a function
> that calls a returns_twice callee.  This is sufficient to verify the fix, and
> avoids the machine-specific code needed in the original runtime test case.
>
> Tested w/o regressions with gcc trunk and 4.6 on x86_64-linux.  The added test
> case does fail without the fix and pass with it.
>
> OK for trunk, and perhaps 4.6?

Ok.  I'll take care of applying it.

Thanks,
Richard.

> (I don't have svn write access.)
>
> /Mikael
>
> gcc/
>
> 2011-06-02  Mikael Pettersson  
>
>        PR tree-optimization/49243
>        * calls.c (setjmp_call_p): Also check if fndecl has the
>        returns_twice attribute.
>
> gcc/testsuite/
>
> 2011-06-02  Mikael Pettersson  
>
>        PR tree-optimization/49243
>        * gcc.dg/pr49243.c: New.
>
> --- gcc-4.7-20110528/gcc/calls.c.~1~    2011-05-25 13:00:14.0 +0200
> +++ gcc-4.7-20110528/gcc/calls.c        2011-06-02 12:55:32.0 +0200
> @@ -554,6 +554,8 @@ special_function_p (const_tree fndecl, i
>  int
>  setjmp_call_p (const_tree fndecl)
>  {
> +  if (DECL_IS_RETURNS_TWICE (fndecl))
> +    return ECF_RETURNS_TWICE;
>   return special_function_p (fndecl, 0) & ECF_RETURNS_TWICE;
>  }
>
> --- gcc-4.7-20110528/gcc/testsuite/gcc.dg/pr49243.c.~1~ 1970-01-01 
> 01:00:00.0 +0100
> +++ gcc-4.7-20110528/gcc/testsuite/gcc.dg/pr49243.c     2011-06-02 
> 12:55:32.0 +0200
> @@ -0,0 +1,25 @@
> +/* PR tree-optimization/49243 */
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -Winline" } */
> +
> +extern unsigned long jb[];
> +extern int my_setjmp(unsigned long jb[]) __attribute__((returns_twice));
> +extern int decode(const char*);
> +
> +static inline int wrapper(const char **s_ptr) /* { dg-warning "(inlining 
> failed|function 'wrapper' can never be inlined because it uses setjmp)" } */
> +{
> +    if (my_setjmp(jb) == 0) {
> +       const char *s = *s_ptr;
> +       while (decode(s) != 0)
> +           *s_ptr = ++s;
> +       return 0;
> +    } else
> +       return -1;
> +}
> +
> +void parse(const char *data)
> +{
> +    const char *s = data;
> +    if (!(wrapper(&s) == -1 && (s - data) == 1)) /* { dg-warning "called 
> from here" } */
> +       __builtin_abort();
> +}
>

Re: [PATCH] Fix fold_stmt ICE (PR c++/49264)

[Jakub Jelinek]

On Mon, Jun 06, 2011 at 11:30:19AM +0200, Richard Guenther wrote:
> On Fri, Jun 3, 2011 at 3:55 PM, Jakub Jelinek  wrote:
> > --- gcc/tree-inline.c.jj        2011-06-02 10:15:20.0 +0200
> > +++ gcc/tree-inline.c   2011-06-03 09:29:15.0 +0200
> > @@ -4108,6 +4108,14 @@ fold_marked_statements (int first, struc
> >                  if (fold_stmt (&gsi))
> >                    {
> >                      gimple new_stmt;
> > +                     /* If a builtin at the end of a bb folded into 
> > nothing,
> > +                        the following loop won't work.  */
> > +                     if (gsi_end_p (gsi))
> > +                       {
> > +                         cgraph_update_edges_for_call_stmt (old_stmt, 
> > old_decl,
> > +                                                            
> > gimple_build_nop ());
> 
> This?  Esp. I don't like the gimple_build_nop () here too much.

Yeah, I've talked about it in my patch comment.
E.g. cgraph_update_edges_for_call_stmt could accept NULL as new_stmt, or we
could add e.g.

void
cgraph_remove_edges_for_call_stmt (gimple old_stmt)
{
  struct cgraph_node *orig = cgraph_get_node (cfun->decl);
  struct cgraph_node *node;
  struct cgraph_edge *e;

  gcc_checking_assert (orig);
  e = cgraph_edge (orig, old_stmt);
  if (e)
cgraph_remove_edge (e);
  if (orig->clones)
for (node = orig->clones; node != orig; )
  {
e = cgraph_edge (node, old_stmt);
if (e)
  cgraph_remove_edge (e);
if (node->clones)
  node = node->clones;
else if (node->next_sibling_clone)
  node = node->next_sibling_clone;
else
  {
while (node != orig && !node->next_sibling_clone)
  node = node->clone_of;
if (node != orig)
  node = node->next_sibling_clone;
  }
  }
}

I think NULL new_stmt would have the advantage that we wouldn't duplicate
the complex code looping through all kinds of clones.

Jakub

Re: -fdump-passes -fenable-xxx=func_name_list

[Richard Guenther]

On Wed, Jun 1, 2011 at 7:24 PM, Xinliang David Li  wrote:
> The attached is the split #1 patch that enhances -fenable/disable.
>
> Ok after testing?

I expect the testcases will be quite fragile, so while I appreciate
test coverage for new options I think we should go without those
that involve any kind of UID.  Those which use assembler names
also will fail randomly dependent on how targets mangle their
functions - so I think we have to drop all testcases.

Also

+/* A helper function to determine if an identifier is valid to
+   be an assembler name (better to use target specific hook).  */
+
+static bool
+is_valid_assembler_name (const char *str)
+{
+  const char *p = str;
+  char c;
+
+  c = *p;
+  if (!((c >= 'a' && c <= 'z')
+|| (c >= 'A' && c <= 'Z')
+|| *p == '_'))
+return false;
+
+  p++;
+  while ((c = *p))
+   {
+ if (!((c >= 'a' && c <= 'z')
+   || (c >= 'A' && c <= 'Z')
+   || (c >= '0' && c <= '9')
+   || *p == '_'))
+   return false;
+ p++;
+   }
+
+  return true;
+}

why all that complicated checks?  Why not just check for p[0]
in [^0-9] and re-structure the range parsing to switch between
UIDs and assembler-names that way?

Thanks,
Richard.

> Thanks,
> David
>
> On Wed, Jun 1, 2011 at 9:16 AM, Xinliang David Li  wrote:
>> On Wed, Jun 1, 2011 at 1:51 AM, Richard Guenther
>>  wrote:
>>> On Wed, Jun 1, 2011 at 1:34 AM, Xinliang David Li  
>>> wrote:
 The following patch implements the a new option that dumps gcc PASS
 configuration. The sample output is attached.  There is one
 limitation: some placeholder passes that are named with '*xxx' are
 note registered thus they are not listed. They are not important as
 they can not be turned on/off anyway.

 The patch also enhanced -fenable-xxx and -fdisable-xx to allow a list
 of function assembler names to be specified.

 Ok for trunk?
>>>
>>> Please split the patch.
>>>
>>> I'm not too happy how you dump the pass configuration.  Why not simply,
>>> at a _single_ place, walk the pass tree?  Instead of doing pieces of it
>>> at pass execution time when it's not already dumped - that really looks
>>> gross.
>>
>> Yes, that was the original plan -- but it has problems
>> 1) the dumper needs to know the root pass lists -- which can change
>> frequently -- it can be a long term maintanance burden;
>> 2) the centralized dumper needs to be done after option processing
>> 3) not sure if gate functions have any side effects or have dependencies on 
>> cfun
>>
>> The proposed solutions IMHO is not that intrusive -- just three hooks
>> to do the dumping and tracking indentation.
>>
>>>
>>> The documentation should also link this option to the -fenable/disable
>>> options as obviously the pass names in that dump are those to be
>>> used for those flags (and not readily available anywhere else).
>>
>> Ok.
>>
>>>
>>> I also think that it would be way more useful to note in the individual
>>> dump files the functions (at the place they would usually appear) that
>>> have the pass explicitly enabled/disabled.
>>
>> Ok -- for ipa passes or tree/rtl passes where all functions are
>> explicitly disabled.
>>
>> Thanks,
>>
>> David
>>
>>>
>>> Richard.
>>>
 Thanks,

 David

>>>
>>
>

Re: Ping: The TI C6X port

[Bernd Schmidt]

Ping^3 for the C6X port. Now with extra patches:

Additional preliminary scheduler tweaks:
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg02408.html

Allow alternatives in attr "predicable":
http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00094.html

regrename across basic block boundaries:
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg02193.html
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg02194.html

> 6/11: REG_WORDS_BIG_ENDIAN
> http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00757.html
> 
> 7/11: Cope with using a section name other than ".rodata".
> http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00909.html
> 
> 8/11: Round function arg sizes to more than PARM_BOUNDARY
> http://gcc.gnu.org/ml/gcc-patches/2011-05/msg02170.html
> 
> 9/11: Make eq_attr work if an attribute uses (attr "...")
> http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00761.html
> 
> 10/11: The port
> http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00764.html
> 
> 11/11: Testcases
> http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00762.html

Re: -fdump-passes -fenable-xxx=func_name_list

[Richard Guenther]

On Thu, Jun 2, 2011 at 9:12 AM, Xinliang David Li  wrote:
> This is the version of the patch that walks through pass lists.
>
> Ok with this one?

+/* Dump all optimization passes.  */
+
+void
+dump_passes (void)
+{
+  struct cgraph_node *n, *node = NULL;
+  tree save_fndecl = current_function_decl;
+
+  fprintf (stderr, "MAX_UID = %d\n", cgraph_max_uid);

this isn't accurate info - cloning can cause more cgraph nodes to
appear (it also looks completely unrelated to dump_passes ...).
Please drop it.

+  create_pass_tab();
+  gcc_assert (pass_tab);

you have quite many asserts of this kind - we don't want them when
the previous stmt as in this case indicates everything is ok.

+  push_cfun (DECL_STRUCT_FUNCTION (node->decl));

this has side-effects, I'm not sure we want this here.  Why do you
need it?  Probably because of

+  is_really_on = override_gate_status (pass, current_function_decl, is_on);

?  But that is dependent on the function given which should have no
effect (unless it is overridden globally in which case override_gate_status
and friends should deal with a NULL cfun).

I don't understand why you need another table mapping pass to name
when pass->name is available and the info is trivially re-constructible.

Thanks,
Richard.

> David
>
> On Wed, Jun 1, 2011 at 12:45 PM, Xinliang David Li  wrote:
>> On Wed, Jun 1, 2011 at 12:29 PM, Richard Guenther
>>  wrote:
>>> On Wed, Jun 1, 2011 at 6:16 PM, Xinliang David Li  
>>> wrote:
 On Wed, Jun 1, 2011 at 1:51 AM, Richard Guenther
  wrote:
> On Wed, Jun 1, 2011 at 1:34 AM, Xinliang David Li  
> wrote:
>> The following patch implements the a new option that dumps gcc PASS
>> configuration. The sample output is attached.  There is one
>> limitation: some placeholder passes that are named with '*xxx' are
>> note registered thus they are not listed. They are not important as
>> they can not be turned on/off anyway.
>>
>> The patch also enhanced -fenable-xxx and -fdisable-xx to allow a list
>> of function assembler names to be specified.
>>
>> Ok for trunk?
>
> Please split the patch.
>
> I'm not too happy how you dump the pass configuration.  Why not simply,
> at a _single_ place, walk the pass tree?  Instead of doing pieces of it
> at pass execution time when it's not already dumped - that really looks
> gross.

 Yes, that was the original plan -- but it has problems
 1) the dumper needs to know the root pass lists -- which can change
 frequently -- it can be a long term maintanance burden;
 2) the centralized dumper needs to be done after option processing
 3) not sure if gate functions have any side effects or have dependencies 
 on cfun

 The proposed solutions IMHO is not that intrusive -- just three hooks
 to do the dumping and tracking indentation.
>>>
>>> Well, if you have a CU that is empty or optimized to nothing at some point
>>> you will not get a complete pass list.  I suppose optimize attributes might
>>> also confuse output.  Your solution might not be that intrusive
>>> but it is still ugly.  I don't see 1) as an issue, for 2) you can just call 
>>> the
>>> dumping from toplev_main before calling do_compile (), 3) gate functions
>>> shouldn't have side-effects, but as they could gate on optimize_for_speed ()
>>> your option summary output will be bogus anyway.
>>>
>>> So - what is the output intended for if it isn't reliable?
>>
>> This needs to be cleaned up at some point -- the gate function should
>> behave the same for all functions and per-function decisions need to
>> be pushed down to the executor body.  I will try to rework the patch
>> as you suggested to see if there are problems.
>>
>> David
>>
>>
>>>
>>> Richard.
>>>
>
> The documentation should also link this option to the -fenable/disable
> options as obviously the pass names in that dump are those to be
> used for those flags (and not readily available anywhere else).

 Ok.

>
> I also think that it would be way more useful to note in the individual
> dump files the functions (at the place they would usually appear) that
> have the pass explicitly enabled/disabled.

 Ok -- for ipa passes or tree/rtl passes where all functions are
 explicitly disabled.

 Thanks,

 David

>
> Richard.
>
>> Thanks,
>>
>> David
>>
>

>>>
>>
>

Re: [PATCH] Fix fold_stmt ICE (PR c++/49264)

[Richard Guenther]

On Mon, Jun 6, 2011 at 1:19 PM, Jakub Jelinek  wrote:
> On Mon, Jun 06, 2011 at 11:30:19AM +0200, Richard Guenther wrote:
>> On Fri, Jun 3, 2011 at 3:55 PM, Jakub Jelinek  wrote:
>> > --- gcc/tree-inline.c.jj        2011-06-02 10:15:20.0 +0200
>> > +++ gcc/tree-inline.c   2011-06-03 09:29:15.0 +0200
>> > @@ -4108,6 +4108,14 @@ fold_marked_statements (int first, struc
>> >                  if (fold_stmt (&gsi))
>> >                    {
>> >                      gimple new_stmt;
>> > +                     /* If a builtin at the end of a bb folded into 
>> > nothing,
>> > +                        the following loop won't work.  */
>> > +                     if (gsi_end_p (gsi))
>> > +                       {
>> > +                         cgraph_update_edges_for_call_stmt (old_stmt, 
>> > old_decl,
>> > +                                                            
>> > gimple_build_nop ());
>>
>> This?  Esp. I don't like the gimple_build_nop () here too much.
>
> Yeah, I've talked about it in my patch comment.
> E.g. cgraph_update_edges_for_call_stmt could accept NULL as new_stmt, or we
> could add e.g.
>
> void
> cgraph_remove_edges_for_call_stmt (gimple old_stmt)
> {
>  struct cgraph_node *orig = cgraph_get_node (cfun->decl);
>  struct cgraph_node *node;
>  struct cgraph_edge *e;
>
>  gcc_checking_assert (orig);
>  e = cgraph_edge (orig, old_stmt);
>  if (e)
>    cgraph_remove_edge (e);
>  if (orig->clones)
>    for (node = orig->clones; node != orig; )
>      {
>        e = cgraph_edge (node, old_stmt);
>        if (e)
>          cgraph_remove_edge (e);
>        if (node->clones)
>          node = node->clones;
>        else if (node->next_sibling_clone)
>          node = node->next_sibling_clone;
>        else
>          {
>            while (node != orig && !node->next_sibling_clone)
>              node = node->clone_of;
>            if (node != orig)
>              node = node->next_sibling_clone;
>          }
>      }
> }
>
> I think NULL new_stmt would have the advantage that we wouldn't duplicate
> the complex code looping through all kinds of clones.

Yeah, I'd prefer that variant.  Honza?

Richard.

>        Jakub
>

Re: [PING] [PATCH] PR preprocessor/48532 (Wrong location in pragma involving macros)

[Dodji Seketeli]

Tom Tromey  a écrit:

> Dodji> +  context of 'P'.  The problem is, if we are beeing
>
> Typo, "being".
>
> Ok with that fixed.

Thanks.  Fixed and committed to revision r174694.

-- 
Dodji

Re: [PATCH] gimple_val_nonnegative_real_p (PR46728 patch 7 of 7)

[William J. Schmidt]

On Mon, 2011-06-06 at 13:00 +0200, Richard Guenther wrote:
> On Wed, Jun 1, 2011 at 9:27 PM, William J. Schmidt
>  wrote:



> > +/* Return true iff VAL is a gimple expression that is known to be
> > +   non-negative.  Restricted to floating-point inputs.  When changing
> > +   this function, review fold-const.c:tree_expr_nonnegative_p to see
> > +   whether similar changes are required.  */
> > +
> > +bool
> > +gimple_val_nonnegative_real_p (tree val)
> > +{
> > +  gimple def_stmt;
> > +
> > +  /* Use existing logic for non-gimple trees.  */
> > +  if (tree_expr_nonnegative_p (val))
> > +return true;
> > +
> > +  if (TREE_CODE (val) != SSA_NAME)
> > +return false;
> > +
> > +  def_stmt = SSA_NAME_DEF_STMT (val);
> > +
> > +  if (is_gimple_assign (def_stmt))
> > +{
> > +  tree op0, op1;
> > +
> > +  /* If this is just a copy between SSA names, check the RHS.  */
> > +  if (gimple_assign_ssa_name_copy_p (def_stmt))
> > +   {
> > + op0 = gimple_assign_rhs1 (def_stmt);
> > + return gimple_val_nonnegative_real_p (op0);
> > +   }
> 
> If handled then do so as SSA_NAME: case below.
> 
> > +  switch (gimple_assign_rhs_code (def_stmt))
> > +   {
> > +   case ABS_EXPR:
> > + /* Always true for floating-point operands.  */
> > + return true;
> 
> You don't verify anywhere that the input is FP.
> 
> As the depth of the expression we look at is unbound it is probably
> easy to construct a testcase that exhibits quadratic compile-time
> behavior like pow(pow(pow(pow(...,0.5), 0.5), 0.5), 0.5).  I originally
> thought of just looking at the immediate defining statement but
> never at its operands (simply return false when only the operand
> would tell).  And I still think that is the way to go and should still
> catch 99% of the useful cases.
> 
> As for the grand masterplan we probably should eventually drive
> the builtin-folding by information provided by a SSA or DOM propagation
> engine (see tree-complex.c for example).  That would avoid the
> quadratic-ness.
> 
> So, please prune any recursion.

OK.  I misunderstood your intent; I thought you had provided a skeleton
and wanted me to fill in the details to match the corresponding tree
interface.  I understand the concern and will remove the recursion.  If
we find we're missing cases, it would be simple enough to provide
limited-depth recursion.

> 
> Thanks,
> Richard.
> 
> > +   case NOP_EXPR:
> > +   case CONVERT_EXPR:
> > + /* True if the first operand is a nonnegative real.  */
> > + op0 = gimple_assign_rhs1 (def_stmt);
> > + return (TREE_CODE (TREE_TYPE (op0)) == REAL_TYPE
> > + && gimple_val_nonnegative_real_p (op0));
> > +
> > +   case PLUS_EXPR:
> > +   case MIN_EXPR:
> > +   case RDIV_EXPR:
> > + /* True if both operands are nonnegative.  */
> > + op0 = gimple_assign_rhs1 (def_stmt);
> > + op1 = gimple_assign_rhs2 (def_stmt);
> > + return (gimple_val_nonnegative_real_p (op0)
> > + && gimple_val_nonnegative_real_p (op1));
> > +
> > +   case MAX_EXPR:
> > + /* True if either operand is nonnegative.  */
> > + op0 = gimple_assign_rhs1 (def_stmt);
> > + op1 = gimple_assign_rhs2 (def_stmt);
> > + return (gimple_val_nonnegative_real_p (op0)
> > + || gimple_val_nonnegative_real_p (op1));
> > +
> > +   case MULT_EXPR:
> > + /* True if the two operands are identical (since we are
> > +restricted to floating-point inputs), or if both operands
> > +are nonnegative.  */
> > + op0 = gimple_assign_rhs1 (def_stmt);
> > + op1 = gimple_assign_rhs2 (def_stmt);
> > +
> > + if (operand_equal_p (op0, op1, 0))
> > +   return true;
> > +
> > + if (TREE_CODE (op0) == SSA_NAME
> > + && TREE_CODE (op1) == SSA_NAME
> > + && SSA_NAME_VAR (op0) == SSA_NAME_VAR (op1)
> > + && SSA_NAME_VERSION (op0) == SSA_NAME_VERSION (op1))
> > +   return true;
> 
> That case is covered by operand_equal_p already.

I don't believe it is, though perhaps it should be.  I didn't see any
handling for SSA_NAME or tcc_exceptional, and the default just returns
false, so I added this logic.  Did I miss something subtle?

Thanks,
Bill

Re: [PATCH][ARM] Add support for ADDW and SUBW instructions

[Dmitry Plotnikov]

This is follow-up patch that fixes rtx costs for CONST_INT in PLUS 
pattern.  Original discussion is here: 
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01427.html
2011-06-06  Dmitry PLotnikov  

	gcc/
	* config/arm/arm.c (arm_rtx_costs_1): Fixed costs for CONST_INT
	in PLUS pattern.

diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 22ddcd2..9ef6f6d 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -7050,7 +7056,10 @@ arm_rtx_costs_1 (rtx x, enum rtx_code outer, int* total, bool speed)
 
 case CONST_INT:
   if (const_ok_for_arm (INTVAL (x))
-	  || const_ok_for_arm (~INTVAL (x)))
+	  || const_ok_for_arm (~INTVAL (x))
+	  || (TARGET_THUMB2 && outer == PLUS 
+	  && (const_ok_for_op (INTVAL (x), outer)
+	  || const_ok_for_op (~INTVAL (x), outer
 	*total = COSTS_N_INSNS (1);
   else
 	*total = COSTS_N_INSNS (arm_gen_constant (SET, mode, NULL_RTX,

Re: [PATCH][ARM] Add support for ADDW and SUBW instructions

[Andrew Stubbs]

On 06/06/11 13:15, Dmitry Plotnikov wrote:

+   &&  (const_ok_for_op (INTVAL (x), outer)
+ || const_ok_for_op (~INTVAL (x), outer


The second call is redundant. const_ok_for_op should already do that.

Andrew

Re: Ping: The TI C6X port

[Gerald Pfeifer]

Hi Bernd,

not a direct approval for any of the outstanding patches, but I am happy 
to report that the steering committee is appointing you maintainer of the 
C6X port.

Please go ahead and add yourself to the MAINTAINERS file as part of the
patch that actually adds the port (10/11 if I recall correctly).

Thanks for contributing this work, and happy hacking!  And do think of
contributing a news item for the main page. :-)

Gerald

Re: Ping: The TI C6X port

[Bernd Schmidt]

On 06/06/2011 02:53 PM, Gerald Pfeifer wrote:
> not a direct approval for any of the outstanding patches, but I am happy 
> to report that the steering committee is appointing you maintainer of the 
> C6X port.

Thanks!

> Thanks for contributing this work, and happy hacking!  And do think of
> contributing a news item for the main page. :-)

I did, and you approved it :)
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00983.html


Bernd

Re: Skip building target libiberty for arm*-*-linux-androideabi

[Nick Clifton]

Hi Jing Yu,

> 2011-05-08  Jing Yu  
>
> * configure.ac: Skip target-libiberty for 
arm*-*-linux-androideabi.

> * configure: Regenerated.

Approved - please apply.

Cheers
  Nick

Re: [patch] Improve detection of widening multiplication in the vectorizer

[Richard Sandiford]

Richard Guenther  writes:
> Thanks.  I would hope that we eventually can get rid of the
> pattern recognizer ... at least for SSE there is also always
> a scalar variant instruction for each vectorized one.

AFAIK, that isn't true for ARM and NEON.  E.g. I don't know of a single
instruction that does the scalar equivalent of things like VADDHN
(add values and narrow to high half), VSUBL.U32 (subtract two values
and extend the result), etc.

FWIW, I think MIPS only has minimum and maximum operations for paired
floats, not for single floats or doubles.  I don't have the manuals to
hand to check though.

It's probably OK for the particular case of widening multiplications.
It sounded like you were making a more general statement though.
If so, I think we should try to avoid assuming that every vectorisable
operation has an equivalent scalar machine instruction.

Richard

Re: [PATCH][ARM] Add support for ADDW and SUBW instructions

[Dmitry Plotnikov]

On 06/06/2011 04:41 PM, Andrew Stubbs wrote:

On 06/06/11 13:15, Dmitry Plotnikov wrote:

+ &&  (const_ok_for_op (INTVAL (x), outer)
+  || const_ok_for_op (~INTVAL (x), outer


The second call is redundant. const_ok_for_op should already do that.


Fixed patch is attached.  Ok?
2011-06-06  Dmitry PLotnikov  

	gcc/
	* config/arm/arm.c (arm_rtx_costs_1): Fixed costs for CONST_INT
	in PLUS pattern.

diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 22ddcd2..9ef6f6d 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -7050,7 +7056,9 @@ arm_rtx_costs_1 (rtx x, enum rtx_code outer, int* total, bool speed)
 
 case CONST_INT:
   if (const_ok_for_arm (INTVAL (x))
-	  || const_ok_for_arm (~INTVAL (x)))
+	  || const_ok_for_arm (~INTVAL (x))
+	  || (TARGET_THUMB2 && outer == PLUS 
+	  && (const_ok_for_op (INTVAL (x), outer
 	*total = COSTS_N_INSNS (1);
   else
 	*total = COSTS_N_INSNS (arm_gen_constant (SET, mode, NULL_RTX,

Re: fix left-over debug insns in DCE

[Alexandre Oliva]

On Jun  6, 2011, Eric Botcazou  wrote:

>> It might be too late for DF to do anything sensible to preserve the
>> debug info rather than just throw it away, as your partial approval
>> suggests.

> OK, let me think about this a little more.

>> Indeed, sorry, I misread it.

> Mind installing these bits separately?  My understanding is that they are 
> independent correctness fixes.

Tested, installed.

Here are the remaining bits.

for  gcc/ChangeLog
from  Alexandre Oliva  

	* df.h (enum debug_temp_where): New.
	(dead_debug_init, dead_debug_finish) Declare.
	(dead_debug_add, dead_debug_insert_temp): Declare.
	(struct dead_debug_use, struct dead_debug): Moved from...
	* df-problems.c: ... here.
	(df_set_unused_notes_for_mw): Bind debug uses of unused regno
	to a debug temp.
	(df_create_unused_note): Likewise.
	(df_set_dead_notes_for_mw): Move comment where it belongs.
	(dead_debug_init): Export.
	(dead_debug_reset_uses): New, factored out of...
	(dead_debug_finish): ...this.  Export.
	(dead_debug_reset): Remove.
	(dead_debug_add): Export.
	(dead_debug_insert_before): Rename to...
	(dead_debug_insert_temp): ... this.  Add where argument.  Export.
	Locate stored value for BEFORE_WITH_VALUE.  Avoid repeat inserts.
	Return insertion count.
	(df_note_bb_compute): Adjust.
	* dce.c (word_dce_process_block): Adjust dead debug uses.
	(dce_process_block): Likewise.

Index: gcc/df-problems.c
===
--- gcc/df-problems.c.orig	2011-06-03 11:41:26.507743096 -0300
+++ gcc/df-problems.c	2011-06-06 10:25:17.854030387 -0300
@@ -2842,25 +2842,6 @@ df_whole_mw_reg_unused_p (struct df_mw_h
 }
 
 
-/* Node of a linked list of uses of dead REGs in debug insns.  */
-struct dead_debug_use
-{
-  df_ref use;
-  struct dead_debug_use *next;
-};
-
-/* Linked list of the above, with a bitmap of the REGs in the
-   list.  */
-struct dead_debug
-{
-  struct dead_debug_use *head;
-  bitmap used;
-  bitmap to_rescan;
-};
-
-static void dead_debug_reset (struct dead_debug *, unsigned int);
-
-
 /* Set the REG_UNUSED notes for the multiword hardreg defs in INSN
based on the bits in LIVE.  Do not generate notes for registers in
artificial uses.  DO_NOT_GEN is updated so that REG_DEAD notes are
@@ -2886,7 +2867,7 @@ df_set_unused_notes_for_mw (rtx insn, st
 {
   unsigned int regno = mws->start_regno;
   df_set_note (REG_UNUSED, insn, mws->mw_reg);
-  dead_debug_reset (debug, regno);
+  dead_debug_insert_temp (debug, regno, insn, DEBUG_TEMP_AFTER_WITH_REG);
 
 #ifdef REG_DEAD_DEBUGGING
   df_print_note ("adding 1: ", insn, REG_NOTES (insn));
@@ -2901,7 +2882,7 @@ df_set_unused_notes_for_mw (rtx insn, st
 	&& !bitmap_bit_p (artificial_uses, r))
 	  {
 	df_set_note (REG_UNUSED, insn, regno_reg_rtx[r]);
-	dead_debug_reset (debug, r);
+	dead_debug_insert_temp (debug, r, insn, DEBUG_TEMP_AFTER_WITH_REG);
 #ifdef REG_DEAD_DEBUGGING
 	df_print_note ("adding 2: ", insn, REG_NOTES (insn));
 #endif
@@ -2969,12 +2950,12 @@ df_set_dead_notes_for_mw (rtx insn, stru
 
   if (df_whole_mw_reg_dead_p (mws, live, artificial_uses, do_not_gen))
 {
-  /* Add a dead note for the entire multi word register.  */
   if (is_debug)
 	{
 	  *added_notes_p = true;
 	  return;
 	}
+  /* Add a dead note for the entire multi word register.  */
   df_set_note (REG_DEAD, insn, mws->mw_reg);
 #ifdef REG_DEAD_DEBUGGING
   df_print_note ("adding 1: ", insn, REG_NOTES (insn));
@@ -3028,7 +3009,7 @@ df_create_unused_note (rtx insn, df_ref 
   rtx reg = (DF_REF_LOC (def))
 ? *DF_REF_REAL_LOC (def): DF_REF_REG (def);
   df_set_note (REG_UNUSED, insn, reg);
-  dead_debug_reset (debug, dregno);
+  dead_debug_insert_temp (debug, dregno, insn, DEBUG_TEMP_AFTER_WITH_REG);
 #ifdef REG_DEAD_DEBUGGING
   df_print_note ("adding 3: ", insn, REG_NOTES (insn));
 #endif
@@ -3039,7 +3020,7 @@ df_create_unused_note (rtx insn, df_ref 
 
 
 /* Initialize DEBUG to an empty list, and clear USED, if given.  */
-static inline void
+void
 dead_debug_init (struct dead_debug *debug, bitmap used)
 {
   debug->head = NULL;
@@ -3049,32 +3030,83 @@ dead_debug_init (struct dead_debug *debu
 bitmap_clear (used);
 }
 
-/* Reset all debug insns with pending uses.  Release the bitmap in it,
-   unless it is USED.  USED must be the same bitmap passed to
-   dead_debug_init.  */
-static inline void
-dead_debug_finish (struct dead_debug *debug, bitmap used)
+/* Reset all debug uses in HEAD, and clear DEBUG->to_rescan bits of
+   each reset insn.  DEBUG is not otherwise modified.  If HEAD is
+   DEBUG->head, DEBUG->head will be set to NULL at the end.
+   Otherwise, entries from DEBUG->head that pertain to reset insns
+   will be removed, and only then rescanned.  */
+
+static void
+dead_debug_reset_uses (struct dead_debug *debug, struct dead_debug_use *head)
 {
-  struct dead_debug_use *head;
-  rtx insn = NULL;
+  bool got_head = (debug->head ==

Re: [PATCH][ARM] Add support for ADDW and SUBW instructions

[Andrew Stubbs]

On 06/06/11 14:26, Dmitry Plotnikov wrote:

if (const_ok_for_arm (INTVAL (x))
- || const_ok_for_arm (~INTVAL (x)))
+ || const_ok_for_arm (~INTVAL (x))
+ || (TARGET_THUMB2&&  outer == PLUS
+   &&  (const_ok_for_op (INTVAL (x), outer


Sorry, I should have noticed before ...

This whole condition should be covered by a single call to 
const_ok_for_op. It already calls const_ok_for_arm internally.


Andrew

Re: initialized out.clauses in read_predicate

[Alexandre Oliva]

On May 30, 2011, Alexandre Oliva  wrote:

> In an -O3 bootstrap, out.clauses are reported as uninitialized.  GCC is
> not smart enough to realize accesses to the uninitialized members will
> never happen.  It shouldn't be too expensive to initialize them all, so
> this is what this patch does.  Regstrapped on x86_64-linux-gnu and
> i686-linux-gnu.  Ok to install?

Oops, I mistakenly checked this in along with a couple of other approved
patches, sorry.

Should I back it out, or may I leave it in?  (please :-)

> for  gcc/ChangeLog
> from  Alexandre Oliva  

>   * ipa-inline-analysis.c (read_predicate): Initialize all clauses.

> Index: gcc/ipa-inline-analysis.c
> ===
> --- gcc/ipa-inline-analysis.c.orig2011-05-18 03:29:08.295328903 -0300
> +++ gcc/ipa-inline-analysis.c 2011-05-18 03:29:38.187242177 -0300
> @@ -2289,6 +2289,11 @@ read_predicate (struct lto_input_block *
>clause = out.clause[k++] = lto_input_uleb128 (ib);
>  }
>while (clause);
> +
> +  /* Zero-initialize the remaining clauses in OUT.  */
> +  while (k <= MAX_CLAUSES)
> +out.clause[k++] = 0;
> +
>return out;
>  }
 
-- 
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist  Red Hat Brazil Compiler Engineer

Re: initialized out.clauses in read_predicate

[Jan Hubicka]

> On May 30, 2011, Alexandre Oliva  wrote:
> 
> > In an -O3 bootstrap, out.clauses are reported as uninitialized.  GCC is
> > not smart enough to realize accesses to the uninitialized members will
> > never happen.  It shouldn't be too expensive to initialize them all, so
> > this is what this patch does.  Regstrapped on x86_64-linux-gnu and
> > i686-linux-gnu.  Ok to install?
> 
> Oops, I mistakenly checked this in along with a couple of other approved
> patches, sorry.
> 
> Should I back it out, or may I leave it in?  (please :-)
> 
> > for  gcc/ChangeLog
> > from  Alexandre Oliva  
> 
> > * ipa-inline-analysis.c (read_predicate): Initialize all clauses.
> 
> > Index: gcc/ipa-inline-analysis.c
> > ===
> > --- gcc/ipa-inline-analysis.c.orig  2011-05-18 03:29:08.295328903 -0300
> > +++ gcc/ipa-inline-analysis.c   2011-05-18 03:29:38.187242177 -0300
> > @@ -2289,6 +2289,11 @@ read_predicate (struct lto_input_block *
> >clause = out.clause[k++] = lto_input_uleb128 (ib);
> >  }
> >while (clause);
> > +
> > +  /* Zero-initialize the remaining clauses in OUT.  */
> > +  while (k <= MAX_CLAUSES)
> > +out.clause[k++] = 0;

Well, clauses is a typical zero terminated array, so I really do think the 
warning is bogus.
Do you at least know why we end up with that weird warning?

Honza

Re: AIX net/if_arp.h include fix for struct fc_softc

[Bruce Korb]

On 06/05/11 21:16, Peter O'Gorman wrote:

Ok for trunk?

Peter



Index: ChangeLog
===
--- ChangeLog   (revision 174678)
2011-??-??  Peter O'Gorman  

* inclhack.def (aix_net_if_arp): New fix.
* fixincl.x: Regenerate.
* tests/base/net/if_arp.h [AIX_NET_IF_ARP_CHECK]: New test.

Index: inclhack.def
===
--- inclhack.def(revision 174678)
+++ inclhack.def(working copy)
@@ -369,6 +369,19 @@
 test_text = "#define _Complex_I   __I\n";
 };

+/*
+ * net/if_arp.h defines a variable fc_softc instead of adding a
+ * typedef for the struct on AIX 5.2, 5.3, 6.1 and 7.1
+ */
+fix = {
+hackname  = aix_net_if_arp;
+mach  = "*-*-aix*";
+files = "net/if_arp.h";
+select= "^struct  fc_softc \\{";
+c_fix = format;
+c_fix_arg = "typedef struct _fc_softc {";
+test_text = "struct  fc_softc {";
+};

 /*
  *  pthread.h on AIX 4.3.3 tries to define a macro without whitspace


Please be kind enough to make the test text sample be a complete
struct, even if it only has one "int" field.  Aesthetics.  Sorry.
The change log showed a change for tests/base/net/if_arp.h, but
the patch did not.

Otherwise, fine by me.

Re: initialized out.clauses in read_predicate

[Jan Hubicka]

> On May 30, 2011, Alexandre Oliva  wrote:
> 
> > In an -O3 bootstrap, out.clauses are reported as uninitialized.  GCC is
> > not smart enough to realize accesses to the uninitialized members will
> > never happen.  It shouldn't be too expensive to initialize them all, so
> > this is what this patch does.  Regstrapped on x86_64-linux-gnu and
> > i686-linux-gnu.  Ok to install?
> 
> Oops, I mistakenly checked this in along with a couple of other approved
> patches, sorry.
> 
> Should I back it out, or may I leave it in?  (please :-)

But concerning backing out, I don't see why we should break bootstrap again.  
it would
be however nice to get a testcase and track the bogus warning issue.

Thanks!
Honza

Re: [pph] Clean up PPH tests (issue4572042)

[Diego Novillo]

So, I'm getting this:

Running /home/dnovillo/pph/svn/src/gcc/testsuite/g++.dg/pph/pph.exp ...
XPASS: g++.dg/pph/c120060625-1.cc  -I.  (test for bogus messages, line )
XPASS: g++.dg/pph/c1eabi1.cc  -I.  (test for bogus messages, line )
XPASS: g++.dg/pph/x1autometh.cc  -I.  (test for bogus messages, line )
XPASS: g++.dg/pph/x1functions.cc  -I.  (test for bogus messages, line )
XPASS: g++.dg/pph/x1functions.cc  -I.  (test for bogus messages, line )
XPASS: g++.dg/pph/x1special.cc  -I.  (test for bogus messages, line )
XPASS: g++.dg/pph/x1special.cc  -fpph-map=pph.map -I.  (test for bogus
messages, line )
FAIL: g++.dg/pph/x1special.cc  -fpph-map=pph.map -I. (test for excess errors)
XPASS: g++.dg/pph/x1template.cc  -I.  (test for bogus messages, line )
XPASS: g++.dg/pph/x1template.cc  -fpph-map=pph.map -I.  (test for
bogus messages, line )
FAIL: g++.dg/pph/x1template.cc  -fpph-map=pph.map -I. (test for excess errors)
XPASS: g++.dg/pph/x1tmplclass.cc  -I.  (test for bogus messages, line )
XPASS: g++.dg/pph/x1tmplfunc.cc  -I.  (test for bogus messages, line )
XPASS: g++.dg/pph/x1tmplfunc.cc  -fpph-map=pph.map -I.  (test for
bogus messages, line )
FAIL: g++.dg/pph/x1tmplfunc.cc  -fpph-map=pph.map -I. (test for excess errors)
XPASS: g++.dg/pph/x1typerefs.cc  -I.  (test for bogus messages, line )
XPASS: g++.dg/pph/x1variables.cc  -I.  (test for bogus messages, line )
XPASS: g++.dg/pph/x1variables.cc  -I.  (test for bogus messages, line )
XPASS: g++.dg/pph/x1variables.cc  -fpph-map=pph.map -I.  (test for
bogus messages, line )
XPASS: g++.dg/pph/x1variables.cc  -fpph-map=pph.map -I.  (test for
bogus messages, line )

=== g++ Summary ===

# of expected passes176
# of unexpected failures3
# of unexpected successes   17
# of expected failures  45

The three FAILs are expected then?  Those are the ones you mentioned
can't be easily XFAIL'd?


Diego.

On Sun, Jun 5, 2011 at 18:46, Lawrence Crowl  wrote:
> The purpose of this patch is to make PPH testing clean.
>
> Some tests have assembly comparison failures between regular compiles and PPH
> compiles.  When this miscompare is exected, we now mark the test with a
> comment "pph asm xdiff".  The driver lib/dg-pph.exp looks for this comment to
> report either FAIL or XFAIL.
>
> Test p1mean.cc enters infinite recursion.  Instead of disabling the test with
> a syntax error, we now run it under a dg-timeout.
>
> Test c1return-5.h was trying to grep assembly, but since we produce pre-parsed
> headers, not assembly, the test was in error.  We have moved the assembly
> check to c1return-5.cc where it belongs.
>
> All PPH tests expected to have PPH compilation failures are marked with
> // { dg-xfail-if "comment" { "*-*-*" } { "-fpph-map=pph.map" } }
> The regular compiles do not have the -fpph-map option, and hence are not
> expected to fail.  One test has a comment INFINITE; one test has a comment
> BOGUS; and the rest have a comment ICE.
>
> The driver lib/dg-pph.exp test control logic now stops a test when any
> compilation fails to produce assembly output.  If the test file contains the
> above directive, that compilation failure is expected and reported as such.
> Otherwise, it is reported as an unexpected failure.
>
> PPH is wrongly producing ICEs and errors.  We mark applicable messages with
> dg-bogus.  Because the line/column information is often wrong, we mark the
> with a line of "0", which avoids line comparisons.  We also prune output as
> needed.
>
> All tests are now either PASS or XFAIL, with the exception of unavoidable
> bogus XPASS messages for "test for bogus messages" and "test for excess
> errors".  These are unavoidable because they cannot be conditionalized based
> on compiler options, and they do not appear in regular compiles.
>
> If you run the output of
>
>    make check-c++ RUNTESTFLAGS=pph.exp
>
> through
>
>    sed -e '
>        /^XPASS: .*test for bogus messages/     d
>        /^XPASS: .*test for excess errors/      d
>
>        /^#/            p
>        /^ERROR: /      p
>        /^XFAIL: /      p
>        /^XPASS: /      p
>        /^FAIL: /       p
>
>        d
>    '
>
> you should get no individual tests listed.
>
>
> Index: gcc/testsuite/ChangeLog.pph
>
> 2011-06-05  Lawrence Crowl  
>
>        * lib/dg-pph.exp (dg-pph-hdr): Add blank lines to logfile.
>        Format if statements and calls consistently.
>        (dg-pph-neg): Remove extraneous assembly files. Add blank
>        lines to logfile. Format if statements and calls consistently.
>        (dg-pph-pos): Stop test when a compilation fails. Recognize
>        expected failing compilations. Recognize expected assembly
>        miscompares. Parenthesize failure notes. Remove extraneous
>        assembly files. Add blank lines to logfile. Format if
>        statements and calls consistently.
>        * g++.dg/pph/c1simple.cc: Add comment "pph asm xdiff"
>        indicating expected assembly difference failure. Add line
>        spacing to

Re: [PATCH][ARM] Add support for ADDW and SUBW instructions

[Dmitry Plotnikov]

On 06/06/2011 05:33 PM, Andrew Stubbs wrote:

On 06/06/11 14:26, Dmitry Plotnikov wrote:

if (const_ok_for_arm (INTVAL (x))
-  || const_ok_for_arm (~INTVAL (x)))
+  || const_ok_for_arm (~INTVAL (x))
+  || (TARGET_THUMB2&&  outer == PLUS
+ &&  (const_ok_for_op (INTVAL (x), outer


Sorry, I should have noticed before ...

This whole condition should be covered by a single call to 
const_ok_for_op. It already calls const_ok_for_arm internally.


This condition is not covered by const_ok_for_op, because "outer" can be 
equal to other rtx codes, which are not covered in const_ok_for_op like 
IF_THEN_ELSE or MULT (I have several ICEs with these codes).  I don't 
know how to fix this correctly - should I add all codes to 
const_ok_for_op or maybe just replace default alternative from 
gcc_unreachable() to "return 0;" ?

Re: [PATCH] gimple_val_nonnegative_real_p (PR46728 patch 7 of 7)

[Richard Guenther]

On Mon, Jun 6, 2011 at 2:12 PM, William J. Schmidt
 wrote:
> On Mon, 2011-06-06 at 13:00 +0200, Richard Guenther wrote:
>> On Wed, Jun 1, 2011 at 9:27 PM, William J. Schmidt
>>  wrote:
>
> 
>
>> > +/* Return true iff VAL is a gimple expression that is known to be
>> > +   non-negative.  Restricted to floating-point inputs.  When changing
>> > +   this function, review fold-const.c:tree_expr_nonnegative_p to see
>> > +   whether similar changes are required.  */
>> > +
>> > +bool
>> > +gimple_val_nonnegative_real_p (tree val)
>> > +{
>> > +  gimple def_stmt;
>> > +
>> > +  /* Use existing logic for non-gimple trees.  */
>> > +  if (tree_expr_nonnegative_p (val))
>> > +    return true;
>> > +
>> > +  if (TREE_CODE (val) != SSA_NAME)
>> > +    return false;
>> > +
>> > +  def_stmt = SSA_NAME_DEF_STMT (val);
>> > +
>> > +  if (is_gimple_assign (def_stmt))
>> > +    {
>> > +      tree op0, op1;
>> > +
>> > +      /* If this is just a copy between SSA names, check the RHS.  */
>> > +      if (gimple_assign_ssa_name_copy_p (def_stmt))
>> > +       {
>> > +         op0 = gimple_assign_rhs1 (def_stmt);
>> > +         return gimple_val_nonnegative_real_p (op0);
>> > +       }
>>
>> If handled then do so as SSA_NAME: case below.
>>
>> > +      switch (gimple_assign_rhs_code (def_stmt))
>> > +       {
>> > +       case ABS_EXPR:
>> > +         /* Always true for floating-point operands.  */
>> > +         return true;
>>
>> You don't verify anywhere that the input is FP.
>>
>> As the depth of the expression we look at is unbound it is probably
>> easy to construct a testcase that exhibits quadratic compile-time
>> behavior like pow(pow(pow(pow(...,0.5), 0.5), 0.5), 0.5).  I originally
>> thought of just looking at the immediate defining statement but
>> never at its operands (simply return false when only the operand
>> would tell).  And I still think that is the way to go and should still
>> catch 99% of the useful cases.
>>
>> As for the grand masterplan we probably should eventually drive
>> the builtin-folding by information provided by a SSA or DOM propagation
>> engine (see tree-complex.c for example).  That would avoid the
>> quadratic-ness.
>>
>> So, please prune any recursion.
>
> OK.  I misunderstood your intent; I thought you had provided a skeleton
> and wanted me to fill in the details to match the corresponding tree
> interface.

Sorry for being unclear.

>  I understand the concern and will remove the recursion.  If
> we find we're missing cases, it would be simple enough to provide
> limited-depth recursion.

Indeed.

>>
>> Thanks,
>> Richard.
>>
>> > +       case NOP_EXPR:
>> > +       case CONVERT_EXPR:
>> > +         /* True if the first operand is a nonnegative real.  */
>> > +         op0 = gimple_assign_rhs1 (def_stmt);
>> > +         return (TREE_CODE (TREE_TYPE (op0)) == REAL_TYPE
>> > +                 && gimple_val_nonnegative_real_p (op0));
>> > +
>> > +       case PLUS_EXPR:
>> > +       case MIN_EXPR:
>> > +       case RDIV_EXPR:
>> > +         /* True if both operands are nonnegative.  */
>> > +         op0 = gimple_assign_rhs1 (def_stmt);
>> > +         op1 = gimple_assign_rhs2 (def_stmt);
>> > +         return (gimple_val_nonnegative_real_p (op0)
>> > +                 && gimple_val_nonnegative_real_p (op1));
>> > +
>> > +       case MAX_EXPR:
>> > +         /* True if either operand is nonnegative.  */
>> > +         op0 = gimple_assign_rhs1 (def_stmt);
>> > +         op1 = gimple_assign_rhs2 (def_stmt);
>> > +         return (gimple_val_nonnegative_real_p (op0)
>> > +                 || gimple_val_nonnegative_real_p (op1));
>> > +
>> > +       case MULT_EXPR:
>> > +         /* True if the two operands are identical (since we are
>> > +            restricted to floating-point inputs), or if both operands
>> > +            are nonnegative.  */
>> > +         op0 = gimple_assign_rhs1 (def_stmt);
>> > +         op1 = gimple_assign_rhs2 (def_stmt);
>> > +
>> > +         if (operand_equal_p (op0, op1, 0))
>> > +           return true;
>> > +
>> > +         if (TREE_CODE (op0) == SSA_NAME
>> > +             && TREE_CODE (op1) == SSA_NAME
>> > +             && SSA_NAME_VAR (op0) == SSA_NAME_VAR (op1)
>> > +             && SSA_NAME_VERSION (op0) == SSA_NAME_VERSION (op1))
>> > +           return true;
>>
>> That case is covered by operand_equal_p already.
>
> I don't believe it is, though perhaps it should be.  I didn't see any
> handling for SSA_NAME or tcc_exceptional, and the default just returns
> false, so I added this logic.  Did I miss something subtle?

  if (arg0 == arg1 && ! (flags & OEP_ONLY_CONST)
  && (TREE_CODE (arg0) == SAVE_EXPR
  || (flags & OEP_CONSTANT_ADDRESS_OF)
  || (! TREE_SIDE_EFFECTS (arg0) && ! TREE_SIDE_EFFECTS (arg1
return 1;

should return true.  SSA_NAMEs are shared trees, so your code
is, simplified

   if (op0 == op1)

which you could pre-pend to the operand-equal check to make it cheaper
in the common case.  Thus,

  if (op0 == op1
 

Re: [lto] Unify decl and type registration (issue4515186)

[Diego Novillo]

On Mon, Jun 6, 2011 at 04:50, Richard Guenther  wrote:

> I'd have it done in the loop that computes canonical types, at this
> place we do not gain the advantage that the decl register functions
> get completely fixed up trees.

Hm, yes, I had forgotten about the call to rest_of_decl_compilation.
Patch coming up.


Diego.

Re: [patch] Improve detection of widening multiplication in the vectorizer

[Richard Guenther]

On Mon, Jun 6, 2011 at 3:04 PM, Richard Sandiford
 wrote:
> Richard Guenther  writes:
>> Thanks.  I would hope that we eventually can get rid of the
>> pattern recognizer ... at least for SSE there is also always
>> a scalar variant instruction for each vectorized one.
>
> AFAIK, that isn't true for ARM and NEON.  E.g. I don't know of a single
> instruction that does the scalar equivalent of things like VADDHN
> (add values and narrow to high half), VSUBL.U32 (subtract two values
> and extend the result), etc.
>
> FWIW, I think MIPS only has minimum and maximum operations for paired
> floats, not for single floats or doubles.  I don't have the manuals to
> hand to check though.
>
> It's probably OK for the particular case of widening multiplications.
> It sounded like you were making a more general statement though.
> If so, I think we should try to avoid assuming that every vectorisable
> operation has an equivalent scalar machine instruction.

Hmm, too bad ;)  Yes, I was suggesting that we assume that.  I guess
for now we can go with the vectorizer pattern matching enhancement
and re-visit re-ordering the passes later (I don't have time right now to
look into the reported issue).

Thanks,
Richard.

> Richard
>

Re: [PATCH][ARM] Add support for ADDW and SUBW instructions

[Andrew Stubbs]

On 06/06/11 15:26, Dmitry Plotnikov wrote:

On 06/06/2011 05:33 PM, Andrew Stubbs wrote:

On 06/06/11 14:26, Dmitry Plotnikov wrote:

if (const_ok_for_arm (INTVAL (x))
- || const_ok_for_arm (~INTVAL (x)))
+ || const_ok_for_arm (~INTVAL (x))
+ || (TARGET_THUMB2&& outer == PLUS
+ && (const_ok_for_op (INTVAL (x), outer


Sorry, I should have noticed before ...

This whole condition should be covered by a single call to
const_ok_for_op. It already calls const_ok_for_arm internally.


This condition is not covered by const_ok_for_op, because "outer" can be
equal to other rtx codes, which are not covered in const_ok_for_op like
IF_THEN_ELSE or MULT (I have several ICEs with these codes). I don't
know how to fix this correctly - should I add all codes to
const_ok_for_op or maybe just replace default alternative from
gcc_unreachable() to "return 0;" ?


That sounds reasonable to me - I mean, the constant is indeed not ok for 
those operations.


... but I'm not a maintainer 

Andrew

[Committed] S/390: longlong.h fix smul_ppmm

[Andreas Krebbel]

Hi,

the attached patch fixed a failure with -mzarch -m31.  The smul_ppmm
implementation in longlong.h uses the registers of the result in the
wrong order.

A corresponding patch for glibc will be posted soon.

Committed to 4.6 and mainline.

Bye,

-Andreas-


2011-06-06  Andreas Krebbel  

* longlong.h (smul_ppmm): The resulting register pair contains the
higher order word first.


Index: gcc-4.6/gcc/longlong.h
===
--- gcc-4.6.orig/gcc/longlong.h
+++ gcc-4.6/gcc/longlong.h
@@ -349,7 +349,7 @@ UDItype __umulsidi3 (USItype, USItype);
 __asm__ ("mr\t%%r0,%3"  \
  : "=r" (r0), "=r" (r1) \
  : "r"  (r1),  "r" (m1));   \
-(xh) = r1; (xl) = r0;   \
+(xh) = r0; (xl) = r1;   \
   } while (0)
 #define sdiv_qrnnd(q, r, n1, n0, d) \
   do { \

[PATCH, C++] Use of a variable with undefined value in cp/parser.c?

[Martin Jambor]

Hi,

when testing my new IPA-CP with make profiledbootstrap, I stumbled
across a warning-made-error in parser.c, claiming that parenthesized_p
in cp_parser_parameter_declaration_list is used but undefined.  I do
not understand the code very much but what happens is that the
variable is passed by reference to cp_parser_parameter_declaration and
this is the only call where the function is not passed NULL for that
parameter.  IPA-CP decided to make a specialized version for all the
other calls where the parameter is NULL and therefore this call became
the only one of the original static function and was therefore
inlined.  Somehow the compiler then figured out the variable is never
set but is tested.  Unfortunately something similar elsewhere is
necessary to trigger the warning because it just does not happen if I
do the above manually.

The patch below fixes my problem with profiled bootstrap and is
obviously correct but since if the warning is true there is a
condition in cp_parser_parameter_declaration_list that either is never
true or depends on random input I thought that C++ people might want
to have a look and perhaps remove the parenthesized_p parameter of
cp_parser_parameter_declaration.

All in all, I intend to commit the following in a few days unless
someone stops me.

Thanks,

Martin

2011-06-06  Martin Jambor  

* parser.c (cp_parser_parameter_declaration_list): Initialize
parenthesized_p.

Index: src/gcc/cp/parser.c
===
--- src.orig/gcc/cp/parser.c
+++ src/gcc/cp/parser.c
@@ -15870,7 +15870,7 @@ cp_parser_parameter_declaration_list (cp
 {
   cp_parameter_declarator *parameter;
   tree decl = error_mark_node;
-  bool parenthesized_p;
+  bool parenthesized_p = false;
   /* Parse the parameter.  */
   parameter
= cp_parser_parameter_declaration (parser,

Re: [lto] Merge streamer hooks from pph branch. (issue4568043)

[Richard Guenther]

On Sat, 4 Jun 2011, Diego Novillo wrote:

> On Wed, Jun 1, 2011 at 15:19, Richard Guenther  wrote:
> 
> > Yes, I see no benefit of using a global function to get access
> > to the address of a global variable.
> 
> There is the minor benefit of being able to control  access to it, but
> I don't have a really convincing reason to give you, so I changed it
> to a global.

Thanks.  It feels more consistent this way.

> >> >> +     if (h->indexable_with_decls_p && h->indexable_with_decls_p (expr))
> >> >> +       {
> >> >> +         output_record_start (ob, LTO_global_decl_ref);
> >> >> +         lto_output_var_decl_index (ob->decl_state, ob->main_stream, 
> >> >> expr);
> >> >
> >> > Why hook it this way and not
> >> >
> >> >             if (h->output_tree_ref
> >> >                 && h->output_tree_ref (...))
> >> >               break;
> >> >             gcc_unreachable ();
> >> >
> >> > I find the flag vs. function hook stuff somewhat odd.
> >>
> >> Sure.  It's
> >
> > ... missing words? ;)
> 
> Sorry.  I meant to continue with "It's just that this particular hook
> is simpler if it only needs to decide whether the node can be written
> as a decl reference.  The code to write the node will be the same
> everywhere."  It would lead to duplication and the hooks would need to
> know more internal details of the generic streamer (they need to write
> the reference in exactly the way that lto_input_tree is expecting).
> 
> This is not a flag, actually.  It's a predicate function called on a
> node.  If the node passes the predicate, then it is written in the
> decl index table.

Hm, ok.

> 
> >> >> @@ -1438,8 +1450,27 @@ lto_output_tree (struct output_block *ob, tree 
> >> >> expr, bool ref_p)
> >> >>       to be materialized by the reader (to implement 
> >> >> TYPE_CACHED_VALUES).  */
> >> >>    if (TREE_CODE (expr) == INTEGER_CST)
> >> >>      {
> >> >> -      lto_output_integer_cst (ob, expr, ref_p);
> >> >> -      return;
> >> >> +      bool is_special;
> >> >> +
> >> >> +     /* There are some constants that are special to the streamer
> >> >> +     (e.g., void_zero_node, truthvalue_false_node).
> >> >> +     These constants cannot be rematerialized with
> >> >> +     build_int_cst_wide because they may actually lack a type (like
> >> >> +     void_zero_node) and they need to be pointer-identical to trees
> >> >> +     materialized by the compiler tables like global_trees or
> >> >> +     c_global_trees.
> >> >> +
> >> >> +     If the streamer told us that it has special constants, they
> >> >> +     will be preloaded in the streamer cache.  If we find a match,
> >> >> +     then stream the constant as a reference so the reader can
> >> >> +     re-materialize it from the cache.  */
> >> >> +      is_special = streamer_hooks ()->has_unique_integer_csts_p
> >> >> +                && lto_streamer_cache_lookup (ob->writer_cache, expr, 
> >> >> NULL);
> >> >> +      if (!is_special)
> >> >> +     {
> >> >> +       lto_output_integer_cst (ob, expr, ref_p);
> >> >> +       return;
> >> >> +     }
> >> >
> >> > ???  We should not arrive here for such global trees.  Please do not
> >> > merge this part of the patch as part of the hook introducing (keep
> >> > patches simple, make them do a single thing ...)
> >>
> >> Not sure what you are objecting to.  We do execute this for global
> >> trees in the C++ FE (as described in the comment).  Are you objecting
> >> to never handling unique constants or to merging this handling until
> >> the pph bits are in?
> >
> > Are you not pre-loading those global trees then?
> 
> I am, but since the streamer always wanted to stream INTEGER_CSTs
> separately, it wasn't getting a chance to check the cache first.
> 
> > Yes, I think this isn't the time to merge this piece.
> 
> No problem.  I'll keep this part in the branch.
> 
> > Ah, I think I get it - we don't stream integer constants as trees.
> 
> Right.
> 
> > But it's odd that you only handle this
> > for integer-csts and not other trees we don't stream as-is (and
> > thus do not enter into the cache)
> 
> Because constants are the only ones that are handled right before the
> cache is consulted.  Every other pre-built tree can be cached
> (regardless of whether it's handled by the streamer).
> 
> > - I think this should be moved up a level and made generic to handle all 
> > trees.  Or we should
> > handle integer-csts similar to builtins - always enter them in the cache,
> 
> I tried this, but the result was sub-optimal
> (http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00563.html)
> Putting constants in the cache, caused various failures which I never
> fully debugged because I noticed an increase in the object size (I
> remember it was noticeable, but not by how much).
> 
> I didn't insist too much with this approach, so maybe I could try it again.
> 
> 
> > or only handle all pre-loaded nodes that way.
> 
> That is what we do.  Pre-loaded nodes always go through the cache.
> The problem were pre-loaded constants, since t

[PING][PATCH][all-langs] Defer size_t and sizetype setting to the middle-end

[Richard Guenther]

On Wed, 1 Jun 2011, Richard Guenther wrote:

> 
> This patch defers the control over size_t and sizetype to the
> middle-end which in turn consults the target.  This removes
> various inconsistencies for frontends that do not seem to care
> about size_t and will allow simplifying the global tree initialization.
> 
> Bootstrapped on x86_64-unknown-linux-gnu for all languages, testing
> in progress.
> 
> Ok for trunk?  (the change is worthwhile from an LTO and middle-end
> perspective and I'll apply leeway to frontends that appear to be
> unmaintained - hello Java)

Ping.

Go and C family frontend approval is still missing.

Thanks,
Richard.

> Thanks,
> Richard.
> 
> 2011-06-01  Richard Guenther  
> 
>   * tree.c (build_common_tree_nodes): Also initialize size_type_node.
>   Call set_sizetype from here.
> 
>   c-family/
>   * c-common.c (c_common_nodes_and_builtins): Do not set
>   size_type_node or call set_sizetype.
> 
>   go/
>   * go-lang.c (go_langhook_init): Do not set
>   size_type_node or call set_sizetype.
> 
>   fortran/
>   * f95-lang.c (gfc_init_decl_processing): Do not set
>   size_type_node or call set_sizetype.
> 
>   java/
>   * decl.c (java_init_decl_processing): Properly initialize
>   size_type_node.
> 
>   lto/
>   * lto-lang.c (lto_init): Do not set
>   size_type_node or call set_sizetype.
> 
>   ada/
>   * gcc-interface/misc.c (gnat_init): Do not set
>   size_type_node or call set_sizetype.
> 
> Index: gcc/tree.c
> ===
> --- gcc/tree.c(revision 174520)
> +++ gcc/tree.c(working copy)
> @@ -9142,6 +9142,7 @@ build_common_tree_nodes (bool signed_cha
>  int128_unsigned_type_node = make_unsigned_type (128);
>}
>  #endif
> +
>/* Define a boolean type.  This type only represents boolean values but
>   may be larger than char depending on the value of BOOL_TYPE_SIZE.
>   Front ends which want to override this size (i.e. Java) can redefine
> @@ -9151,6 +9152,17 @@ build_common_tree_nodes (bool signed_cha
>TYPE_MAX_VALUE (boolean_type_node) = build_int_cst (boolean_type_node, 1);
>TYPE_PRECISION (boolean_type_node) = 1;
>  
> +  /* Define what type to use for size_t.  */
> +  if (strcmp (SIZE_TYPE, "unsigned int") == 0)
> +size_type_node = unsigned_type_node;
> +  else if (strcmp (SIZE_TYPE, "long unsigned int") == 0)
> +size_type_node = long_unsigned_type_node;
> +  else if (strcmp (SIZE_TYPE, "long long unsigned int") == 0)
> +size_type_node = long_long_unsigned_type_node;
> +  else
> +gcc_unreachable ();
> +  set_sizetype (size_type_node);
> +
>/* Fill in the rest of the sized types.  Reuse existing type nodes
>   when possible.  */
>intQI_type_node = make_or_reuse_type (GET_MODE_BITSIZE (QImode), 0);
> Index: gcc/c-family/c-common.c
> ===
> --- gcc/c-family/c-common.c   (revision 174520)
> +++ gcc/c-family/c-common.c   (working copy)
> @@ -4666,13 +4666,7 @@ c_common_nodes_and_builtins (void)
>TYPE_DECL, NULL_TREE,
>widest_unsigned_literal_type_node));
>  
> -  /* `unsigned long' is the standard type for sizeof.
> - Note that stddef.h uses `unsigned long',
> - and this must agree, even if long and int are the same size.  */
> -  size_type_node =
> -TREE_TYPE (identifier_global_value (get_identifier (SIZE_TYPE)));
>signed_size_type_node = c_common_signed_type (size_type_node);
> -  set_sizetype (size_type_node);
>  
>pid_type_node =
>  TREE_TYPE (identifier_global_value (get_identifier (PID_TYPE)));
> Index: gcc/go/go-lang.c
> ===
> --- gcc/go/go-lang.c  (revision 174520)
> +++ gcc/go/go-lang.c  (working copy)
> @@ -87,15 +87,6 @@ go_langhook_init (void)
>  {
>build_common_tree_nodes (false);
>  
> -  /* The sizetype may be "unsigned long" or "unsigned long long".  */
> -  if (TYPE_MODE (long_unsigned_type_node) == ptr_mode)
> -size_type_node = long_unsigned_type_node;
> -  else if (TYPE_MODE (long_long_unsigned_type_node) == ptr_mode)
> -size_type_node = long_long_unsigned_type_node;
> -  else
> -size_type_node = long_unsigned_type_node;
> -  set_sizetype (size_type_node);
> -
>build_common_tree_nodes_2 (0);
>  
>/* We must create the gogo IR after calling build_common_tree_nodes
> Index: gcc/fortran/f95-lang.c
> ===
> --- gcc/fortran/f95-lang.c(revision 174520)
> +++ gcc/fortran/f95-lang.c(working copy)
> @@ -590,9 +590,6 @@ gfc_init_decl_processing (void)
>   want double_type_node to actually have double precision.  */
>build_common_tree_nodes (false);
>  
> -  size_type_node = gfc_build_uint_type (POINTER_SIZE);
> -  set_sizetype (size_typ

Re: AIX net/if_arp.h include fix for struct fc_softc

[David Edelsohn]

On Mon, Jun 6, 2011 at 12:16 AM, Peter O'Gorman
 wrote:
> Hi,
>
> We ran across an issue with qt-4.7 built with gcc-4.4 on AIX 5.2, 5.3,
> 6.1, and 7.1 where some static constructors were not being called. It
> turned out to be a header file issue, see, for example,
> https://www.ibm.com/developerworks/forums/thread.jspa?threadID=211873&tstart=-2
>
> Using fixincludes to fix the header allows us to build a working qt.
>
> The erroneous struct declaration is:
> struct  fc_softc {
>        struct arpcom   fc_ac;              /* FCS common part             */
>        struct ndd    *nddp;                /* returned from NS            */
>        int(*efcnet_arp_fct)
>             (struct ndd *, struct mbuf *); /* efcnet_arp function address */
> } *fc_softc ;
>
> when fixed it becomes:
> typedef struct _fc_softc {
>        struct arpcom   fc_ac;              /* FCS common part             */
>        struct ndd    *nddp;                /* returned from NS            */
>        int(*efcnet_arp_fct)
>             (struct ndd *, struct mbuf *); /* efcnet_arp function address */
> } *fc_softc ;
>
> David, do you have any idea if this is what it's supposed to be?
>
> Ok for trunk?

The header certainly does not make sense as is and does not follow AIX
header file conventions.  typedef is the only thing that makes sense,
which was confirmed by some other AIX developer with whom I checked.
(I would have expected fc_softc_t as well if it was intended as a
typedef, but that's a separate issue.)

This change is okay.

I will try to find the AIX header owners to fix the problem as well.

Thanks, David

Re: [lto] Merge streamer hooks from pph branch. (issue4568043)

[Diego Novillo]

On Mon, Jun 6, 2011 at 10:50, Richard Guenther  wrote:

> Do you remember if it was only void_zero_node that causes problems?
> We could just special-case it in
> lto_input_integer_cst/lto_output_integer_cst.  Or even fix the C family
> frontends to not create or use this strange node.  It seems to be
> a special tree for "empty valid something" which could as well be
> a new tree code with a singleton object.

void_zero_node was the only one causing problems because it couldn't
be built with build_int_cst_wide.  However, the other well-known
constants where causing problem when the parser tried to
pointer-compare them.  This sounded a bit strange to me, since I was
expecting the constant cache in the type to give back shared
constants, but I did not investigate it further.

Making void_zero_node a new singleton object sounds like a good cleanup.


Diego.

Re: PATCH [1/n]: Add initial -x32 support

[Uros Bizjak]

On Sun, Jun 5, 2011 at 9:54 PM, H.J. Lu  wrote:

> I'd like to start submitting a series of patches to enable x32:
>
> https://sites.google.com/site/x32abi/
>
> The GCC x32 branch is very stable. There are no unexpected failures in
> C, C++, Fortran and Objective C testsuites.  SPEC CPU 2K/2006 compile
> and run correctly at -O2 and -O3.
>
> More than 90% of changes are in x86 backend.  This is the first patch to
> support x32.  By default, x32 is disabled and x32 run-time support
> isn't required.  OK for trunk?

I'd suggest to first post for review and later commit target
independent fixes in the middle-end, then fixes/improvements in
generic i386 parts and at last strict x32 target stuff. IIRC, ther are
many inconsistencies w.r.t. ptr_size != size of Pmode in both,
middle-end and generic i386 parts, and this way I hope we will avoid
problems if change in lower layers is based on wrong assumptions.

I also suggest to rename t-linuxx32 to t-linux-x32.

Thanks,
Uros.

Re: -fdump-passes -fenable-xxx=func_name_list

[Xinliang David Li]

On Mon, Jun 6, 2011 at 4:22 AM, Richard Guenther
 wrote:
> On Wed, Jun 1, 2011 at 7:24 PM, Xinliang David Li  wrote:
>> The attached is the split #1 patch that enhances -fenable/disable.
>>
>> Ok after testing?
>
> I expect the testcases will be quite fragile, so while I appreciate
> test coverage for new options I think we should go without those
> that involve any kind of UID.  Those which use assembler names
> also will fail randomly dependent on how targets mangle their
> functions - so I think we have to drop all testcases.

Ok -- how about keeping tests with large uid range, and assembler name
for x86? A feature without testing is just to easy to break without
being noticed.

>
> Also
>
> +/* A helper function to determine if an identifier is valid to
> +   be an assembler name (better to use target specific hook).  */
> +
> +static bool
> +is_valid_assembler_name (const char *str)
> +{
> +  const char *p = str;
> +  char c;
> +
> +  c = *p;
> +  if (!((c >= 'a' && c <= 'z')
> +        || (c >= 'A' && c <= 'Z')
> +        || *p == '_'))
> +    return false;
> +
> +  p++;
> +  while ((c = *p))
> +   {
> +     if (!((c >= 'a' && c <= 'z')
> +           || (c >= 'A' && c <= 'Z')
> +           || (c >= '0' && c <= '9')
> +           || *p == '_'))
> +       return false;
> +     p++;
> +   }
> +
> +  return true;
> +}
>
> why all that complicated checks?  Why not just check for p[0]
> in [^0-9] and re-structure the range parsing to switch between
> UIDs and assembler-names that way?

Ok.

David

>
> Thanks,
> Richard.
>
>> Thanks,
>> David
>>
>> On Wed, Jun 1, 2011 at 9:16 AM, Xinliang David Li  wrote:
>>> On Wed, Jun 1, 2011 at 1:51 AM, Richard Guenther
>>>  wrote:
 On Wed, Jun 1, 2011 at 1:34 AM, Xinliang David Li  
 wrote:
> The following patch implements the a new option that dumps gcc PASS
> configuration. The sample output is attached.  There is one
> limitation: some placeholder passes that are named with '*xxx' are
> note registered thus they are not listed. They are not important as
> they can not be turned on/off anyway.
>
> The patch also enhanced -fenable-xxx and -fdisable-xx to allow a list
> of function assembler names to be specified.
>
> Ok for trunk?

 Please split the patch.

 I'm not too happy how you dump the pass configuration.  Why not simply,
 at a _single_ place, walk the pass tree?  Instead of doing pieces of it
 at pass execution time when it's not already dumped - that really looks
 gross.
>>>
>>> Yes, that was the original plan -- but it has problems
>>> 1) the dumper needs to know the root pass lists -- which can change
>>> frequently -- it can be a long term maintanance burden;
>>> 2) the centralized dumper needs to be done after option processing
>>> 3) not sure if gate functions have any side effects or have dependencies on 
>>> cfun
>>>
>>> The proposed solutions IMHO is not that intrusive -- just three hooks
>>> to do the dumping and tracking indentation.
>>>

 The documentation should also link this option to the -fenable/disable
 options as obviously the pass names in that dump are those to be
 used for those flags (and not readily available anywhere else).
>>>
>>> Ok.
>>>

 I also think that it would be way more useful to note in the individual
 dump files the functions (at the place they would usually appear) that
 have the pass explicitly enabled/disabled.
>>>
>>> Ok -- for ipa passes or tree/rtl passes where all functions are
>>> explicitly disabled.
>>>
>>> Thanks,
>>>
>>> David
>>>

 Richard.

> Thanks,
>
> David
>

>>>
>>
>

Re: -fdump-passes -fenable-xxx=func_name_list

[Richard Guenther]

On Mon, Jun 6, 2011 at 5:53 PM, Xinliang David Li  wrote:
> On Mon, Jun 6, 2011 at 4:22 AM, Richard Guenther
>  wrote:
>> On Wed, Jun 1, 2011 at 7:24 PM, Xinliang David Li  wrote:
>>> The attached is the split #1 patch that enhances -fenable/disable.
>>>
>>> Ok after testing?
>>
>> I expect the testcases will be quite fragile, so while I appreciate
>> test coverage for new options I think we should go without those
>> that involve any kind of UID.  Those which use assembler names
>> also will fail randomly dependent on how targets mangle their
>> functions - so I think we have to drop all testcases.
>
> Ok -- how about keeping tests with large uid range, and assembler name
> for x86? A feature without testing is just to easy to break without
> being noticed.

That's true.  Running the tests on a few selected known-good targets
sounds good.

Richard.

>>
>> Also
>>
>> +/* A helper function to determine if an identifier is valid to
>> +   be an assembler name (better to use target specific hook).  */
>> +
>> +static bool
>> +is_valid_assembler_name (const char *str)
>> +{
>> +  const char *p = str;
>> +  char c;
>> +
>> +  c = *p;
>> +  if (!((c >= 'a' && c <= 'z')
>> +        || (c >= 'A' && c <= 'Z')
>> +        || *p == '_'))
>> +    return false;
>> +
>> +  p++;
>> +  while ((c = *p))
>> +   {
>> +     if (!((c >= 'a' && c <= 'z')
>> +           || (c >= 'A' && c <= 'Z')
>> +           || (c >= '0' && c <= '9')
>> +           || *p == '_'))
>> +       return false;
>> +     p++;
>> +   }
>> +
>> +  return true;
>> +}
>>
>> why all that complicated checks?  Why not just check for p[0]
>> in [^0-9] and re-structure the range parsing to switch between
>> UIDs and assembler-names that way?
>
> Ok.
>
> David
>
>>
>> Thanks,
>> Richard.
>>
>>> Thanks,
>>> David
>>>
>>> On Wed, Jun 1, 2011 at 9:16 AM, Xinliang David Li  
>>> wrote:
 On Wed, Jun 1, 2011 at 1:51 AM, Richard Guenther
  wrote:
> On Wed, Jun 1, 2011 at 1:34 AM, Xinliang David Li  
> wrote:
>> The following patch implements the a new option that dumps gcc PASS
>> configuration. The sample output is attached.  There is one
>> limitation: some placeholder passes that are named with '*xxx' are
>> note registered thus they are not listed. They are not important as
>> they can not be turned on/off anyway.
>>
>> The patch also enhanced -fenable-xxx and -fdisable-xx to allow a list
>> of function assembler names to be specified.
>>
>> Ok for trunk?
>
> Please split the patch.
>
> I'm not too happy how you dump the pass configuration.  Why not simply,
> at a _single_ place, walk the pass tree?  Instead of doing pieces of it
> at pass execution time when it's not already dumped - that really looks
> gross.

 Yes, that was the original plan -- but it has problems
 1) the dumper needs to know the root pass lists -- which can change
 frequently -- it can be a long term maintanance burden;
 2) the centralized dumper needs to be done after option processing
 3) not sure if gate functions have any side effects or have dependencies 
 on cfun

 The proposed solutions IMHO is not that intrusive -- just three hooks
 to do the dumping and tracking indentation.

>
> The documentation should also link this option to the -fenable/disable
> options as obviously the pass names in that dump are those to be
> used for those flags (and not readily available anywhere else).

 Ok.

>
> I also think that it would be way more useful to note in the individual
> dump files the functions (at the place they would usually appear) that
> have the pass explicitly enabled/disabled.

 Ok -- for ipa passes or tree/rtl passes where all functions are
 explicitly disabled.

 Thanks,

 David

>
> Richard.
>
>> Thanks,
>>
>> David
>>
>

>>>
>>
>

Re: -fdump-passes -fenable-xxx=func_name_list

[Xinliang David Li]

On Mon, Jun 6, 2011 at 4:38 AM, Richard Guenther
 wrote:
> On Thu, Jun 2, 2011 at 9:12 AM, Xinliang David Li  wrote:
>> This is the version of the patch that walks through pass lists.
>>
>> Ok with this one?
>
> +/* Dump all optimization passes.  */
> +
> +void
> +dump_passes (void)
> +{
> +  struct cgraph_node *n, *node = NULL;
> +  tree save_fndecl = current_function_decl;
> +
> +  fprintf (stderr, "MAX_UID = %d\n", cgraph_max_uid);
>
> this isn't accurate info - cloning can cause more cgraph nodes to
> appear (it also looks completely unrelated to dump_passes ...).
> Please drop it.

Ok.


>
> +  create_pass_tab();
> +  gcc_assert (pass_tab);
>
> you have quite many asserts of this kind - we don't want them when
> the previous stmt as in this case indicates everything is ok.

ok.

>
> +  push_cfun (DECL_STRUCT_FUNCTION (node->decl));
>
> this has side-effects, I'm not sure we want this here.  Why do you
> need it?  Probably because of
>
> +  is_really_on = override_gate_status (pass, current_function_decl, is_on);
>
> ?  But that is dependent on the function given which should have no
> effect (unless it is overridden globally in which case override_gate_status
> and friends should deal with a NULL cfun).

As we discussed, currently some pass gate functions depend on per node
information -- those checks need to be pushed into execute functions.
I would like to clean those up later -- at which time, the push/pop
can be removed.

>
> I don't understand why you need another table mapping pass to name
> when pass->name is available and the info is trivially re-constructible.

This is needed as the pass->name is not the canonicalized name (i.e.,
not with number suffix etc), so the extra mapping from id to
normalized name is needed.

Thanks,

David

>
> Thanks,
> Richard.
>
>> David
>>
>> On Wed, Jun 1, 2011 at 12:45 PM, Xinliang David Li  
>> wrote:
>>> On Wed, Jun 1, 2011 at 12:29 PM, Richard Guenther
>>>  wrote:
 On Wed, Jun 1, 2011 at 6:16 PM, Xinliang David Li  
 wrote:
> On Wed, Jun 1, 2011 at 1:51 AM, Richard Guenther
>  wrote:
>> On Wed, Jun 1, 2011 at 1:34 AM, Xinliang David Li  
>> wrote:
>>> The following patch implements the a new option that dumps gcc PASS
>>> configuration. The sample output is attached.  There is one
>>> limitation: some placeholder passes that are named with '*xxx' are
>>> note registered thus they are not listed. They are not important as
>>> they can not be turned on/off anyway.
>>>
>>> The patch also enhanced -fenable-xxx and -fdisable-xx to allow a list
>>> of function assembler names to be specified.
>>>
>>> Ok for trunk?
>>
>> Please split the patch.
>>
>> I'm not too happy how you dump the pass configuration.  Why not simply,
>> at a _single_ place, walk the pass tree?  Instead of doing pieces of it
>> at pass execution time when it's not already dumped - that really looks
>> gross.
>
> Yes, that was the original plan -- but it has problems
> 1) the dumper needs to know the root pass lists -- which can change
> frequently -- it can be a long term maintanance burden;
> 2) the centralized dumper needs to be done after option processing
> 3) not sure if gate functions have any side effects or have dependencies 
> on cfun
>
> The proposed solutions IMHO is not that intrusive -- just three hooks
> to do the dumping and tracking indentation.

 Well, if you have a CU that is empty or optimized to nothing at some point
 you will not get a complete pass list.  I suppose optimize attributes might
 also confuse output.  Your solution might not be that intrusive
 but it is still ugly.  I don't see 1) as an issue, for 2) you can just 
 call the
 dumping from toplev_main before calling do_compile (), 3) gate functions
 shouldn't have side-effects, but as they could gate on optimize_for_speed 
 ()
 your option summary output will be bogus anyway.

 So - what is the output intended for if it isn't reliable?
>>>
>>> This needs to be cleaned up at some point -- the gate function should
>>> behave the same for all functions and per-function decisions need to
>>> be pushed down to the executor body.  I will try to rework the patch
>>> as you suggested to see if there are problems.
>>>
>>> David
>>>
>>>

 Richard.

>>
>> The documentation should also link this option to the -fenable/disable
>> options as obviously the pass names in that dump are those to be
>> used for those flags (and not readily available anywhere else).
>
> Ok.
>
>>
>> I also think that it would be way more useful to note in the individual
>> dump files the functions (at the place they would usually appear) that
>> have the pass explicitly enabled/disabled.
>
> Ok -- for ipa passes or tree/rtl passes where all functions are
> explicitly disabled.
>
> Thanks,
>
>

Re: [PATCH, ARM] Fix ABI for double-precision helpers on single-float-only CPUs

[Richard Earnshaw]

On 06/03/11 18:41, Julian Brown wrote:

On Thu, 02 Jun 2011 16:35:01 +0100
Richard Earnshaw  wrote:

   

I see Paul has already approved this, but I've just spotted one
potential problem that might cause latent bugs sometime in the future.

The code to register the libcalls is only run once, the first time we
try to look up a libcall.  If we ever end up allowing dynamic changing
of CPU and optimization options, not registering the other libcalls
will lead to subtle problems at run time.  I suggest that these
functions be unconditionally added along with the other libcalls.
 

Done.

   

I also don't understand why all the tests are needed in
arm_init_cumulative_args?  Surely arm_libcall_uses_aapcs_base() will
already have run that test.
 

I did some archaeology to try to figure out why things were like that
(the patch was written a while ago) -- and yeah, it looks like it's
completely unnecessary to have those tests in arm_init_cumulative_args.
That bit of code was refactored a while ago, and it looks like the
patch wasn't ever updated properly. My mistake!

I'm re-testing the attached version.

Thanks,

Julian

ChangeLog

 gcc/
 * config/arm/arm.c (arm_libcall_uses_aapcs_base): Use correct ABI
 for double-precision helper functions in hard-float mode if only
 single-precision arithmetic is supported in hardware.


OK.

R.

Re: [ARM] TLS Descriptor support

[Ramana Radhakrishnan]

On 6 June 2011 10:56, Nathan Sidwell  wrote:
> On 06/06/11 10:53, Ramana Radhakrishnan wrote:
>>>
>>> If you're asking something else, can you rephrase the question?
>>
>> Sorry if I wasn't too clear.  My question really should have read "why
>> do we have to special case Thumb2" ? The linker should be able to
>> veneer the t->  a calls either through the veneering sequence (in case
>> of T1 without blx) or convert the bl to a blx (modulo the case with
>> out of range branches). As I said I'm probably missing something here.
>
> Maybe we don't.  It just seems neater to emit blx on arches that have it.
>

In which case the test should probably read -

(arm_arch5 && TARGET_THUMB) rather than (TARGET_THUMB2) since blx
exists since v5t

cheers
Ramana

Re: [patch gimplify]: Make sure comparison using boolean-type after gimplification

[Diego Novillo]

On Thu, May 26, 2011 at 07:02, Richard Guenther
 wrote:

>  81764   dnovillo       {
>  81764   dnovillo         if (TREE_CODE (type) == BOOLEAN_TYPE)
>  81764   dnovillo           {
>  81764   dnovillo             arg0 = copy_node (arg0);
>  81764   dnovillo             TREE_TYPE (arg0) = type;
>  81764   dnovillo             return arg0;
>  81764   dnovillo           }
>
> (famous tree-ssa merge revision).
>
> So - lets ask who still is around.  Diego? ;)

I just saw this in my inbox, sorry.  What's the question?  Whether I
remember this code in fold?  Not offhand.  If it looks weird and/or is
not working right, feel free to toss it.


Diego.

Re: AIX net/if_arp.h include fix for struct fc_softc

[Peter O'Gorman]

On Mon, Jun 06, 2011 at 11:05:25AM -0400, David Edelsohn wrote:
> > David, do you have any idea if this is what it's supposed to be?
> >
> > Ok for trunk?
> 
> The header certainly does not make sense as is and does not follow AIX
> header file conventions.  typedef is the only thing that makes sense,
> which was confirmed by some other AIX developer with whom I checked.
> (I would have expected fc_softc_t as well if it was intended as a
> typedef, but that's a separate issue.)
> 
> This change is okay.

Thanks, committed in r174707 with Bruce's change to the test.

> 
> I will try to find the AIX header owners to fix the problem as well.

That would be great.

Peter
-- 
Peter O'Gorman
po...@thewrittenword.com

Re: Dump before flag

[Xinliang David Li]

>
> Your patch doesn't really improve this but adds to the confusion.
>
> +  /* Override dump TODOs.  */
> +  if (dump_file && (pass->todo_flags_finish & TODO_dump_func)
> +      && (dump_flags & TDF_BEFORE))
> +    {
> +      pass->todo_flags_finish &= ~TODO_dump_func;
> +      pass->todo_flags_start |= TODO_dump_func;
> +    }
>
> and certainly writing to pass is not ok.  And the TDF_BEFORE flag
> looks misplaced as it controls TODOs, not dumping behavior.
> Yes, it's a mess right now but the above looks like a hack ontop
> of that mess (maybe because of it, but well ...).
>

How about removing dumping TODO completely -- this can be done easily
-- I don't understand why pass wants extra control on the dumping if
user already asked for dumping -- it is annoying to see empty IR dump
for a pass when I want to see it.

> At least I would have expected to also get the dump after the
> pass, not only the one before it with this dump flag.
>
> Now, why can't you look at the previous pass output for the
> before-dump (as I do usually)?

For one thing, you need to either remember what is the previous pass,
or dump all passes which for large files can take very long time. Even
with all the dumps, you will need to eyeballing to find the previous
pass which may or may not have the IR dumped.

How about removing dump TODO?

Thanks,

David


>
> Richard.
>

Re: [ARM] TLS Descriptor support

[Richard Earnshaw]

On 05/10/11 07:49, Nathan Sidwell wrote:
This patch implements TLS descriptor support in GCC.  TLS descriptors 
are described at 
http://www.codesourcery.com/publications/RFC-TLSDESC-ARM.txt and 
blessed by ARM, who have reserved the relocation numbers.


Binutils and GLIBC patches are already committed (there is an 
orthogonal glibc patch to do with make dependencies that I need to 
post though).


This patch adds a --with-tls={arm|gnu} configuration option, to 
specify the default scheme.  It can be overridden with a 
-mtls-dialect={arm|gnu} option (this is the name used by the x86 
backend, which also has tlsdescriptor support).  I have not added 
--with-tls support to the x86 bits of config.gcc etc, but it would be 
simple to do so.


The arm.{c,h,md} changes are fairly mechanical -- a new tls pattern 
and smarts to emit it appropriately.


This patch has been tested for both default arm and default gnu tls 
schemes using the gcc and glibc testsuites for an arm-linux-gnueabi 
target.


ok?

nathan


+/* The + is to avoid an assembly parse ambiguity with symbols that
+   look like register names, which is unsuccessfully recovered 
from.  */

+return TARGET_THUMB2 ? "blx\\t%c0(tlscall)" : "bl\\t+%c0(tlscall)";


Eh?  This is backwards.  There is blx , but no bl .  If the 
assembler gets confused with 'bl r0' then it needs to be fixed urgently.


Further, both the assembler and the linker know how to change bl to blx 
when needed, so it's best to just put out bl and be done with it.


R.

Re: [PING][PATCH][all-langs] Defer size_t and sizetype setting to the middle-end

[Ian Lance Taylor]

Richard Guenther  writes:

>> 2011-06-01  Richard Guenther  
>> 
>>  * tree.c (build_common_tree_nodes): Also initialize size_type_node.
>>  Call set_sizetype from here.
>> 
>>  c-family/
>>  * c-common.c (c_common_nodes_and_builtins): Do not set
>>  size_type_node or call set_sizetype.
>> 
>>  go/
>>  * go-lang.c (go_langhook_init): Do not set
>>  size_type_node or call set_sizetype.
>> 
>>  fortran/
>>  * f95-lang.c (gfc_init_decl_processing): Do not set
>>  size_type_node or call set_sizetype.
>> 
>>  java/
>>  * decl.c (java_init_decl_processing): Properly initialize
>>  size_type_node.
>> 
>>  lto/
>>  * lto-lang.c (lto_init): Do not set
>>  size_type_node or call set_sizetype.
>> 
>>  ada/
>>  * gcc-interface/misc.c (gnat_init): Do not set
>>  size_type_node or call set_sizetype.

The change to the Go frontend is fine.

The change to the C frontend is fine too unless somebody objects soon.

Ian

[v3] Small tweak to std::move_if_noexcept

[Paolo Carlini]

Hi,

noticed while working on std::vector. Tested x86_64-linux, committed.

Paolo.

///
2011-06-06  Paolo Carlini  

* include/bits/move.h (move_if_noexcept): Use __and_ and __not_.
Index: include/bits/move.h
===
--- include/bits/move.h (revision 174699)
+++ include/bits/move.h (working copy)
@@ -90,8 +90,8 @@
*/
   template
 inline typename
-conditional<(!is_nothrow_move_constructible<_Tp>::value
-&& is_copy_constructible<_Tp>::value),
+conditional<__and_<__not_>,
+   is_copy_constructible<_Tp>>::value,
 const _Tp&, _Tp&&>::type
 move_if_noexcept(_Tp& __x) noexcept
 { return std::move(__x); }

[testsuite] Compile gfortran.dg/graphite/vect-pr40979.f90 with -msse2 on x86 (PR tree-optimization/48497)

[Rainer Orth]

As described in the PR, gfortran.dg/graphite/vect-pr40979.f90 FAILs on
Solaris 8 and 9/x86, which defaults to -march=pentiumpro:

FAIL: gfortran.dg/graphite/vect-pr40979.f90  -O  scan-tree-dump-times vect 
"vectorized 1 loops" 1

The dump contains 'vectorized 0 loops' instead.  The test passes with
-march=pentium4 and also with -msse2.  Since the test is compiled with a
long bunch of options, it seemed inappropriate to use dg-options and
repeat that list, just to add -msse2.  Instead, I've chosen to implement
dg-additional-options, which unlike dg-options just adds to the list of
default options.

I've missed this facility myself many times, and it seems like a
straightforward addition.

Bootstrapped without regressions on i386-pc-solaris2.8 and
i386-pc-solaris2.11, will commit to mainline in a day or two unless
someone objects.

Rainer


2011-05-29  Rainer Orth  

gcc:
PR tree-optimization/48497
* doc/sourcebuild.texi (Directives, dg-additional-options): Document.

gcc/testsuite:
PR tree-optimization/48497
* lib/gcc-defs.exp (dg-additional-options): New proc.
* gfortran.dg/graphite/vect-pr40979.f90: Use dg-additional-options
-msse2 on 32-bit x86.

diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -1016,6 +1016,11 @@ This directive does nothing on targets t
 default, or that don't provide them at all.  It must come after
 all @code{dg-options} directives.
 For supported values of @var{feature} see @ref{Add Options, ,}.
+
+@item @{ dg-additional-options @var{options} [@{ target @var{selector} @}] @}
+This directive provides a list of compiler options, to be used
+if the target system matches @var{selector}, that are added to the default
+options used for this set of tests.
 @end table
 
 @subsubsection Modify the test timeout value
diff --git a/gcc/testsuite/gfortran.dg/graphite/vect-pr40979.f90 
b/gcc/testsuite/gfortran.dg/graphite/vect-pr40979.f90
--- a/gcc/testsuite/gfortran.dg/graphite/vect-pr40979.f90
+++ b/gcc/testsuite/gfortran.dg/graphite/vect-pr40979.f90
@@ -1,5 +1,6 @@
 ! { dg-do compile }
 ! { dg-require-effective-target vect_double }
+! { dg-additional-options "-msse2" { target { { i?86-*-* x86_64-*-* } && ilp32 
} } }
 
 module mqc_m
 integer, parameter, private :: longreal = selected_real_kind(15,90)
diff --git a/gcc/testsuite/lib/gcc-defs.exp b/gcc/testsuite/lib/gcc-defs.exp
--- a/gcc/testsuite/lib/gcc-defs.exp
+++ b/gcc/testsuite/lib/gcc-defs.exp
@@ -183,6 +183,28 @@ if { [info procs runtest_file_p] == "" }
 }
 }
 
+# Like dg-options, but adds to the default options rather than replacing them.
+
+proc dg-additional-options { args } {
+upvar dg-extra-tool-flags extra-tool-flags
+
+if { [llength $args] > 3 } {
+   error "[lindex $args 0]: too many arguments"
+   return
+}
+
+if { [llength $args] >= 3 } {
+   switch [dg-process-target [lindex $args 2]] {
+   "S" { eval lappend extra-tool-flags [lindex $args 1] }
+   "N" { }
+   "F" { error "[lindex $args 0]: `xfail' not allowed here" }
+   "P" { error "[lindex $args 0]: `xfail' not allowed here" }
+   }
+} else {
+   eval lappend extra-tool-flags [lindex $args 1]
+}
+}
+
 # Record additional sources files that must be compiled along with the
 # main source file.
 


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

Re: [lto] Unify decl and type registration (issue4515186)

[Diego Novillo]

On Mon, Jun 6, 2011 at 10:27, Diego Novillo  wrote:
> On Mon, Jun 6, 2011 at 04:50, Richard Guenther  wrote:
>
>> I'd have it done in the loop that computes canonical types, at this
>> place we do not gain the advantage that the decl register functions
>> get completely fixed up trees.
>
> Hm, yes, I had forgotten about the call to rest_of_decl_compilation.
> Patch coming up.

You mean this?  Currently under testing.


* lto.c (uniquify_nodes): Move code to register decls to
the loop that computes canonical types.

diff --git a/gcc/lto/lto.c b/gcc/lto/lto.c
index 74dfecd..6e49ee7 100644
--- a/gcc/lto/lto.c
+++ b/gcc/lto/lto.c
@@ -651,21 +651,13 @@ uniquify_nodes (struct data_in *data_in, unsigned from)
   /* Go backwards because children streamed for the first time come
  as part of their parents, and hence are created after them.  */

-  /* First register all declarations and types in the cache.
- This makes sure to have the original structure in the type cycles
- when registering them and computing hashes.  */
+  /* First register all the types in the cache.  This makes sure to
+ have the original structure in the type cycles when registering
+ them and computing hashes.  */
   for (i = len; i-- > from;)
 {
   tree t = VEC_index (tree, cache->nodes, i);
-
-  if (t == NULL_TREE)
-   continue;
-
-  if (TREE_CODE (t) == VAR_DECL)
-   lto_register_var_decl_in_symtab (data_in, t);
-  else if (TREE_CODE (t) == FUNCTION_DECL && !DECL_BUILT_IN (t))
-   lto_register_function_decl_in_symtab (data_in, t);
-  else if (TYPE_P (t))
+  if (t && TYPE_P (t))
gimple_register_type (t);
 }

@@ -788,19 +780,23 @@ uniquify_nodes (struct data_in *data_in, unsigned from)
}
 }

-  /* Finally compute the canonical type of t.  From this point
- there are no longer any types with TYPE_STRUCTURAL_EQUALITY_P
- and its type-based alias problems.  This step requires the
- TYPE_POINTER_TO lists being present, so make sure it is done
- last.  */
+  /* Finally compute the canonical type of all TREE_TYPEs and register
+ VAR_DECL and FUNCTION_DECL nodes in the symbol table.
+ From this point there are no longer any types with
+ TYPE_STRUCTURAL_EQUALITY_P and its type-based alias problems.
+ This step requires the TYPE_POINTER_TO lists being present, so
+ make sure it is done last.  */
   for (i = len; i-- > from;)
 {
   tree t = VEC_index (tree, cache->nodes, i);
-  if (!t
- || !TYPE_P (t))
+  if (t == NULL_TREE)
continue;

-  if (!TYPE_CANONICAL (t))
+  if (TREE_CODE (t) == VAR_DECL)
+   lto_register_var_decl_in_symtab (data_in, t);
+  else if (TREE_CODE (t) == FUNCTION_DECL && !DECL_BUILT_IN (t))
+   lto_register_function_decl_in_symtab (data_in, t);
+  else if (TYPE_P (t) && !TYPE_CANONICAL (t))
TYPE_CANONICAL (t) = gimple_register_canonical_type (t);
 }
 }

Re: [PATCH] cleanup: local label prefix

[Richard Earnshaw]

On 05/20/11 11:13, Greta Yorsh wrote:

This patch replaces a hardcoded "." of local label prefix with
LOCAL_LABEL_PREFIX macro in the ARM backend (generating a "trampoline" in
thumb mode).

The patch also contains a new test to make sure that the local label
".Ltrampoline_start:" is generated correctly.

No regressions on arm-none-eabi.



-- Greta



gcc/Changelog:

2011-05-13  Greta Yorsh

* config/arm/arm.c: Replace hardcoded "." of local label prefix
with LOCAL_LABEL_PREFIX macro.

gcc/testsuite/ChangeLog:

2011-05-13  Greta Yorsh

* gcc.target/arm/trampoline-1.c: New test, to make sure
the local label ".Ltrampoline" is generated correctly.



OK.

R.

Re: [google]Skip target-libiberty for arm*-*-linux-androideabi (issue4564050)

[jingyu]

The trunk version has been approved and committed as r174710. Backport
it to google/main. The google/main version has the same logic but is
slightly different since trunk has a different code structure here. OK
for google/main?

2011-06-06  Jing Yu  

Backport trunk r174710:

* configure.ac: Skip target-libiberty for arm*-*-linux-androideabi.
* configure: Regenerated.

http://codereview.appspot.com/4564050/

Re: [PATCH] PR fortran/49268

[Langton, Asher]

On 6/2/11 2:42 PM, "Langton, Asher"  wrote:
>On 6/2/11 2:11 PM, "Steve Kargl"  wrote:
>>On Thu, Jun 02, 2011 at 01:59:03PM -0700, Langton, Asher wrote:
>>> This patch fixes a bug where the wrong code was generated for
>>>assumed-size
>>> Cray pointees. The fix is simple, but a bit ugly. Bootstrapped and
>>> regression-tested on x86_64-unknown-linux-gnu. Okay for trunk?
>>> 
>>> Thanks,
>>> Asher
>>> 
>>> 2011-06-02  Asher Langton  
>>> 
>>> PR fortran/49268
>>> * trans-decl.c (gfc_trans_deferred_vars): Treat assumed-size
>>>Cray
>>> pointees as AS_EXPLICIT.
>>> 
>>> 2011-06-02  Asher Langton  
>>> 
>>> PR fortran/49268
>>> * gfortran.dg/PR49268.f90: New test.
>>
>>OK.
>
>Committed at revision 174584.

A gfortran user here at LLNL asked if this could be backported to the 4.6
branch. I bootstrapped and regression-tested on x86_64-unknown-linux-gnu.
Okay for 4.6?

Thanks,
Asher



PR49268-4_6.diff
Description: PR49268-4_6.diff

Re: [google]Skip target-libiberty for arm*-*-linux-androideabi (issue4564050)

[Carrot Wei]

OK.

thanks
Carrot

On Tue, Jun 7, 2011 at 1:09 AM,   wrote:
> The trunk version has been approved and committed as r174710. Backport
> it to google/main. The google/main version has the same logic but is
> slightly different since trunk has a different code structure here. OK
> for google/main?
>
> 2011-06-06  Jing Yu  
>
>        Backport trunk r174710:
>
>        * configure.ac: Skip target-libiberty for arm*-*-linux-androideabi.
>        * configure: Regenerated.
>
> http://codereview.appspot.com/4564050/
>

[PATCH, libstdc++-v3] Add newlib specific ctype_members.cc

[Yufeng Zhang]

Hi,

This patch fixes an issue in the ctype implementation when the
newlib C library is used.

The generic version of ctype::_M_convert_to_wmask() in
config/locale/generic/ctype_members.cc assumes that a character type
mask is either a bitmask with only 1 bit set or a bitwise-OR result of
other character type masks; for instance, as illustrated in the C++
Standard 2003 TC1 [lib.category.ctype]:

  enum mask { // numeric values are for exposition only.
space=1<<0, print=1<<1, cntrl=1<<2, upper=1<<3, lower=1<<4,
alpha=1<<5, digit=1<<6, punct=1<<7, xdigit=1<<8,
alnum=alpha|digit, graph=alnum|punct
  };

The newlibc has a more compact character type mask definition; it uses
one byte only to represent the masks:

(newlib/libc/include/ctype.h)
#define _U 01
#define _L 02
#define _N 04
#define _S 010
#define _P 020
#define _C 040
#define _X 0100
#define _B 0200

(libstdc++-v3/config/os/newlib/ctype_base.h)
typedef char mask;
static const mask upper = _U;
static const mask lower = _L;
static const mask alpha = _U | _L;
static const mask digit = _N;
static const mask xdigit = _X | _N;
static const mask space = _S;
static const mask print = _P | _U | _L | _N | _B;
static const mask graph = _P | _U | _L | _N;
static const mask cntrl = _C;
static const mask punct = _P;
static const mask alnum = _U | _L | _N;

For _X and _B, the generic version of
ctype::_M_convert_to_wmask() fails to obtain their
corresponding wmasks, while other ctype_members.cc variants at
config/locale/{gnu,darwin}/ are not capable in handling this case either.

Therefore, in this patch, a newlib specific ctype_members.cc is added
at config/locale/newlib/, and acinclude.m4 is modified to use the new
ctype_members.cc when with_newlib is enabled. The main difference in this
ctype_members.cc from the generic version is the addition of the special
handling of xdigit and print at the end of
ctype::_M_convert_to_wmask().

With this patch the following test failure (when the C library is the
newlib C) will be fixed:
libstdc++-v3/testsuite/22_locale/ctype/scan/wchar_t/1.cc.

The patch has passed the regression test with armv7-a arm-eabi on qemu.

Is it OK for trunk?

Thanks,
Yufeng


libstdc++-v3/ChangeLog
2011-06-06  Yufeng Zhang  

* config/locale/newlib/ctype_members.cc: New file.
* acinclude.m4 (GLIBCXX_ENABLE_CLOCALE): Add a new C locale
kind: newlib.  Configure to use the newlib specific
ctype_members.cc when with_newlib is enabled.
* configure: Regenerate.

RE: [PATCH, libstdc++-v3] Add newlib specific ctype_members.cc

[Yufeng Zhang]

This time with the patch attached.

Yufeng

> -Original Message-
> From: Yufeng Zhang [mailto:yufeng.zh...@arm.com]
> Sent: 06 June 2011 18:31
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH, libstdc++-v3] Add newlib specific ctype_members.cc
> 
> Hi,
> 
> This patch fixes an issue in the ctype implementation when the
> newlib C library is used.
> 
> The generic version of ctype::_M_convert_to_wmask() in
> config/locale/generic/ctype_members.cc assumes that a character type
> mask is either a bitmask with only 1 bit set or a bitwise-OR result of
> other character type masks; for instance, as illustrated in the C++
> Standard 2003 TC1 [lib.category.ctype]:
> 
>   enum mask { // numeric values are for exposition only.
> space=1<<0, print=1<<1, cntrl=1<<2, upper=1<<3, lower=1<<4,
> alpha=1<<5, digit=1<<6, punct=1<<7, xdigit=1<<8,
> alnum=alpha|digit, graph=alnum|punct
>   };
> 
> The newlibc has a more compact character type mask definition; it uses
> one byte only to represent the masks:
> 
> (newlib/libc/include/ctype.h)
> #define _U 01
> #define _L 02
> #define _N 04
> #define _S 010
> #define _P 020
> #define _C 040
> #define _X 0100
> #define _B 0200
> 
> (libstdc++-v3/config/os/newlib/ctype_base.h)
> typedef char mask;
> static const mask upper = _U;
> static const mask lower = _L;
> static const mask alpha = _U | _L;
> static const mask digit = _N;
> static const mask xdigit = _X | _N;
> static const mask space = _S;
> static const mask print = _P | _U | _L | _N | _B;
> static const mask graph = _P | _U | _L | _N;
> static const mask cntrl = _C;
> static const mask punct = _P;
> static const mask alnum = _U | _L | _N;
> 
> For _X and _B, the generic version of
> ctype::_M_convert_to_wmask() fails to obtain their
> corresponding wmasks, while other ctype_members.cc variants at
> config/locale/{gnu,darwin}/ are not capable in handling this case
> either.
> 
> Therefore, in this patch, a newlib specific ctype_members.cc is added
> at config/locale/newlib/, and acinclude.m4 is modified to use the new
> ctype_members.cc when with_newlib is enabled. The main difference in
> this
> ctype_members.cc from the generic version is the addition of the
> special
> handling of xdigit and print at the end of
> ctype::_M_convert_to_wmask().
> 
> With this patch the following test failure (when the C library is the
> newlib C) will be fixed:
> libstdc++-v3/testsuite/22_locale/ctype/scan/wchar_t/1.cc.
> 
> The patch has passed the regression test with armv7-a arm-eabi on qemu.
> 
> Is it OK for trunk?
> 
> Thanks,
> Yufeng
> 
> 
> libstdc++-v3/ChangeLog
> 2011-06-06  Yufeng Zhang  
> 
> * config/locale/newlib/ctype_members.cc: New file.
> * acinclude.m4 (GLIBCXX_ENABLE_CLOCALE): Add a new C locale
> kind: newlib.  Configure to use the newlib specific
> ctype_members.cc when with_newlib is enabled.
> * configure: Regenerate.diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index ed8b129..7f9231c 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -1753,7 +1753,7 @@ dnl
 AC_DEFUN([GLIBCXX_ENABLE_CLOCALE], [
   GLIBCXX_ENABLE(clocale,auto,[[[=MODEL]]],
 [use MODEL for target locale package],
-[permit generic|gnu|ieee_1003.1-2001|yes|no|auto])
+[permit generic|gnu|ieee_1003.1-2001|newlib|yes|no|auto])
 
   # Deal with gettext issues.  Default to not using it (=no) until we detect
   # support for it later.  Let the user turn it off via --e/d, but let that
@@ -1764,7 +1764,7 @@ AC_DEFUN([GLIBCXX_ENABLE_CLOCALE], [
 [],
 [enable_nls=yes])
 
-  # Either a known packaage, or "auto"
+  # Either a known package, or "auto"
   if test $enable_clocale = no || test $enable_clocale = yes; then
  enable_clocale=auto
   fi
@@ -1781,7 +1781,11 @@ AC_DEFUN([GLIBCXX_ENABLE_CLOCALE], [
enable_clocale_flag=darwin
;;
   *)
-   enable_clocale_flag=generic
+   if test x"$with_newlib" = x"yes"; then
+ enable_clocale_flag=newlib
+   else
+ enable_clocale_flag=generic
+   fi
;;
 esac
   fi
@@ -1915,6 +1919,22 @@ AC_DEFUN([GLIBCXX_ENABLE_CLOCALE], [
   CTIME_CC=config/locale/generic/time_members.cc
   CLOCALE_INTERNAL_H=config/locale/generic/c++locale_internal.h
   ;;
+newlib)
+  AC_MSG_RESULT(newlib)
+
+  CLOCALE_H=config/locale/generic/c_locale.h
+  CLOCALE_CC=config/locale/generic/c_locale.cc
+  CCODECVT_CC=config/locale/generic/codecvt_members.cc
+  CCOLLATE_CC=config/locale/generic/collate_members.cc
+  CCTYPE_CC=config/locale/newlib/ctype_members.cc
+  CMESSAGES_H=config/locale/generic/messages_members.h
+  CMESSAGES_CC=config/locale/generic/messages_members.cc
+  CMONEY_CC=config/locale/generic/monetary_members.cc
+  CNUMERIC_CC=config/locale/generic/numeric_members.cc
+  CTIME_H=config/locale/generic/time_members.h
+

Re: objc/objc++: switch all testcases to Modern Objective-C runtime API

[IainS]

On 6 Jun 2011, at 18:21, Nicola Pero wrote:

This patch switches all the testcases in the ObjC/ObjC++ testsuite  
to use the
Modern Objective-C runtime API when executing with the GNU runtime.   
This
will allow me to complete removing the Traditional Objective-C  
runtime API

from libobjc. :-)


...

I tested this on GNU/Linux i686, and on Apple 10.6.7 64-bit.  That  
tests both the GNU
runtime and a recent NeXT runtime.  I'd like to test with an older  
NeXT runtime, but I

don't have any access to an Apple machine with Mac OS X < 10.5.


testing at m32 should exercise all the post 10.4 stuff - and would be  
a good indicator of any major hassles.


I'll try and do a 10.4 test during the week ... (assuming trunk still  
bootstrap on it).


Iain

Re: [PATCH] Fix fold_stmt ICE (PR c++/49264)

[Jakub Jelinek]

On Mon, Jun 06, 2011 at 01:41:14PM +0200, Richard Guenther wrote:
> > I think NULL new_stmt would have the advantage that we wouldn't duplicate
> > the complex code looping through all kinds of clones.
> 
> Yeah, I'd prefer that variant.  Honza?

Ok, after further discussions with Honza on IRC here is what I've committed
to trunk and 4.6, after bootstrapping/regtesting it on x86_64-linux and
i686-linux again.

2011-06-06  Jakub Jelinek  

PR c++/49264
* gimple-fold.c (fold_stmt_1): Don't try to fold *& on the lhs
if stmt folded into nothing.
* tree-inline.c (fold_marked_statements): If a builtin at the
end of a bb folded into nothing, just update cgraph edges
and move to next bb.
* cgraph.c (cgraph_update_edges_for_call_stmt_node): Allow new_stmt
to be NULL.  Don't compute count and frequency if new_call is NULL.

* g++.dg/opt/pr49264.C: New test.

--- gcc/gimple-fold.c.jj2011-06-03 10:31:32.0 +0200
+++ gcc/gimple-fold.c   2011-06-06 16:27:41.0 +0200
@@ -1577,6 +1577,11 @@ fold_stmt_1 (gimple_stmt_iterator *gsi, 
   bool changed = false;
   gimple stmt = gsi_stmt (*gsi);
   unsigned i;
+  gimple_stmt_iterator gsinext = *gsi;
+  gimple next_stmt;
+
+  gsi_next (&gsinext);
+  next_stmt = gsi_end_p (gsinext) ? NULL : gsi_stmt (gsinext);
 
   /* Fold the main computation performed by the statement.  */
   switch (gimple_code (stmt))
@@ -1665,10 +1670,19 @@ fold_stmt_1 (gimple_stmt_iterator *gsi, 
 default:;
 }
 
+  /* If stmt folds into nothing and it was the last stmt in a bb,
+ don't call gsi_stmt.  */
+  if (gsi_end_p (*gsi))
+{
+  gcc_assert (next_stmt == NULL);
+  return changed;
+}
+
   stmt = gsi_stmt (*gsi);
 
-  /* Fold *& on the lhs.  */
-  if (gimple_has_lhs (stmt))
+  /* Fold *& on the lhs.  Don't do this if stmt folded into nothing,
+ as we'd changing the next stmt.  */
+  if (gimple_has_lhs (stmt) && stmt != next_stmt)
 {
   tree lhs = gimple_get_lhs (stmt);
   if (lhs && REFERENCE_CLASS_P (lhs))
--- gcc/tree-inline.c.jj2011-06-06 10:24:12.0 +0200
+++ gcc/tree-inline.c   2011-06-06 16:28:51.0 +0200
@@ -4055,6 +4055,14 @@ fold_marked_statements (int first, struc
  if (fold_stmt (&gsi))
{
  gimple new_stmt;
+ /* If a builtin at the end of a bb folded into nothing,
+the following loop won't work.  */
+ if (gsi_end_p (gsi))
+   {
+ cgraph_update_edges_for_call_stmt (old_stmt,
+old_decl, NULL);
+ break;
+   }
  if (gsi_end_p (i2))
i2 = gsi_start_bb (BASIC_BLOCK (first));
  else
--- gcc/cgraph.c.jj 2011-06-03 10:31:32.0 +0200
+++ gcc/cgraph.c2011-06-06 16:30:06.0 +0200
@@ -1233,13 +1233,17 @@ cgraph_make_edge_direct (struct cgraph_e
 
 /* Update or remove the corresponding cgraph edge if a GIMPLE_CALL
OLD_STMT changed into NEW_STMT.  OLD_CALL is gimple_call_fndecl
-   of OLD_STMT if it was previously call statement.  */
+   of OLD_STMT if it was previously call statement.
+   If NEW_STMT is NULL, the call has been dropped without any
+   replacement.  */
 
 static void
 cgraph_update_edges_for_call_stmt_node (struct cgraph_node *node,
-   gimple old_stmt, tree old_call, gimple 
new_stmt)
+   gimple old_stmt, tree old_call,
+   gimple new_stmt)
 {
-  tree new_call = (is_gimple_call (new_stmt)) ? gimple_call_fndecl (new_stmt) 
: 0;
+  tree new_call = (new_stmt && is_gimple_call (new_stmt))
+ ? gimple_call_fndecl (new_stmt) : 0;
 
   /* We are seeing indirect calls, then there is nothing to update.  */
   if (!new_call && !old_call)
@@ -1277,7 +1281,7 @@ cgraph_update_edges_for_call_stmt_node (
  frequency = e->frequency;
  cgraph_remove_edge (e);
}
-  else
+  else if (new_call)
{
  /* We are seeing new direct call; compute profile info based on BB.  
*/
  basic_block bb = gimple_bb (new_stmt);
--- gcc/testsuite/g++.dg/opt/pr49264.C.jj   2011-06-06 16:27:41.0 
+0200
+++ gcc/testsuite/g++.dg/opt/pr49264.C  2011-06-06 16:27:41.0 +0200
@@ -0,0 +1,19 @@
+// PR c++/49264
+// { dg-do compile }
+// { dg-options "-O2" }
+
+struct B { };
+struct A { char a[sizeof (B) + 1]; } a;
+
+static inline void
+foo (const B &b)
+{
+  __builtin_memcpy (&a, &b, sizeof (b));
+}
+
+void
+bar ()
+{
+  B c;
+  foo (c);
+}


Jakub

[committed] Fix ICE on vector shift in dwarf2out (PR debug/49294)

[Jakub Jelinek]

Hi!

Trying to create vector zero_extend is wrong, while mem_loc_descriptor
will for now fail for vector modes, the code attempted to expand zero_extend
anyway.

Fixed thusly, committed to trunk as obvious after bootstrapping/regtesting
on x86_64-linux and i686-linux.

2011-06-06  Jakub Jelinek  

PR debug/49294
* dwarf2out.c (mem_loc_descriptor) : Give up for
non-MODE_INT modes.

* gcc.dg/debug/pr49294.c: New test.

--- gcc/dwarf2out.c.jj  2011-06-06 10:24:41.0 +0200
+++ gcc/dwarf2out.c 2011-06-06 10:30:05.0 +0200
@@ -14904,6 +14904,8 @@ mem_loc_descriptor (rtx rtl, enum machin
   goto do_shift;
 
 do_shift:
+  if (GET_MODE_CLASS (mode) != MODE_INT)
+   break;
   op0 = mem_loc_descriptor (XEXP (rtl, 0), mode, mem_mode,
VAR_INIT_STATUS_INITIALIZED);
   {
--- gcc/testsuite/gcc.dg/debug/pr49294.c.jj 2011-06-06 10:39:41.0 
+0200
+++ gcc/testsuite/gcc.dg/debug/pr49294.c2011-06-06 10:39:21.0 
+0200
@@ -0,0 +1,14 @@
+/* PR debug/49294 */
+/* { dg-do compile } */
+
+typedef __attribute__ ((vector_size ((8) * sizeof (short short V;
+
+int k;
+V v;
+
+void
+foo (void)
+{
+  V w = { k, k, k, k, k, k, k, k };
+  V x = v >> w;
+}

Jakub

Re: [PATCH] PR fortran/49268

[Steve Kargl]

On Mon, Jun 06, 2011 at 10:14:39AM -0700, Langton, Asher wrote:
> On 6/2/11 2:42 PM, "Langton, Asher"  wrote:
> >On 6/2/11 2:11 PM, "Steve Kargl"  wrote:
> >>On Thu, Jun 02, 2011 at 01:59:03PM -0700, Langton, Asher wrote:
> >>> This patch fixes a bug where the wrong code was generated for
> >>>assumed-size
> >>> Cray pointees. The fix is simple, but a bit ugly. Bootstrapped and
> >>> regression-tested on x86_64-unknown-linux-gnu. Okay for trunk?
> >>> 
> >>> Thanks,
> >>> Asher
> >>> 
> >>> 2011-06-02  Asher Langton  
> >>> 
> >>> PR fortran/49268
> >>> * trans-decl.c (gfc_trans_deferred_vars): Treat assumed-size
> >>>Cray
> >>> pointees as AS_EXPLICIT.
> >>> 
> >>> 2011-06-02  Asher Langton  
> >>> 
> >>> PR fortran/49268
> >>> * gfortran.dg/PR49268.f90: New test.
> >>
> >>OK.
> >
> >Committed at revision 174584.
> 
> A gfortran user here at LLNL asked if this could be backported to the 4.6
> branch. I bootstrapped and regression-tested on x86_64-unknown-linux-gnu.
> Okay for 4.6?

OK.

-- 
Steve

[testsuite] Fix cdtor-1.C testcase (PR testsuite/49288)

[Jakub Jelinek]

Hi!

As usually, -g -dA output differs between targets that can't merge
debug strings and those that do.  Instead of writing regexps to match both,
this patch does what most other testcases do.  Additionally, it fixes the
testcase also for -gdwarf-4 defaulting compilers.

Regtested on x86_64-linux and i686-linux, committed as obvious.

2011-06-06  Jakub Jelinek  

PR testsuite/49288
* g++.dg/debug/dwarf2/cdtor-1.C: Add -fno-merge-debug-strings
to dg-options, match also DW_AT_linkage_name.

--- gcc/testsuite/g++.dg/debug/dwarf2/cdtor-1.C.jj  2011-06-01 
10:19:57.0 +0200
+++ gcc/testsuite/g++.dg/debug/dwarf2/cdtor-1.C 2011-06-06 14:51:26.0 
+0200
@@ -1,5 +1,5 @@
 // origin PR debug/49047
-// { dg-options "-g -dA" }
+// { dg-options "-g -dA -fno-merge-debug-strings" }
 // { dg-do compile }
 
 struct K
@@ -11,7 +11,7 @@ struct K
 int
 main()
 {
-K k;
+  K k;
 }
 
-// { dg-final {scan-assembler-times "\[^\n\r\]*DW_AT_MIPS_linkage_name:" 2 } }
+// { dg-final {scan-assembler-times " DW_AT_\[MIPS_\]*linkage_name" 2 } }

Jakub

[committed] Fix endless loop in dwarf2out.c (PR debug/49262)

[Jakub Jelinek]

Hi!

I forgot to decrement the counter, but given that nobody has hit it
until now it is possible that no frontend leaves RANGE_EXPR indexes in
CONSTRUCTORs around till late.  varasm.c seems to handle them though,
so fixed thusly, committed to trunk as obvious.

2011-06-06  Jakub Jelinek  

PR debug/49262
* dwarf2out.c (native_encode_initializer): Decrement count in each
iteration.

--- gcc/dwarf2out.c.jj  2011-06-06 10:30:05.0 +0200
+++ gcc/dwarf2out.c 2011-06-06 18:02:28.0 +0200
@@ -18065,7 +18065,7 @@ native_encode_initializer (tree init, un
{
  int count = tree_low_cst (TREE_OPERAND (index, 1), 0)
  - tree_low_cst (TREE_OPERAND (index, 0), 0);
- while (count > 0)
+ while (count-- > 0)
{
  if (val)
memcpy (array + curpos, array + pos, fieldsize);

Jakub

[PATCH] Fix -fprofile-use optimization of a noreturn indirect call (PR gcov-profile/49299)

[Jakub Jelinek]

Hi!

When an indirect noreturn call has a likely call target, value-prof.c
ICEs on it, as there is no fallthru edge after the call (nor a join bb).
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk/4.6?

2011-06-06  Jakub Jelinek  

PR gcov-profile/49299
* value-prof.c (gimple_ic): Don't assume icall has
a fallthru edge.

* gcc.dg/tree-prof/pr49299-1.c: New test.
* gcc.dg/tree-prof/pr49299-2.c: New test.

--- gcc/value-prof.c.jj 2011-05-02 18:39:28.0 +0200
+++ gcc/value-prof.c2011-06-06 12:37:30.0 +0200
@@ -1145,9 +1145,9 @@ gimple_ic (gimple icall_stmt, struct cgr
 {
   gimple dcall_stmt, load_stmt, cond_stmt;
   tree tmp0, tmp1, tmpv, tmp;
-  basic_block cond_bb, dcall_bb, icall_bb, join_bb;
+  basic_block cond_bb, dcall_bb, icall_bb, join_bb = NULL;
   tree optype = build_pointer_type (void_type_node);
-  edge e_cd, e_ci, e_di, e_dj, e_ij;
+  edge e_cd, e_ci, e_di, e_dj = NULL, e_ij;
   gimple_stmt_iterator gsi;
   int lp_nr;
 
@@ -1194,12 +1194,19 @@ gimple_ic (gimple icall_stmt, struct cgr
   else
 {
   e_ij = find_fallthru_edge (icall_bb->succs);
-  e_ij->probability = REG_BR_PROB_BASE;
-  e_ij->count = all - count;
-  e_ij = single_pred_edge (split_edge (e_ij));
+  /* The indirect call might be noreturn.  */
+  if (e_ij != NULL)
+   {
+ e_ij->probability = REG_BR_PROB_BASE;
+ e_ij->count = all - count;
+ e_ij = single_pred_edge (split_edge (e_ij));
+   }
+}
+  if (e_ij != NULL)
+{
+  join_bb = e_ij->dest;
+  join_bb->count = all;
 }
-  join_bb = e_ij->dest;
-  join_bb->count = all;
 
   e_cd->flags = (e_cd->flags & ~EDGE_FALLTHRU) | EDGE_TRUE_VALUE;
   e_cd->probability = prob;
@@ -1211,12 +1218,15 @@ gimple_ic (gimple icall_stmt, struct cgr
 
   remove_edge (e_di);
 
-  e_dj = make_edge (dcall_bb, join_bb, EDGE_FALLTHRU);
-  e_dj->probability = REG_BR_PROB_BASE;
-  e_dj->count = count;
+  if (e_ij != NULL)
+{
+  e_dj = make_edge (dcall_bb, join_bb, EDGE_FALLTHRU);
+  e_dj->probability = REG_BR_PROB_BASE;
+  e_dj->count = count;
 
-  e_ij->probability = REG_BR_PROB_BASE;
-  e_ij->count = all - count;
+  e_ij->probability = REG_BR_PROB_BASE;
+  e_ij->count = all - count;
+}
 
   /* Insert PHI node for the call result if necessary.  */
   if (gimple_call_lhs (icall_stmt)
--- gcc/testsuite/gcc.dg/tree-prof/pr49299-1.c.jj   2011-06-06 
11:34:58.0 +0200
+++ gcc/testsuite/gcc.dg/tree-prof/pr49299-1.c  2011-06-06 11:34:51.0 
+0200
@@ -0,0 +1,34 @@
+/* { dg-options "-O2" } */
+
+__attribute__((noreturn)) void (*fn) (void);
+
+volatile int v;
+
+__attribute__((noreturn)) void
+fn0 (void)
+{
+  __builtin_exit (0);
+}
+
+__attribute__((noreturn)) void
+fn1 (void)
+{
+  __builtin_exit (1);
+}
+
+__attribute__((noinline, noclone)) void
+setfn (__attribute__((noreturn)) void (*x) (void))
+{
+  fn = x;
+}
+
+int
+main ()
+{
+  int i;
+  if (v < 1)
+setfn (fn0);
+  else
+setfn (fn1);
+  fn ();
+}
--- gcc/testsuite/gcc.dg/tree-prof/pr49299-2.c.jj   2011-06-06 
12:46:25.0 +0200
+++ gcc/testsuite/gcc.dg/tree-prof/pr49299-2.c  2011-06-06 12:39:15.0 
+0200
@@ -0,0 +1,34 @@
+/* { dg-options "-O2" } */
+
+void (*fn) (void);
+
+volatile int v;
+
+__attribute__((noreturn)) void
+fn0 (void)
+{
+  __builtin_exit (0);
+}
+
+void
+fn1 (void)
+{
+}
+
+__attribute__((noinline, noclone)) void
+setfn (void (*x) (void))
+{
+  fn = x;
+}
+
+int
+main ()
+{
+  int i;
+  if (v < 1)
+setfn (fn0);
+  else
+setfn (fn1);
+  fn ();
+  return 0;
+}

Jakub

[Design notes, RFC] Address-lowering prototype design (PR46556)

[William J. Schmidt]

It's been some time since I last posted about the address lowering issue from
PR46556 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46556).  I've had a basic
prototype in place for some time, but I ran into some issues that initially
caused performance regressions; I've had to jump through several hoops to
resolve these.  At this time, I'm now seeing decent performance improvements
from address lowering for PowerPC (about 2% overall on SPEC cpu2000).  A
couple of minor degradations still occur that I am looking into.

I thought this would be a good time to put out another RFC.  However, the code
has grown over time, and I doubt whether all you busy people are particularly
interested in reviewing a 2700-line prototype patch in detail.  Instead, I've
written up some notes on the design, some of the challenges I ran into, and my
current approach to handling those.

I'd like to first get comments from interested parties on the prototype
design, and get consensus on whether this is the appropriate overall
approach.  If so, the next step would be to decide how to go about reviewing
the code.  Since smaller patches are much easier to review, one possibility
would be for me to gate the new pass on a flag that's off by default, and
submit patches incrementally for review.  I.e., start with the bare-bones
algorithm, and gradually add in the complexities as folks have time to review
the code.  I'm quite new to the community, so any advice on how to handle
this would be very welcome.

In any case, here are my notes.  Thanks in advance for your views!

Bill


Basic algorithm
===
A new pass is added late in the gimple phases, currently between
pass_phi_only_cprop and pass_cd_dce.  I chose this placement because the new
pass can generate a fair amount of dead code.

Address lowering walks the CFG in predominator order.  Common subexpression
elimination is performed on operations that could participate in addressing
expressions.  These operations may have been made available in the current
block, or in any dominating block.

Any statement that may contain a memory access (excluding calls) is considered
for address lowering.  The memory access is expanded into an affine
combination of trees by looking back at feeding statements, using logic
originally developed for IVopts.  The affine combination is subjected to a
number of tests to determine whether it's legal and profitable to lower the
addressing expression into a TARGET_MEM_REF (or MEM_REF, when addressing is
sufficiently simple).  If so, the conversion to a TMR is performed, again
using logic originally developed for IVopts.

The resulting memory reference is again subjected to a number of conditions
testing for legality and profitability.  If these conditions are all met, the
reference data is copied from the original expression to the TMR, and the TMR
replaces the original expression in the gimple statement.

The conversion of a memory access into a TMR generally creates a number of new
gimple statements preceding the statement under analysis.  CSE is performed on
the fly for these new statements as well, using the available expressions data
discussed earlier.  This produces naturally shared addressability for members
of the same structure, for example.

Inhibitors
==
As mentioned, a number of conditions are checked before replacing a memory
access with a TMR.  Conditions that inhibit replacement include the following.

 * There is not yet any handling for bitfields.

 * An expression containing a direct field reference from a small nonvolatile
   structure is left alone.  It is assumed that these values will be
   register-assigned, so exposing their addresses is counterproductive.

 * I have seen odd cases in C++ code such as 

 lhs = MEM[(struct foo *) 0B].bar;

   This results in an affine combination of trees with no elements, so an
   explicit check for such empty combinations is required.

 * If the affine combination of trees introduces an ADDR_EXPR for any decl
   that is not already marked as addressable, we refuse to make the
   replacement.  Taking the address of something for the first time defeats
   downstream optimizations that would otherwise be possible.

 * create_mem_ref can occasionally produce a TMR or MEM_REF with a base
   expression of constant zero.  One way this can happen is with questionable
   coding practices, such as treating an integer paramter as a pointer.  It's
   an open question whether create_mem_ref should ever produce such a tree.
   In any case, the base expression of zero again confuses the may-aliasing
   machinery, so I refuse the replacement in this case.

 * If the original expression will be recognized as a "hidden global store" in
   tree-ssa-sink.c:is_hidden_global_store, but the replacement expression will
   not, it is possible for the dead code eliminator to remove the modified
   statement.  It seems to me this shouldn't normally happen in practice.  For
   now I detect this case and refuse

Re: objc/objc++: switch all testcases to Modern Objective-C runtime API

[Mike Stump]

On Jun 6, 2011, at 10:21 AM, Nicola Pero wrote:
> This patch switches all the testcases in the ObjC/ObjC++ testsuite to use the
> Modern Objective-C runtime API when executing with the GNU runtime.
> OK to commit ?

Ok, from me with one possible exception, I'd like Iain or Jack to weigh in on 
wether it should go in before they have a chance to test it on pre 10.6 
systems.  I'm fine with it going in before or after, as we're in stage 1 and I 
think there is plenty of time to address any pre 10.6 fallout.  If it goes in 
sooner, we'll get 10.5 coverage with Geoff's tester.

Re: [pph] Clean up PPH tests (issue4572042)

[Lawrence Crowl]

On 6/6/11, Diego Novillo  wrote:
> So, I'm getting this:
>
> Running /home/dnovillo/pph/svn/src/gcc/testsuite/g++.dg/pph/pph.exp ...
> XPASS: g++.dg/pph/c120060625-1.cc  -I.  (test for bogus messages, line )
> XPASS: g++.dg/pph/c1eabi1.cc  -I.  (test for bogus messages, line )
> XPASS: g++.dg/pph/x1autometh.cc  -I.  (test for bogus messages, line )
> XPASS: g++.dg/pph/x1functions.cc  -I.  (test for bogus messages, line )
> XPASS: g++.dg/pph/x1functions.cc  -I.  (test for bogus messages, line )
> XPASS: g++.dg/pph/x1special.cc  -I.  (test for bogus messages, line )
> XPASS: g++.dg/pph/x1special.cc  -fpph-map=pph.map -I.  (test for bogus
> messages, line )
> FAIL: g++.dg/pph/x1special.cc  -fpph-map=pph.map -I. (test for excess
> errors)
> XPASS: g++.dg/pph/x1template.cc  -I.  (test for bogus messages, line )
> XPASS: g++.dg/pph/x1template.cc  -fpph-map=pph.map -I.  (test for
> bogus messages, line )
> FAIL: g++.dg/pph/x1template.cc  -fpph-map=pph.map -I. (test for excess
> errors)
> XPASS: g++.dg/pph/x1tmplclass.cc  -I.  (test for bogus messages, line )
> XPASS: g++.dg/pph/x1tmplfunc.cc  -I.  (test for bogus messages, line )
> XPASS: g++.dg/pph/x1tmplfunc.cc  -fpph-map=pph.map -I.  (test for
> bogus messages, line )
> FAIL: g++.dg/pph/x1tmplfunc.cc  -fpph-map=pph.map -I. (test for excess
> errors)
> XPASS: g++.dg/pph/x1typerefs.cc  -I.  (test for bogus messages, line )
> XPASS: g++.dg/pph/x1variables.cc  -I.  (test for bogus messages, line )
> XPASS: g++.dg/pph/x1variables.cc  -I.  (test for bogus messages, line )
> XPASS: g++.dg/pph/x1variables.cc  -fpph-map=pph.map -I.  (test for
> bogus messages, line )
> XPASS: g++.dg/pph/x1variables.cc  -fpph-map=pph.map -I.  (test for
> bogus messages, line )
>
> === g++ Summary ===
>
> # of expected passes176
> # of unexpected failures3
> # of unexpected successes   17
> # of expected failures  45
>
> The three FAILs are expected then?  Those are the ones you mentioned
> can't be easily XFAIL'd?

These are probably changes in the line number of the ICE,
and so the dg-bogus needs updating.

-- 
Lawrence Crowl

Re: [lto] Unify decl and type registration (issue4515186)

[Diego Novillo]

On Mon, Jun 6, 2011 at 13:02, Diego Novillo  wrote:
> On Mon, Jun 6, 2011 at 10:27, Diego Novillo  wrote:
>> On Mon, Jun 6, 2011 at 04:50, Richard Guenther  wrote:
>>
>>> I'd have it done in the loop that computes canonical types, at this
>>> place we do not gain the advantage that the decl register functions
>>> get completely fixed up trees.
>>
>> Hm, yes, I had forgotten about the call to rest_of_decl_compilation.
>> Patch coming up.
>
> You mean this?  Currently under testing.

>
>
>        * lto.c (uniquify_nodes): Move code to register decls to
>        the loop that computes canonical types.


LTO profiledbootstrap and regression tested on x86_64.

OK for trunk?


Diego.

Re: [PATCH] gimple_val_nonnegative_real_p (PR46728 patch 7 of 7)

[William J. Schmidt]

Hi Richard,

Here's the reworked patch addressing the noted concerns.  Regtested for
powerpc-linux.  OK for trunk?

Thanks,
Bill


2011-06-06  Bill Schmidt  

PR tree-optimization/46728
* tree-ssa-math-opts.c (gimple_expand_builtin_pow): Change FIXME
to use gimple_val_nonnegative_real_p.
* gimple-fold.c (gimple_val_nonnegative_real_p): New function.
* gimple.h (gimple_val_nonnegative_real_p): New declaration.


Index: gcc/tree-ssa-math-opts.c
===
--- gcc/tree-ssa-math-opts.c(revision 174708)
+++ gcc/tree-ssa-math-opts.c(working copy)
@@ -1172,13 +1172,7 @@ gimple_expand_builtin_pow (gimple_stmt_iterator *g
 
   if (flag_unsafe_math_optimizations
   && cbrtfn
-  /* FIXME: The following line was originally
-&& (tree_expr_nonnegative_p (arg0) || !HONOR_NANS (mode)),
-but since arg0 is a gimple value, the first predicate
-will always return false.  It needs to be replaced with a
-call to a similar gimple_val_nonnegative_p function to be
- added in gimple-fold.c.  */
-  && !HONOR_NANS (mode)
+  && (gimple_val_nonnegative_real_p (arg0) || !HONOR_NANS (mode))
   && REAL_VALUES_EQUAL (c, dconst1_3))
 return build_and_insert_call (gsi, loc, &target, cbrtfn, arg0);
   
@@ -1190,13 +1184,7 @@ gimple_expand_builtin_pow (gimple_stmt_iterator *g
   if (flag_unsafe_math_optimizations
   && sqrtfn
   && cbrtfn
-  /* FIXME: The following line was originally
-&& (tree_expr_nonnegative_p (arg0) || !HONOR_NANS (mode)),
-but since arg0 is a gimple value, the first predicate
-will always return false.  It needs to be replaced with a
-call to a similar gimple_val_nonnegative_p function to be
- added in gimple-fold.c.  */
-  && !HONOR_NANS (mode)
+  && (gimple_val_nonnegative_real_p (arg0) || !HONOR_NANS (mode))
   && optimize_function_for_speed_p (cfun)
   && hw_sqrt_exists
   && REAL_VALUES_EQUAL (c, dconst1_6))
@@ -1270,13 +1258,7 @@ gimple_expand_builtin_pow (gimple_stmt_iterator *g
 
   if (flag_unsafe_math_optimizations
   && cbrtfn
-  /* FIXME: The following line was originally
-&& (tree_expr_nonnegative_p (arg0) || !HONOR_NANS (mode)),
-but since arg0 is a gimple value, the first predicate
-will always return false.  It needs to be replaced with a
-call to a similar gimple_val_nonnegative_p function to be
- added in gimple-fold.c.  */
-  && !HONOR_NANS (mode)
+  && (gimple_val_nonnegative_real_p (arg0) || !HONOR_NANS (mode))
   && real_identical (&c2, &c)
   && optimize_function_for_speed_p (cfun)
   && powi_cost (n / 3) <= POWI_MAX_MULTS)
Index: gcc/gimple-fold.c
===
--- gcc/gimple-fold.c   (revision 174708)
+++ gcc/gimple-fold.c   (working copy)
@@ -3433,3 +3433,134 @@ fold_const_aggregate_ref (tree t)
 {
   return fold_const_aggregate_ref_1 (t, NULL);
 }
+
+/* Return true iff VAL is a gimple expression that is known to be
+   non-negative.  Restricted to floating-point inputs.  */
+
+bool
+gimple_val_nonnegative_real_p (tree val)
+{
+  gimple def_stmt;
+
+  gcc_assert (val && (TREE_CODE (TREE_TYPE (val)) == REAL_TYPE));
+
+  /* Use existing logic for non-gimple trees.  */
+  if (tree_expr_nonnegative_p (val))
+return true;
+
+  if (TREE_CODE (val) != SSA_NAME)
+return false;
+
+  /* Currently we look only at the immediately defining statement
+ to make this determination, since recursion on defining 
+ statements of operands can lead to quadratic behavior in the
+ worst case.  This is expected to catch almost all occurrences
+ in practice.  It would be possible to implement limited-depth
+ recursion if important cases are lost.  Alternatively, passes
+ that need this information (such as the pow/powi lowering code
+ in the cse_sincos pass) could be revised to provide it through
+ dataflow propagation.  */
+
+  def_stmt = SSA_NAME_DEF_STMT (val);
+
+  if (is_gimple_assign (def_stmt))
+{
+  tree op0, op1;
+
+  /* See fold-const.c:tree_expr_nonnegative_p for additional
+cases that could be handled with recursion.  */
+
+  switch (gimple_assign_rhs_code (def_stmt))
+   {
+   case ABS_EXPR:
+ /* Always true for floating-point operands.  */
+ return true;
+
+   case MULT_EXPR:
+ /* True if the two operands are identical (since we are
+restricted to floating-point inputs).  */
+ op0 = gimple_assign_rhs1 (def_stmt);
+ op1 = gimple_assign_rhs2 (def_stmt);
+
+ if (op0 == op1
+ || operand_equal_p (op0, op1, 0))
+   return true;
+
+   default:
+ return false;
+   }
+}
+  else if (is_gimple_call (def_stmt))
+{
+  tree fndecl = gimple_call_fndecl (def_stmt);
+  if (fn

Re: -fdump-passes -fenable-xxx=func_name_list

[Xinliang David Li]

Please take a look at the revised one.

Thanks,

David

On Mon, Jun 6, 2011 at 4:22 AM, Richard Guenther
 wrote:
> On Wed, Jun 1, 2011 at 7:24 PM, Xinliang David Li  wrote:
>> The attached is the split #1 patch that enhances -fenable/disable.
>>
>> Ok after testing?
>
> I expect the testcases will be quite fragile, so while I appreciate
> test coverage for new options I think we should go without those
> that involve any kind of UID.  Those which use assembler names
> also will fail randomly dependent on how targets mangle their
> functions - so I think we have to drop all testcases.
>
> Also
>
> +/* A helper function to determine if an identifier is valid to
> +   be an assembler name (better to use target specific hook).  */
> +
> +static bool
> +is_valid_assembler_name (const char *str)
> +{
> +  const char *p = str;
> +  char c;
> +
> +  c = *p;
> +  if (!((c >= 'a' && c <= 'z')
> +        || (c >= 'A' && c <= 'Z')
> +        || *p == '_'))
> +    return false;
> +
> +  p++;
> +  while ((c = *p))
> +   {
> +     if (!((c >= 'a' && c <= 'z')
> +           || (c >= 'A' && c <= 'Z')
> +           || (c >= '0' && c <= '9')
> +           || *p == '_'))
> +       return false;
> +     p++;
> +   }
> +
> +  return true;
> +}
>
> why all that complicated checks?  Why not just check for p[0]
> in [^0-9] and re-structure the range parsing to switch between
> UIDs and assembler-names that way?
>
> Thanks,
> Richard.
>
>> Thanks,
>> David
>>
>> On Wed, Jun 1, 2011 at 9:16 AM, Xinliang David Li  wrote:
>>> On Wed, Jun 1, 2011 at 1:51 AM, Richard Guenther
>>>  wrote:
 On Wed, Jun 1, 2011 at 1:34 AM, Xinliang David Li  
 wrote:
> The following patch implements the a new option that dumps gcc PASS
> configuration. The sample output is attached.  There is one
> limitation: some placeholder passes that are named with '*xxx' are
> note registered thus they are not listed. They are not important as
> they can not be turned on/off anyway.
>
> The patch also enhanced -fenable-xxx and -fdisable-xx to allow a list
> of function assembler names to be specified.
>
> Ok for trunk?

 Please split the patch.

 I'm not too happy how you dump the pass configuration.  Why not simply,
 at a _single_ place, walk the pass tree?  Instead of doing pieces of it
 at pass execution time when it's not already dumped - that really looks
 gross.
>>>
>>> Yes, that was the original plan -- but it has problems
>>> 1) the dumper needs to know the root pass lists -- which can change
>>> frequently -- it can be a long term maintanance burden;
>>> 2) the centralized dumper needs to be done after option processing
>>> 3) not sure if gate functions have any side effects or have dependencies on 
>>> cfun
>>>
>>> The proposed solutions IMHO is not that intrusive -- just three hooks
>>> to do the dumping and tracking indentation.
>>>

 The documentation should also link this option to the -fenable/disable
 options as obviously the pass names in that dump are those to be
 used for those flags (and not readily available anywhere else).
>>>
>>> Ok.
>>>

 I also think that it would be way more useful to note in the individual
 dump files the functions (at the place they would usually appear) that
 have the pass explicitly enabled/disabled.
>>>
>>> Ok -- for ipa passes or tree/rtl passes where all functions are
>>> explicitly disabled.
>>>
>>> Thanks,
>>>
>>> David
>>>

 Richard.

> Thanks,
>
> David
>

>>>
>>
>
Index: doc/invoke.texi
===
--- doc/invoke.texi	(revision 174549)
+++ doc/invoke.texi	(working copy)
@@ -5056,11 +5056,12 @@ appended with a sequential number starti
 Disable rtl pass @var{pass}.  @var{pass} is the pass name.  If the same pass is
 statically invoked in the compiler multiple times, the pass name should be
 appended with a sequential number starting from 1.  @var{range-list} is a comma
-seperated list of function ranges.  Each range is a number pair seperated by a colon.
-The range is inclusive in both ends.  If the range is trivial, the number pair can be
-simplified a a single number.  If the function's cgraph node's @var{uid} is falling
-within one of the specified ranges, the @var{pass} is disabled for that function.
-The @var{uid} is shown in the function header of a dump file.
+seperated list of function ranges or assembler names.  Each range is a number
+pair seperated by a colon.  The range is inclusive in both ends.  If the range
+is trivial, the number pair can be simplified as a single number.  If the
+function's cgraph node's @var{uid} is falling within one of the specified ranges,
+the @var{pass} is disabled for that function.  The @var{uid} is shown in the
+function header of a dump file.
 
 @item -fdisable-tree-@var{pass}
 @item -fdisable-tree-@var{pass}=@var{range-list}
@@ -5090,7 +5091,8 @@ of option arguments.
-fenabl

Fix for PR obj-c++/48275 ("getter=namespace failing with .mm")

[Nicola Pero]

This patch fixes PR obj-c++/48275.  It's a routine parser ingenuity.

OK to commit ?

Thanks

Index: testsuite/ChangeLog
===
--- testsuite/ChangeLog (revision 174657)
+++ testsuite/ChangeLog (working copy)
@@ -1,3 +1,9 @@
+2011-06-06  Nicola Pero  
+
+   PR objc-++/48275
+   * obj-c++.dg/property/cxx-property-1.mm: New.   
+   * obj-c++.dg/property/cxx-property-2.mm: New.
+
 2011-06-05  Nicola Pero  
 
PR testsuite/49287
Index: testsuite/obj-c++.dg/property/cxx-property-2.mm
===
--- testsuite/obj-c++.dg/property/cxx-property-2.mm (revision 0)
+++ testsuite/obj-c++.dg/property/cxx-property-2.mm (revision 0)
@@ -0,0 +1,22 @@
+/* { dg-do compile } */
+
+/* All these C++ keywords are acceptable in ObjC method names, hence
+   should be accepted for property getters and setters.  */
+
+@interface Test
+{
+  Class isa;
+}
+@property (getter=namespace) int p0;
+@property (setter=namespace:) int p1;
+@property (getter=and) int p2;
+@property (setter=and:) int p3;
+@property (getter=class) int p4;
+@property (setter=class:) int p5;
+@property (getter=new) int p6;
+@property (setter=new:) int p7;
+@property (getter=delete) int p8;
+@property (setter=delete:) int p9;
+@property (getter=delete) int p10;
+@property (setter=delete:) int p11;
+@end
Index: testsuite/obj-c++.dg/property/cxx-property-1.mm
===
--- testsuite/obj-c++.dg/property/cxx-property-1.mm (revision 0)
+++ testsuite/obj-c++.dg/property/cxx-property-1.mm (revision 0)
@@ -0,0 +1,10 @@
+/* Testcase from PR obj-c++/48275.  */
+/* { dg-do compile } */
+
+@interface Test
+{
+int ns;
+}
+@property (getter=namespace) int ns;
+
+@end
Index: cp/ChangeLog
===
--- cp/ChangeLog(revision 174656)
+++ cp/ChangeLog(working copy)
@@ -1,3 +1,9 @@
+2011-06-06  Nicola Pero  ,
+
+   PR obj-c++/48275
+   * parser.c (cp_parser_objc_at_property_declaration): Allow setter
+   and getter names to use all the allowed method names.
+
 2011-06-04  Jonathan Wakely  
 
* init.c (build_delete): Warn when deleting type with non-virtual
Index: cp/parser.c
===
--- cp/parser.c (revision 174656)
+++ cp/parser.c (working copy)
@@ -23187,7 +23187,7 @@ cp_parser_objc_at_property_declaration (cp_parser
  break;
}
  cp_lexer_consume_token (parser->lexer); /* eat the = */
- if (cp_lexer_next_token_is_not (parser->lexer, CPP_NAME))
+ if (!cp_parser_objc_selector_p (cp_lexer_peek_token 
(parser->lexer)->type))
{
  cp_parser_error (parser, "expected identifier");
  syntax_error = true;
@@ -23196,10 +23196,12 @@ cp_parser_objc_at_property_declaration (cp_parser
  if (keyword == RID_SETTER)
{
  if (property_setter_ident != NULL_TREE)
-   cp_parser_error (parser, "the % attribute may only 
be specified once");
+   {
+ cp_parser_error (parser, "the % attribute may 
only be specified once");
+ cp_lexer_consume_token (parser->lexer);
+   }
  else
-   property_setter_ident = cp_lexer_peek_token 
(parser->lexer)->u.value;
- cp_lexer_consume_token (parser->lexer);
+   property_setter_ident = cp_parser_objc_selector (parser);
  if (cp_lexer_next_token_is_not (parser->lexer, CPP_COLON))
cp_parser_error (parser, "setter name must terminate with 
%<:%>");
  else
@@ -23208,10 +23210,12 @@ cp_parser_objc_at_property_declaration (cp_parser
  else
{
  if (property_getter_ident != NULL_TREE)
-   cp_parser_error (parser, "the % attribute may only 
be specified once");
+   {
+ cp_parser_error (parser, "the % attribute may 
only be specified once");
+ cp_lexer_consume_token (parser->lexer);
+   }
  else
-   property_getter_ident = cp_lexer_peek_token 
(parser->lexer)->u.value;
- cp_lexer_consume_token (parser->lexer);
+   property_getter_ident = cp_parser_objc_selector (parser);
}
  break;
default:

Re: -fdump-passes -fenable-xxx=func_name_list

[Xinliang David Li]

This is the patch with max id removed.

Thanks,

David

On Mon, Jun 6, 2011 at 9:00 AM, Xinliang David Li  wrote:
> On Mon, Jun 6, 2011 at 4:38 AM, Richard Guenther
>  wrote:
>> On Thu, Jun 2, 2011 at 9:12 AM, Xinliang David Li  wrote:
>>> This is the version of the patch that walks through pass lists.
>>>
>>> Ok with this one?
>>
>> +/* Dump all optimization passes.  */
>> +
>> +void
>> +dump_passes (void)
>> +{
>> +  struct cgraph_node *n, *node = NULL;
>> +  tree save_fndecl = current_function_decl;
>> +
>> +  fprintf (stderr, "MAX_UID = %d\n", cgraph_max_uid);
>>
>> this isn't accurate info - cloning can cause more cgraph nodes to
>> appear (it also looks completely unrelated to dump_passes ...).
>> Please drop it.
>
> Ok.
>
>
>>
>> +  create_pass_tab();
>> +  gcc_assert (pass_tab);
>>
>> you have quite many asserts of this kind - we don't want them when
>> the previous stmt as in this case indicates everything is ok.
>
> ok.
>
>>
>> +  push_cfun (DECL_STRUCT_FUNCTION (node->decl));
>>
>> this has side-effects, I'm not sure we want this here.  Why do you
>> need it?  Probably because of
>>
>> +  is_really_on = override_gate_status (pass, current_function_decl, is_on);
>>
>> ?  But that is dependent on the function given which should have no
>> effect (unless it is overridden globally in which case override_gate_status
>> and friends should deal with a NULL cfun).
>
> As we discussed, currently some pass gate functions depend on per node
> information -- those checks need to be pushed into execute functions.
> I would like to clean those up later -- at which time, the push/pop
> can be removed.
>
>>
>> I don't understand why you need another table mapping pass to name
>> when pass->name is available and the info is trivially re-constructible.
>
> This is needed as the pass->name is not the canonicalized name (i.e.,
> not with number suffix etc), so the extra mapping from id to
> normalized name is needed.
>
> Thanks,
>
> David
>
>>
>> Thanks,
>> Richard.
>>
>>> David
>>>
>>> On Wed, Jun 1, 2011 at 12:45 PM, Xinliang David Li  
>>> wrote:
 On Wed, Jun 1, 2011 at 12:29 PM, Richard Guenther
  wrote:
> On Wed, Jun 1, 2011 at 6:16 PM, Xinliang David Li  
> wrote:
>> On Wed, Jun 1, 2011 at 1:51 AM, Richard Guenther
>>  wrote:
>>> On Wed, Jun 1, 2011 at 1:34 AM, Xinliang David Li  
>>> wrote:
 The following patch implements the a new option that dumps gcc PASS
 configuration. The sample output is attached.  There is one
 limitation: some placeholder passes that are named with '*xxx' are
 note registered thus they are not listed. They are not important as
 they can not be turned on/off anyway.

 The patch also enhanced -fenable-xxx and -fdisable-xx to allow a list
 of function assembler names to be specified.

 Ok for trunk?
>>>
>>> Please split the patch.
>>>
>>> I'm not too happy how you dump the pass configuration.  Why not simply,
>>> at a _single_ place, walk the pass tree?  Instead of doing pieces of it
>>> at pass execution time when it's not already dumped - that really looks
>>> gross.
>>
>> Yes, that was the original plan -- but it has problems
>> 1) the dumper needs to know the root pass lists -- which can change
>> frequently -- it can be a long term maintanance burden;
>> 2) the centralized dumper needs to be done after option processing
>> 3) not sure if gate functions have any side effects or have dependencies 
>> on cfun
>>
>> The proposed solutions IMHO is not that intrusive -- just three hooks
>> to do the dumping and tracking indentation.
>
> Well, if you have a CU that is empty or optimized to nothing at some point
> you will not get a complete pass list.  I suppose optimize attributes 
> might
> also confuse output.  Your solution might not be that intrusive
> but it is still ugly.  I don't see 1) as an issue, for 2) you can just 
> call the
> dumping from toplev_main before calling do_compile (), 3) gate functions
> shouldn't have side-effects, but as they could gate on optimize_for_speed 
> ()
> your option summary output will be bogus anyway.
>
> So - what is the output intended for if it isn't reliable?

 This needs to be cleaned up at some point -- the gate function should
 behave the same for all functions and per-function decisions need to
 be pushed down to the executor body.  I will try to rework the patch
 as you suggested to see if there are problems.

 David


>
> Richard.
>
>>>
>>> The documentation should also link this option to the -fenable/disable
>>> options as obviously the pass names in that dump are those to be
>>> used for those flags (and not readily available anywhere else).
>>
>> Ok.
>>
>>>
>>> I also think that it would be way more useful to note in the i

Re: [patch, fortran] Some more TRIM optimizations

[Thomas Koenig]

I wrote:


Hello world,

the attached patch extends removing trailing TRIMs in assignments for
cases like a // trim(b). Regression-tested. OK for trunk?

Thomas


This time with the test case corrected (cleanup of the *.original file)
and a more meaningful Subject line.

OK?

Thomas

2011-05-06  Thomas König  

* frontend-passes.c (optimize_assignment): Follow chains
of concatenation operators to the end for removing trailing
TRIMS for assignments.

2011-05-06  Thomas König  

* gfortran.dg/trim_optimize_7.f90:  New test.
Index: frontend-passes.c
===
--- frontend-passes.c	(Revision 174391)
+++ frontend-passes.c	(Arbeitskopie)
@@ -500,6 +500,14 @@ optimize_assignment (gfc_code * c)
 
   if (lhs->ts.type == BT_CHARACTER)
 {
+  /* Check for a // b // trim(c).  Looping is probably not
+	 necessary because the parser usually generates
+	 (// (// a b ) trim(c) ) , but better safe than sorry.  */
+
+  while (rhs->expr_type == EXPR_OP
+	 && rhs->value.op.op == INTRINSIC_CONCAT)
+	rhs = rhs->value.op.op2;
+
   if (rhs->expr_type == EXPR_FUNCTION &&
 	  rhs->value.function.isym &&
 	  rhs->value.function.isym->id == GFC_ISYM_TRIM)
! { dg-do run }
! { dg-options "-O -fdump-tree-original" }
! Check that trailing trims are also removed from assignment of
! expressions involving concatenations of strings .
program main
  character(2) :: a,b,c
  character(8) :: d
  a = 'a '
  b = 'b '
  c = 'c '
  d = a // b // a // trim(c)   ! This should be optimized away.
  if (d /= 'a b a c ') call abort
  d = a // trim(b) // c // a   ! This shouldn't.
  if (d /= 'a bc a  ') call abort
  d = a // b // a // trim(trim(c)) ! This should also be optimized away.
  if (d /= 'a b a c ') call abort
end
! { dg-final { scan-tree-dump-times "string_len_trim" 1 "original" } }
! { dg-final { cleanup-tree-dump "original" } }

Re: objc/objc++: switch all testcases to Modern Objective-C runtime API

[Dominique Dhumieres]

Nicola,

On x86_64-apple-darwin10 I have the following failures with -m32

FAIL: obj-c++.dg/threedotthree-abi-1.mm -fnext-runtime (test for excess errors)

FAIL: obj-c++.dg/torture/strings/const-str-10.mm  -O0  -fnext-runtime (test for 
excess errors)
FAIL: obj-c++.dg/torture/strings/const-str-10.mm  -O1  -fnext-runtime (test for 
excess errors)
FAIL: obj-c++.dg/torture/strings/const-str-10.mm  -O2  -fnext-runtime (test for 
excess errors)
FAIL: obj-c++.dg/torture/strings/const-str-10.mm  -O3 -fomit-frame-pointer  
-fnext-runtime (test for excess errors)
FAIL: obj-c++.dg/torture/strings/const-str-10.mm  -O3 -g  -fnext-runtime (test 
for excess errors)
FAIL: obj-c++.dg/torture/strings/const-str-10.mm  -Os  -fnext-runtime (test for 
excess errors)
FAIL: obj-c++.dg/torture/strings/const-str-10.mm  -O2 -flto 
-flto-partition=none  -fnext-runtime (test for excess errors)
FAIL: obj-c++.dg/torture/strings/const-str-10.mm  -O2 -flto  -fnext-runtime 
(test for excess errors)
FAIL: obj-c++.dg/torture/strings/const-str-11.mm  -O0  -fnext-runtime (test for 
excess errors)
FAIL: obj-c++.dg/torture/strings/const-str-11.mm  -O1  -fnext-runtime (test for 
excess errors)
FAIL: obj-c++.dg/torture/strings/const-str-11.mm  -O2  -fnext-runtime (test for 
excess errors)
FAIL: obj-c++.dg/torture/strings/const-str-11.mm  -O3 -fomit-frame-pointer  
-fnext-runtime (test for excess errors)
FAIL: obj-c++.dg/torture/strings/const-str-11.mm  -O3 -g  -fnext-runtime (test 
for excess errors)
FAIL: obj-c++.dg/torture/strings/const-str-11.mm  -Os  -fnext-runtime (test for 
excess errors)
FAIL: obj-c++.dg/torture/strings/const-str-11.mm  -O2 -flto 
-flto-partition=none  -fnext-runtime (test for excess errors)
FAIL: obj-c++.dg/torture/strings/const-str-11.mm  -O2 -flto  -fnext-runtime 
(test for excess errors)
FAIL: obj-c++.dg/torture/strings/const-str-9.mm  -O0  -fnext-runtime (test for 
excess errors)
FAIL: obj-c++.dg/torture/strings/const-str-9.mm  -O1  -fnext-runtime (test for 
excess errors)
FAIL: obj-c++.dg/torture/strings/const-str-9.mm  -O2  -fnext-runtime (test for 
excess errors)
FAIL: obj-c++.dg/torture/strings/const-str-9.mm  -O3 -fomit-frame-pointer  
-fnext-runtime (test for excess errors)
FAIL: obj-c++.dg/torture/strings/const-str-9.mm  -O3 -g  -fnext-runtime (test 
for excess errors)
FAIL: obj-c++.dg/torture/strings/const-str-9.mm  -Os  -fnext-runtime (test for 
excess errors)
FAIL: obj-c++.dg/torture/strings/const-str-9.mm  -O2 -flto -flto-partition=none 
 -fnext-runtime (test for excess errors)
FAIL: obj-c++.dg/torture/strings/const-str-9.mm  -O2 -flto  -fnext-runtime 
(test for excess errors)

The failures are

FAIL: obj-c++.dg/threedotthree-abi-1.mm -fnext-runtime (test for excess errors)
Excess errors:
/opt/gcc/work/gcc/testsuite/obj-c++.dg/threedotthree-abi-1.mm:51:78: warning: 
'descriptionForInstanceMethod:' is deprecated (declared at 
/usr/include/objc/Protocol.h:54) [-Wdeprecated-declarations]
/opt/gcc/work/gcc/testsuite/obj-c++.dg/threedotthree-abi-1.mm:54:78: warning: 
'descriptionForInstanceMethod:' is deprecated (declared at 
/usr/include/objc/Protocol.h:54) [-Wdeprecated-declarations]
/opt/gcc/work/gcc/testsuite/obj-c++.dg/threedotthree-abi-1.mm:57:78: warning: 
'descriptionForInstanceMethod:' is deprecated (declared at 
/usr/include/objc/Protocol.h:54) [-Wdeprecated-declarations]
/opt/gcc/work/gcc/testsuite/obj-c++.dg/threedotthree-abi-1.mm:60:78: warning: 
'descriptionForInstanceMethod:' is deprecated (declared at 
/usr/include/objc/Protocol.h:54) [-Wdeprecated-declarations]
/opt/gcc/work/gcc/testsuite/obj-c++.dg/threedotthree-abi-1.mm:63:78: warning: 
'descriptionForInstanceMethod:' is deprecated (declared at 
/usr/include/objc/Protocol.h:54) [-Wdeprecated-declarations]
/opt/gcc/work/gcc/testsuite/obj-c++.dg/threedotthree-abi-1.mm:66:79: warning: 
'descriptionForInstanceMethod:' is deprecated (declared at 
/usr/include/objc/Protocol.h:54) [-Wdeprecated-declarations]

FAIL: obj-c++.dg/torture/strings/const-str-10.mm  -O0  -fnext-runtime (test for 
excess errors)
Excess errors:
/opt/gcc/work/gcc/testsuite/obj-c++.dg/torture/strings/const-str-10.mm:27:26: 
warning: 'objc_class' is deprecated (declared at 
/usr/include/objc/runtime.h:46) [-Wdeprecated-declarations]

FAIL: obj-c++.dg/torture/strings/const-str-11.mm  -O0  -fnext-runtime (test for 
excess errors)
Excess errors:
/opt/gcc/work/gcc/testsuite/obj-c++.dg/torture/strings/const-str-11.mm:27:26: 
warning: 'objc_class' is deprecated (declared at 
/usr/include/objc/runtime.h:46) [-Wdeprecated-declarations]

FAIL: obj-c++.dg/torture/strings/const-str-9.mm  -O0  -fnext-runtime (test for 
excess errors)
Excess errors:
/opt/gcc/work/gcc/testsuite/obj-c++.dg/torture/strings/const-str-9.mm:19:26: 
warning: 'objc_class' is deprecated (declared at 
/usr/include/objc/runtime.h:46) [-Wdeprecated-declarations]

FAIL: objc.dg/stret-2.m scan-assembler-not objc_msgSend[^_S]
FAIL: objc.dg/threedotthree-abi-1.m -fnext-runtime (test for excess errors)

FAIL: objc.dg/torture/

C++ PATCH for c++/49298 (C++0x regression with pointer to member)

[Jason Merrill]

potential_constant_expression_1 didn't know how to deal with a 
pointer-to-member expression in a template.


Tested x86_64-pc-linux-gnu, applied to trunk.
commit a07ee89ff40f73dcb1fc11fb66931ee79bf8a2d9
Author: Jason Merrill 
Date:   Mon Jun 6 12:05:39 2011 -0400

	PR c++/49298
	* semantics.c (potential_constant_expression_1): Handle FIELD_DECL.

diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 5626a86..f005f2f 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -7489,6 +7489,8 @@ potential_constant_expression_1 (tree t, bool want_rval, tsubst_flags_t flags)
 case TEMPLATE_PARM_INDEX:
 case TRAIT_EXPR:
 case IDENTIFIER_NODE:
+  /* We can see a FIELD_DECL in a pointer-to-member expression.  */
+case FIELD_DECL:
   return true;
 
 case PARM_DECL:
diff --git a/gcc/testsuite/g++.dg/cpp0x/regress/ptrmem1.C b/gcc/testsuite/g++.dg/cpp0x/regress/ptrmem1.C
new file mode 100644
index 000..873000b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/regress/ptrmem1.C
@@ -0,0 +1,9 @@
+// PR c++/49298
+// { dg-options -std=c++0x }
+
+template  struct B { };
+template  struct A
+{
+  int i;
+  B b;
+};

Re: [PATCH] Fix PR debug/49130

[Jason Merrill]

OK.

Jason

Re: objc/objc++: switch all testcases to Modern Objective-C runtime API

[IainS]

On 6 Jun 2011, at 21:07, Nicola Pero wrote:


On x86_64-apple-darwin10 I have the following failures with -m32


darwin10 is Mac OS X 10.6, right ?  I have access to that.  So, how  
do you test with -m32 ?
I thought the testsuite would do that (test both with -m32 and -m64  
if they are available) automatically,

but clearly it doesn't, because I never saw these failures ;-)


It doesn't...
.. if you want to be pedantic the following should cover all bases on  
a given platform > 10.4:


make -k check-objc check-obj-c++ RUNTESTFLAGS="--target_board=unix\{- 
m32,-m32/-fabi-version=1,-m64\} "


I am doing this on i686-darwin9 at the moment with your original path  
- will re-try your re-posted patch.


As a far as my opinion, if it passes OK @m32 on darwin9 (10.5.x) - I'm  
with Mike that we have time to sort out any problems on darwin8  
(10.4.x).


cheers
Iain