Re: [PATCH i386 3/8] [AVX512] [1/n] Add AVX-512 patterns: VF iterator extended.

[Kirill Yukhin]

Hello,
On 13 Sep 14:28, Kirill Yukhin wrote:
> Hello,
> On 09 Sep 15:11, Kirill Yukhin wrote:
> > Hello,
> > On 06 Sep 17:41, Kirill Yukhin wrote:
> > > Hello,
> > > 
> > > PING.
> > PING.
> PING.
PING

--
Thanks, K

Re: [PATCH v2 1/6] Convert symtab, cgraph and varpool nodes into a real class hierarchy

[Jan Hubicka]

> > > +cgraph_node *cgn = static_cast  (x);
> > > +gt_ggc_m_11cgraph_edge (cgn->callers);
> > > +gt_ggc_m_11cgraph_node (cgn->origin);
> > > +gt_ggc_m_11cgraph_node (cgn->nested);
> > > +gt_ggc_m_11cgraph_node (cgn->next_nested);
> > > +gt_ggc_m_11cgraph_node (cgn->next_sibling_clone);
> > > +gt_ggc_m_11cgraph_node (cgn->prev_sibling_clone);
> > > +gt_ggc_m_11cgraph_node (cgn->clones);
> > > +gt_ggc_m_11cgraph_node (cgn->clone_of);
> > Same as here.
> 
> Sorry, it's not clear to me what you meant by "Same as here." here.  Do
> you mean that I can skip marking them because they're within the symbol
> table?   If so, are you referring to all 10 fields above ("callees"
> through "clone_of")?

All those pointers above points inside symbol table, so none of them needs
to be marked.  Actually those two needs however, I missed them with prevoius
reading:
> > > +gt_ggc_m_11cgraph_edge (cgn->indirect_calls);
> > > +gt_ggc_m_11cgraph_edge (cgn->callees);

Otherwise edges will probably get lost.
> 
> 
> > 
> > > +gt_ggc_m_P11cgraph_edge4htab (cgn->call_site_hash);
> > Move call site hash out of GGC rather than introducing hack.
> 
> I see that this is allocated in cgraph_edge (), and it appears to be an
> index.  I can create it with htab_create rather than htab_create_ggc,
> but if so, there doesn't seem a natural place to call htab_delete.  Is
> that OK?

Delete it in cgraph_remove_node.
> 
> 
> > > +gt_ggc_m_9tree_node (cgn->former_clone_of);
> > > +gt_ggc_m_11cgraph_node (cgn->global.inlined_to);
> > And here
> 
> Again, do you mean that "inlined_to" can be skipped since it's in the
> symbol table?

yes.
> > > +cgraph_node *cgn = static_cast  (x);
> > > +gt_pch_n_11cgraph_edge (cgn->callees);
> > > +gt_pch_n_11cgraph_edge (cgn->callers);
> > > +gt_pch_n_11cgraph_edge (cgn->indirect_calls);
> > > +gt_pch_n_11cgraph_node (cgn->origin);
> > > +gt_pch_n_11cgraph_node (cgn->nested);
> > > +gt_pch_n_11cgraph_node (cgn->next_nested);
> > > +gt_pch_n_11cgraph_node (cgn->next_sibling_clone);
> > > +gt_pch_n_11cgraph_node (cgn->prev_sibling_clone);
> > > +gt_pch_n_11cgraph_node (cgn->clones);
> > > +gt_pch_n_11cgraph_node (cgn->clone_of);
> > > +gt_pch_n_P11cgraph_edge4htab (cgn->call_site_hash);
> > > +gt_pch_n_9tree_node (cgn->former_clone_of);
> > > +gt_pch_n_11cgraph_node (cgn->global.inlined_to);
> > > +gt_pch_n_28vec_ipa_replace_map_p_va_gc_ 
> > > (cgn->clone.tree_map);
> > > +gt_pch_n_15bitmap_head_def (cgn->clone.args_to_skip);
> > > +gt_pch_n_15bitmap_head_def 
> > > (cgn->clone.combined_args_to_skip);
> > > +gt_pch_n_9tree_node (cgn->thunk.alias);
> > 
> > We can skip good part of those. Just small of those is build at PCH time. 
> > But lets do that incrementally, PCH is touchy business.
> 
> OK.  I'll just make analogous changes here to those made to the
> gt_ggc_mx function.

I think some of the pointers that do not need to be marked still needs to be
streamed and fixed by PCH, so we probably want to keep them.  All the cloning
pointers above are not live at PCH time (they are always NULL).  Only reason
why PCH lives at that point is that C++ FE produces Cgraph nodes early for
funny reason. The nodes are not analyzed at that point and call edges do not
exist (if I recall right) Probably I can do this incrementally - we do not want
to break PCH with a large patch and then spend weeks analyzing it.  That things
can bite ;)

Honza

Re: [wide-int] Fix mode choice in convert_modes

[Richard Sandiford]

Ping

Richard Sandiford  writes:
> Enabling the CONST_INT assert showed that this branch-local code was
> passing the wrong mode to std::make_pair.  The mode of X is OLDMODE,
> and we're supposed to be converting it to MODE.
>
> In the case where OLDMODE is VOIDmode, I think we have to assume
> that every bit of the input is significant.
>
> Tested on x86_64-linux-gnu.  OK to install?
>
> This and the other patches that I just committed to trunk are enough
> for a bootstrap and regression test to pass on x86_64-linux-gnu with
> the assertion for a canonical CONST_INT enabled.  I think it would be
> better to leave the assertion out until after the merge though,
> so we can deal with any fallout separately.
>
> Thanks,
> Richard
>
>
> Index: gcc/expr.c
> ===
> --- gcc/expr.c2013-09-09 11:32:33.734617409 +0100
> +++ gcc/expr.c2013-09-09 11:45:27.381001353 +0100
> @@ -714,13 +714,14 @@ convert_modes (enum machine_mode mode, e
>&& GET_MODE_CLASS (mode) == MODE_INT
>&& (oldmode == VOIDmode || GET_MODE_CLASS (oldmode) == MODE_INT))
>  {
> -  wide_int w = std::make_pair (x, mode);
>/* If the caller did not tell us the old mode, then there is
> -  not much to do with respect to canonization.  */
> -  if (oldmode != VOIDmode
> -   && GET_MODE_PRECISION (mode) > GET_MODE_PRECISION (oldmode))
> - w = wi::ext (w, GET_MODE_PRECISION (oldmode),
> -  unsignedp ? UNSIGNED : SIGNED);
> +  not much to do with respect to canonization.  We have to assume
> +  that all the bits are significant.  */
> +  if (oldmode == VOIDmode)
> + oldmode = MAX_MODE_INT;
> +  wide_int w = wide_int::from (std::make_pair (x, oldmode),
> +GET_MODE_PRECISION (mode),
> +unsignedp ? UNSIGNED : SIGNED);
>return immed_wide_int_const (w, mode);
>  }
>  

Re: [PATCH, committed] SH: Fix PR58314 (unsatisfied constraints)

[Christian Bruel]

Hi Richard,

On 09/16/2013 07:10 PM, Richard Sandiford wrote:
> Hi Christian,
>
> Christian Bruel  writes:
>> @@ -6893,11 +6894,14 @@ label:
>>  ;; reloading MAC subregs otherwise.  For that probably special patterns
>>  ;; would be required.
>>  (define_insn "*mov_reg_reg"
>> -  [(set (match_operand:QIHI 0 "arith_reg_dest" "=r")
>> -(match_operand:QIHI 1 "register_operand" "r"))]
>> +  [(set (match_operand:QIHI 0 "arith_reg_dest" "=r,m,*z")
>> +(match_operand:QIHI 1 "register_operand" "r,*z,m"))]
> If the constraints allow "m", the predicates need to accept memories too.
> (It'd be worth having an insn condition that rejects both operands
> being memories though.)
>
> Thanks,
> Richard
Thanks for your comment,

I was wondering this too when doing the fix. I felt that a memory
operand would be matched by the *movhi" patterns bellow.  As  I wanted
to fix only the spilling case, so the original operand is a pseudo reg
having matched the register predicate.
Without the predicate memory not found, I wonder how I never hit a kind
of "insn not found" error,  well, 'll give a try to adding a memory
condition in the predicate, but I fear that the movhi patterns will stop
to match,

Cheers

Christian

Commit: MSP430: Pass -md on to assembler

[Nick Clifton]

Hi Guys,

  I am applying the patch below to add a couple of minor tweaks to the
  msp430.h header file.  The first is to pass the -md command line
  option to the assembler, to enable the copying of data from ROM to
  RAM.  (This is a code size optimization.  The assembler and linker
  conspire to detect when the .data section is empty and, if it is, the
  code to perform the copying is omitted from crt0.o.  The -md command
  line option enables this feature).

  The other tweak is to define ASM_DECLARE_FUNCTION_NAME so that
  msp430_start_function can provide some annotations describing the
  function in the assembler output.  This is mainly for debugging
  purposes.

Cheers
  Nick

gcc/ChangeLog
2013-09-18  Nick Clifton  

* config/msp430/msp430.h (ASM_SPEC): Pass -md on to the assembler.
(ASM_DECLARE_FUNCTION_NAME): Define.

Index: gcc/config/msp430/msp430.h
===
--- gcc/config/msp430/msp430.h  (revision 202680)
+++ gcc/config/msp430/msp430.h  (working copy)
@@ -54,6 +54,7 @@
   "%{mmcu=msp430x:-mmcu=msp430X;mmcu=*:-mmcu=%*} " /* Pass the MCU type on to 
the assembler.  */  \
   "%{mrelax=-mQ} " /* Pass the relax option on to the assembler.  */ \
   "%{mlarge:-ml} " /* Tell the assembler if we are building for the LARGE 
pointer model.  */ \
+  "%{!msim:-md} %{msim:%{mlarge:-md}}" /* Copy data from ROM to RAM if 
necessary.  */ \
   "%{ffunction-sections:-gdwarf-sections}" /* If function sections are being 
created then create DWARF line number sections as well.  */
 
 /* Enable linker section garbage collection by default, unless we
@@ -399,3 +400,7 @@
   )
 
 #define ACCUMULATE_OUTGOING_ARGS 1
+
+#undef  ASM_DECLARE_FUNCTION_NAME
+#define ASM_DECLARE_FUNCTION_NAME(FILE, NAME, DECL) \
+  msp430_start_function ((FILE), (NAME), (DECL))

[PATCH][gomp4] Plugins Support in LibGOMP (Take 2)

[Michael V. Zolotukhin]

Hi Jakub,

I merged my patch with recent changes in gomp4-branch, and the new version is
below.  Also, I fixed most of your remarks - the one isn't fixed is checking
sizeof(void*)==sizeof(uintptr_t) in configure.  I'll do it in the next patch.

Is it ok for gomp4-branch?

Also, I was thinking of how we could test such changes.  Maybe we need to add
some logging stuff to all these libgomp routines - then we could check logs and
thus test if everything works as expected.  Otherwise it's really hard to find
out, whether offloading happened or not.  What do you think?

Thanks, Michael

---
 libgomp/config.h.in  |   6 ++
 libgomp/configure|  63 +++
 libgomp/configure.ac |   9 ++
 libgomp/target.c | 290 ++-
 4 files changed, 320 insertions(+), 48 deletions(-)

diff --git a/libgomp/config.h.in b/libgomp/config.h.in
index 14c7e2a..67f5420 100644
--- a/libgomp/config.h.in
+++ b/libgomp/config.h.in
@@ -30,6 +30,9 @@
 /* Define to 1 if you have the  header file. */
 #undef HAVE_INTTYPES_H
 
+/* Define to 1 if you have the `dl' library (-ldl). */
+#undef HAVE_LIBDL
+
 /* Define to 1 if you have the  header file. */
 #undef HAVE_MEMORY_H
 
@@ -107,6 +110,9 @@
 /* Define to the version of this package. */
 #undef PACKAGE_VERSION
 
+/* Define if all infrastructure, needed for plugins, is supported. */
+#undef PLUGIN_SUPPORT
+
 /* The size of `char', as computed by sizeof. */
 #undef SIZEOF_CHAR
 
diff --git a/libgomp/configure b/libgomp/configure
index 238b1af..f4f71a4 100755
--- a/libgomp/configure
+++ b/libgomp/configure
@@ -15046,6 +15046,69 @@ fi
 rm -f core conftest.err conftest.$ac_objext \
 conftest$ac_exeext conftest.$ac_ext
 
+plugin_support=yes
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for dlsym in -ldl" >&5
+$as_echo_n "checking for dlsym in -ldl... " >&6; }
+if test "${ac_cv_lib_dl_dlsym+set}" = set; then :
+  $as_echo_n "(cached) " >&6
+else
+  ac_check_lib_save_LIBS=$LIBS
+LIBS="-ldl  $LIBS"
+cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+
+/* Override any GCC internal prototype to avoid an error.
+   Use char because int might match the return type of a GCC
+   builtin and then its argument prototype would still apply.  */
+#ifdef __cplusplus
+extern "C"
+#endif
+char dlsym ();
+int
+main ()
+{
+return dlsym ();
+  ;
+  return 0;
+}
+_ACEOF
+if ac_fn_c_try_link "$LINENO"; then :
+  ac_cv_lib_dl_dlsym=yes
+else
+  ac_cv_lib_dl_dlsym=no
+fi
+rm -f core conftest.err conftest.$ac_objext \
+conftest$ac_exeext conftest.$ac_ext
+LIBS=$ac_check_lib_save_LIBS
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_dl_dlsym" >&5
+$as_echo "$ac_cv_lib_dl_dlsym" >&6; }
+if test "x$ac_cv_lib_dl_dlsym" = x""yes; then :
+  cat >>confdefs.h <<_ACEOF
+#define HAVE_LIBDL 1
+_ACEOF
+
+  LIBS="-ldl $LIBS"
+
+else
+  plugin_support=no
+fi
+
+ac_fn_c_check_header_mongrel "$LINENO" "dirent.h" "ac_cv_header_dirent_h" 
"$ac_includes_default"
+if test "x$ac_cv_header_dirent_h" = x""yes; then :
+
+else
+  plugin_support=no
+fi
+
+
+
+if test x$plugin_support = xyes; then
+
+$as_echo "#define PLUGIN_SUPPORT 1" >>confdefs.h
+
+fi
+
 # Check for functions needed.
 for ac_func in getloadavg clock_gettime strtoull
 do :
diff --git a/libgomp/configure.ac b/libgomp/configure.ac
index d87ed29..85ecbcf 100644
--- a/libgomp/configure.ac
+++ b/libgomp/configure.ac
@@ -193,6 +193,15 @@ AC_LINK_IFELSE(
[],
[AC_MSG_ERROR([Pthreads are required to build libgomp])])])
 
+plugin_support=yes
+AC_CHECK_LIB(dl, dlsym, , [plugin_support=no])
+AC_CHECK_HEADER(dirent.h, , [plugin_support=no])
+
+if test x$plugin_support = xyes; then
+  AC_DEFINE(PLUGIN_SUPPORT, 1,
+[Define if all infrastructure, needed for plugins, is supported.])
+fi
+
 # Check for functions needed.
 AC_CHECK_FUNCS(getloadavg clock_gettime strtoull)
 
diff --git a/libgomp/target.c b/libgomp/target.c
index e9b3386..fd2383e 100644
--- a/libgomp/target.c
+++ b/libgomp/target.c
@@ -30,6 +30,15 @@
 #include 
 #include 
 
+#ifdef PLUGIN_SUPPORT
+# include 
+# include 
+#endif
+
+static void gomp_target_init (void);
+
+static pthread_once_t gomp_is_initialized = PTHREAD_ONCE_INIT;
+
 /* Forward declaration for a node in the tree.  */
 typedef struct splay_tree_node_s *splay_tree_node;
 typedef struct splay_tree_s *splay_tree;
@@ -50,6 +59,10 @@ struct target_mem_desc {
   struct target_mem_desc *prev;
   /* Number of items in following list.  */
   size_t list_count;
+
+  /* Corresponding target device descriptor.  */
+  struct gomp_device_descr* device_descr;
+
   /* List of splay keys to remove (or decrease refcount)
  at the end of region.  */
   splay_tree_key list[];
@@ -70,6 +83,12 @@ struct splay_tree_key_s {
   bool copy_from;
 };
 
+/* Array of descriptors of all available devices.  */
+static struct gomp_device_descr *devices;
+
+/* Total number of available devices.  */
+static int num_devices;
+
 /* The comparison function.  */
 
 static int
@@ -87,33 +106,

Re: [ping][PATCH][1 of 2] Add value range info to SSA_NAME for zero sign extension elimination in RTL

[Richard Earnshaw]

On 16/09/13 15:13, Richard Biener wrote:
> +void
> +get_range_info (tree name, double_int &min, double_int &max,
> +enum value_range_type &range_type)
> 
> I'm not sure we want to use references.  Well - first time.

Personally, I don't think we should ever allow non-const references.
Use of references means you can't tell from the source code that an
argument to a function can be modified.  It leads to confusion and makes
things harder to debug.  It can also lead to more object code bloat
because more things end up being addressable.

R.

Re: [ping][PATCH][1 of 2] Add value range info to SSA_NAME for zero sign extension elimination in RTL

[Richard Biener]

On Wed, 18 Sep 2013, Richard Earnshaw wrote:

> On 16/09/13 15:13, Richard Biener wrote:
> > +void
> > +get_range_info (tree name, double_int &min, double_int &max,
> > +enum value_range_type &range_type)
> > 
> > I'm not sure we want to use references.  Well - first time.
> 
> Personally, I don't think we should ever allow non-const references.
> Use of references means you can't tell from the source code that an
> argument to a function can be modified.  It leads to confusion and makes
> things harder to debug.

That's a good argument, so please make get_range_info take pointers
to min/max/range_type.

Richard.

Re: [PATCH][gomp4] Plugins Support in LibGOMP (Take 2)

[Jakub Jelinek]

On Wed, Sep 18, 2013 at 12:35:38PM +0400, Michael V. Zolotukhin wrote:
> I merged my patch with recent changes in gomp4-branch, and the new version is
> below.  Also, I fixed most of your remarks - the one isn't fixed is checking
> sizeof(void*)==sizeof(uintptr_t) in configure.  I'll do it in the next patch.
> 
> Is it ok for gomp4-branch?
> 
> Also, I was thinking of how we could test such changes.  Maybe we need to add
> some logging stuff to all these libgomp routines - then we could check logs 
> and
> thus test if everything works as expected.  Otherwise it's really hard to find
> out, whether offloading happened or not.  What do you think?

The OpenMP standard has the omp_is_initial_device () function that can be
used to query whether the code is offloaded or not.  So I don't think we
need to do the logging.  For the device 257 hack we of course don't return
that as true, but that is a hack that is going away.
> @@ -50,6 +59,10 @@ struct target_mem_desc {
>struct target_mem_desc *prev;
>/* Number of items in following list.  */
>size_t list_count;
> +
> +  /* Corresponding target device descriptor.  */
> +  struct gomp_device_descr* device_descr;

Please put the space before *, not after it.

> +  /* Plugin file name.  */
> +  char plugin_name[PATH_MAX];

I don't like such fixed size arrays, for most cases
it will be big memory waste.  What do you need the plugin_name
for?  And, if you really need it past dlopen, can't you store
it as const char *plugin_name instead?
> +
> +  /* Plugin file handler.  */
> +  void *plugin_handle;
> +
> +  /* Function handlers.  */
> +  bool (*device_available_func) (void);

The scan hook shouldn't give you just bool whether the device is available,
but how many devices of that kind are available.  You can have 2 MIC
cards and one or two HSAIL GPGPU in a box e.g.  Plus, is this hook useful
after the initialization at all?  I'd say it would be enough to just
dlsym it during initialization, ask how many devices it has and just create
that many device structures with that plugin_handle.
What you want are hooks for device_alloc (taking size and align arguments,
returning uintptr_t target address), device_free (taking uintptr_t target
address and perhaps size), device_copyto (like memcpy, just with target
address uintptr_t instead of void *) and device_copyfrom (similarly),
and device_run hook or similar (taking host and target fn and target
uintptr_t address of the block with pointers).

>  attribute_hidden int
>  gomp_get_num_devices (void)
>  {
> -  /* FIXME: Scan supported accelerators when called the first time.  */
> -  return 0;

You need to call pthread_once here too, so that omp_get_num_devices returns
the correct number.

> +  return num_devices;
>  }
>  
> -static int
> -resolve_device (int device)
> +static struct gomp_device_descr*
> +resolve_device (int device_id)
>  {
> -  if (device == -1)
> +  (void) pthread_once (&gomp_is_initialized, gomp_target_init);

Thus, IMHO you should just call gomp_get_num_devices () here, or after the
if (device_id == -1) block, and that will ensure gomp_target_init has been
already called.  Just save the return value into a temporary.

> +  if (device_id == -1)
>  {
>struct gomp_task_icv *icv = gomp_icv (false);
> -  device = icv->default_device_var;
> +  device_id = icv->default_device_var;
>  }
>/* FIXME: Temporary hack for testing non-shared address spaces on host.  */
> -  if (device == 257)
> -return 257;
> -  if (device >= gomp_get_num_devices ())
> -return -1;
> -  return -1;
> +  if (device_id == 257)
> +return &devices[0];

Guess the hack should be if gomp_get_num_devices () returned 0 and
device_id == 257, otherwise the hack device won't be created.

> @@ -137,15 +179,20 @@ gomp_map_vars_existing (splay_tree_key oldn, 
> splay_tree_key newn,
>  }
>  
>  static struct target_mem_desc *
> -gomp_map_vars (size_t mapnum, void **hostaddrs, size_t *sizes,
> -unsigned char *kinds, bool is_target)
> +gomp_map_vars (struct gomp_device_descr* devicep, size_t mapnum,

Again, please watch the formatting.

> -  struct target_mem_desc *tgt
> -= gomp_malloc (sizeof (*tgt) + sizeof (tgt->list[0]) * mapnum);
> +  struct target_mem_desc *tgt = NULL;
> +  tgt = gomp_malloc (sizeof (*tgt) + sizeof (tgt->list[0]) * mapnum);

Why this change?

>tgt->list_count = mapnum;
>tgt->refcount = 1;
> +  tgt->device_descr = devicep;
> +
> +  if (!devicep)
> +return tgt;

Why this conditional?  mapnum == 0 conditional below will do the trick.

>if (mapnum == 0)
>  return tgt;

> @@ -322,6 +373,8 @@ gomp_unmap_tgt (struct target_mem_desc *tgt)
>  static void
>  gomp_unmap_vars (struct target_mem_desc *tgt)
>  {
> +  struct gomp_device_descr* devicep = tgt->device_descr;
> +

Formatting (several other places too).

> +  /* FIXME: currently only device 257 is available and it is a hack which is
> + done only to test the functionality early.  We need to enable all 

Re: [ping][PATCH][1 of 2] Add value range info to SSA_NAME for zero sign extension elimination in RTL

[Jakub Jelinek]

On Wed, Sep 18, 2013 at 10:57:57AM +0200, Richard Biener wrote:
> On Wed, 18 Sep 2013, Richard Earnshaw wrote:
> 
> > On 16/09/13 15:13, Richard Biener wrote:
> > > +void
> > > +get_range_info (tree name, double_int &min, double_int &max,
> > > +enum value_range_type &range_type)
> > > 
> > > I'm not sure we want to use references.  Well - first time.
> > 
> > Personally, I don't think we should ever allow non-const references.
> > Use of references means you can't tell from the source code that an
> > argument to a function can be modified.  It leads to confusion and makes
> > things harder to debug.
> 
> That's a good argument, so please make get_range_info take pointers
> to min/max/range_type.

Or return range_type and just take min/max pointers?

Jakub

Re: [ping][PATCH][1 of 2] Add value range info to SSA_NAME for zero sign extension elimination in RTL

[Jan Hubicka]

> On Wed, Sep 18, 2013 at 10:57:57AM +0200, Richard Biener wrote:
> > On Wed, 18 Sep 2013, Richard Earnshaw wrote:
> > 
> > > On 16/09/13 15:13, Richard Biener wrote:
> > > > +void
> > > > +get_range_info (tree name, double_int &min, double_int &max,
> > > > +enum value_range_type &range_type)
> > > > 
> > > > I'm not sure we want to use references.  Well - first time.
> > > 
> > > Personally, I don't think we should ever allow non-const references.
> > > Use of references means you can't tell from the source code that an
> > > argument to a function can be modified.  It leads to confusion and makes
> > > things harder to debug.

I use non-const references in ipa-devirt code and speculative indirect call 
removal.
I am not thrilled by them, just it seems common in C++ source bases.  If we 
don't want
them, i will remove these (they are used on two or three places, so it is  easy)

Honza
> > 
> > That's a good argument, so please make get_range_info take pointers
> > to min/max/range_type.
> 
> Or return range_type and just take min/max pointers?
> 
>   Jakub

Re: Use CreateSemaphoreW instead of CreateSemaphoreA in libgcc.

[Jacek Caban]

On 09/18/13 10:57, Pedro Alves wrote:
> On 09/17/2013 12:19 PM, Jacek Caban wrote:
>> This is no-op for usual GCC targets, because we don't pass any string to
>> CreateSemaphore anyway. However this trivial change will help
>> mingw-w64's efforts to support WinRT, where only unicode variant is
>> available.
>>
>> libgcc/Changelog:
>> config/i386/gthr-win32.c: CreateSemaphoreW instead of CreateSemaphoreA.
>> config/i386/gthr-win32.h: Likewise.
>>
> I'm a bit puzzled and curious about why you actually need this (and other
> similar patches), since the Windows CE port manages without them, and there,
> likewise only the W variants are available (for the whole Win32 API).
> The w32api headers do things like:
>
> WINBASEAPI HANDLE WINAPI 
> CreateSemaphoreA(LPSECURITY_ATTRIBUTES,LONG,LONG,LPCSTR);
> WINBASEAPI HANDLE WINAPI 
> CreateSemaphoreW(LPSECURITY_ATTRIBUTES,LONG,LONG,LPCWSTR);
>
> #ifdef UNICODE
> #define CreateSemaphore CreateSemaphoreW
> #else
> #define CreateSemaphore CreateSemaphoreA
> #endif
>
> AFAICS, the mingw-w64 headers do something equivalent.
>
> For Windows CE, UNICODE is always defined, so uses of CreateSemaphore
> end up calling CreateSemaphoreW.   Doesn't WinRT always define
> UNICODE similarly?  If not, shouldn't it?

Current mingw-w64 solution uses regular GCC build and adds a
compatibility library for building for winrt target. This means that
libgcc is not aware of winrt and is built for regular win32 target.
Also, I think that being explicit about API variant we use is a good
thing. UNICODE macro may be useful for stuff that has any reason to be
changed by a switch, which is not the case here, IMO.

Jacek

RE: [PATCH ARM]Refine scaled address expression on ARM

[bin.cheng]

> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of bin.cheng
> Sent: Monday, September 02, 2013 3:09 PM
> To: Richard Earnshaw
> Cc: gcc-patches@gcc.gnu.org
> Subject: RE: [PATCH ARM]Refine scaled address expression on ARM
> 
> 
> 
> > -Original Message-
> > From: Richard Earnshaw
> > Sent: Thursday, August 29, 2013 9:06 PM
> > To: Bin Cheng
> > Cc: gcc-patches@gcc.gnu.org
> > Subject: Re: [PATCH ARM]Refine scaled address expression on ARM
> >
> > On 28/08/13 08:00, bin.cheng wrote:
> > > Hi,
> > >
> > > This patch refines scaled address expression on ARM.  It supports
> > > "base+index*scale" in arm_legitimate_address_outer_p.  It also tries
> > > to legitimize "base + index * scale + offset" with "reg <- base +
> > > offset;  reg
> > > + index * scale" by introducing thumb2_legitimize_address.  For now
> > > + function
> > > thumb2_legitimize_address is a kind of placeholder and just does the
> > > mentioned transformation by calling to try_multiplier_address.
> > > Hoping we can improve it in the future.
> > >
> > > With this patch:
> > > 1) "base+index*scale" is recognized.
> >
> > That's because (PLUS (REG) (MULT (REG) (CONST))) is not canonical form.
> >  So this shouldn't be necessary.  Can you identify where this
> non-canoncial form is being generated?
> >
> 
> Oh, for now ivopt constructs "index*scale" to test whether backend
> supports scaled addressing mode, which is not valid on ARM, so I was going
> to construct "base + index*scale" instead.  Since "base + index * scale"
is not
> canonical form, I will construct the canonical form and drop this part of
the
> patch.
> 
> Is rest of this patch OK?
> 
Hi Richard, I removed the part over which you concerned and created this
updated patch.

Is it OK?

Thanks.
bin

2013-09-18  Bin Cheng  

* config/arm/arm.c (try_multiplier_address): New function.
(thumb2_legitimize_address): New function.
(arm_legitimize_address): Call try_multiplier_address and
thumb2_legitimize_address.Index: gcc/config/arm/arm.c
===
--- gcc/config/arm/arm.c(revision 200774)
+++ gcc/config/arm/arm.c(working copy)
@@ -6652,6 +6654,106 @@ legitimize_tls_address (rtx x, rtx reg)
 }
 }
 
+/* Try to find address expression like base + index * scale + offset
+   in X.  If we find one, force base + offset into register and
+   construct new expression reg + index * scale; return the new
+   address expression if it's valid.  Otherwise return X.  */
+static rtx
+try_multiplier_address (rtx x, enum machine_mode mode ATTRIBUTE_UNUSED)
+{
+  rtx tmp, base_reg, new_rtx;
+  rtx base = NULL_RTX, index = NULL_RTX, scale = NULL_RTX, offset = NULL_RTX;
+
+  gcc_assert (GET_CODE (x) == PLUS);
+
+  /* Try to find and record base/index/scale/offset in X. */
+  if (GET_CODE (XEXP (x, 1)) == MULT)
+{
+  tmp = XEXP (x, 0);
+  index = XEXP (XEXP (x, 1), 0);
+  scale = XEXP (XEXP (x, 1), 1);
+  if (GET_CODE (tmp) != PLUS)
+   return x;
+
+  base = XEXP (tmp, 0);
+  offset = XEXP (tmp, 1);
+}
+  else
+{
+  tmp = XEXP (x, 0);
+  offset = XEXP (x, 1);
+  if (GET_CODE (tmp) != PLUS)
+   return x;
+
+  base = XEXP (tmp, 0);
+  scale = XEXP (tmp, 1);
+  if (GET_CODE (base) == MULT)
+   {
+ tmp = base;
+ base = scale;
+ scale = tmp;
+   }
+  if (GET_CODE (scale) != MULT)
+   return x;
+
+  index = XEXP (scale, 0);
+  scale = XEXP (scale, 1);
+}
+
+  if (CONST_INT_P (base))
+{
+  tmp = base;
+  base = offset;
+  offset = tmp;
+}
+
+  if (CONST_INT_P (index))
+{
+  tmp = index;
+  index = scale;
+  scale = tmp;
+}
+
+  /* ARM only supports constant scale in address.  */
+  if (!CONST_INT_P (scale))
+return x;
+
+  if (GET_MODE (base) != SImode || GET_MODE (index) != SImode)
+return x;
+
+  /* Only register/constant are allowed in each part.  */
+  if (!symbol_mentioned_p (base)
+  && !symbol_mentioned_p (offset)
+  && !symbol_mentioned_p (index)
+  && !symbol_mentioned_p (scale))
+{
+  /* Force "base+offset" into register and construct
+"register+index*scale".  Return the new expression
+only if it's valid.  */
+  tmp = gen_rtx_PLUS (SImode, base, offset);
+  base_reg = force_reg (SImode, tmp);
+  tmp = gen_rtx_fmt_ee (MULT, SImode, index, scale);
+  new_rtx = gen_rtx_PLUS (SImode, base_reg, tmp);
+  return new_rtx;
+}
+
+  return x;
+}
+
+/* Try machine-dependent ways of modifying an illegitimate Thumb2 address
+   to be legitimate.  If we find one, return the new address.
+
+   TODO: legitimize_address for Thumb2.  */
+static rtx
+thumb2_legitimize_address (rtx x, rtx orig_x ATTRIBUTE_UNUSED,
+  enum machine_mode mode)
+{
+  if (GET_CODE (x) == PLUS)
+return try_mul

Re: [ping][PATCH][1 of 2] Add value range info to SSA_NAME for zero sign extension elimination in RTL

[Richard Biener]

On Wed, 18 Sep 2013, Kugan wrote:

> 
> Thanks Richard for the review.
> On 16/09/13 23:43, Richard Biener wrote:
> > On Mon, 16 Sep 2013, Kugan wrote:
> > 
> > > Hi,
> > > 
> > > Updated the patch to the latest changes in trunk that splits tree.h. I
> > > also
> > > noticed an error in printing double_int and fixed it.
> > > 
> > > Is this OK?
> > 
> > print_gimple_stmt (dump_file, stmt, 0,
> > -TDF_SLIM | (dump_flags & TDF_LINENO));
> > +TDF_SLIM | TDF_RANGE | (dump_flags &
> > TDF_LINENO));
> > 
> > this should be (dump_flags & (TDF_LINENO|TDF_RANGE)) do not always
> > dump range info.  I'd have simply re-used TDF_ALIAS (and interpret
> > it as SSA annotation info), adding -range in dump file modifiers
> > is ok with me.
> > 
> > +static void
> > +print_double_int (pretty_printer *buffer, double_int cst)
> > +{
> > +  tree node = double_int_to_tree (integer_type_node, cst);
> > +  if (TREE_INT_CST_HIGH (node) == 0)
> > +pp_printf (buffer, HOST_WIDE_INT_PRINT_UNSIGNED, TREE_INT_CST_LOW
> > (node));
> > +  else if (TREE_INT_CST_HIGH (node) == -1
> > +   && TREE_INT_CST_LOW (node) != 0)
> > +pp_printf (buffer, "-" HOST_WIDE_INT_PRINT_UNSIGNED,
> > +   -TREE_INT_CST_LOW (node));
> > +  else
> > +sprintf (pp_buffer (buffer)->digit_buffer,
> > + HOST_WIDE_INT_PRINT_DOUBLE_HEX,
> > + (unsigned HOST_WIDE_INT) TREE_INT_CST_HIGH (node),
> > + (unsigned HOST_WIDE_INT) TREE_INT_CST_LOW (node));
> > 
> > using sprintf here looks like a layering violation to me.  You
> > probably want to factor out code from the INTEGER_CST handling
> > of tree-pretty-print.c:dump_generic_node into a pp_double_int
> > function in pretty-print.[ch] instead.
> > 
> > @@ -1628,6 +1647,27 @@ dump_gimple_phi (pretty_printer *buffer, gimple
> > phi, int spc, int flags)
> > pp_string (buffer, "# ");
> >   }
> > 
> > +  if ((flags & TDF_RANGE)
> > +  && !POINTER_TYPE_P (TREE_TYPE (lhs))
> > +  && SSA_NAME_RANGE_INFO (lhs))
> > +{
> > +  double_int min, max;
> > +  value_range_type range_type;
> > 
> > I realize the scheme is pre-existing but can you try factoring
> > out the dumping of SSA_NAME_PTR_INFO / SSA_NAME_RANGE_INFO into
> > a separate routine that can be shared by dump_gimple_phi and
> > pp_gimple_stmt_1?
> > 
> > +get_range_info (tree name, double_int &min, double_int &max,
> > +enum value_range_type &range_type)
> > +{
> > +  gcc_assert (!POINTER_TYPE_P (TREE_TYPE (name)));
> > +  gcc_assert (TREE_CODE (name) == SSA_NAME);
> > +  range_info_def *ri = SSA_NAME_RANGE_INFO (name);
> > 
> > the TREE_CODE (name) == SSA_NAME assert is redundant with the
> > tree-checking performed by SSA_NAME_RANGE_INFO.  Likewise in
> > the other functions.
> > 
> > +void
> > +get_range_info (tree name, double_int &min, double_int &max,
> > +enum value_range_type &range_type)
> > 
> > I'm not sure we want to use references.  Well - first time.
> > 
> > +  /* If min > max, it is  VR_ANTI_RANGE.  */
> > +  if (ri->min.scmp (ri->max) == 1)
> > +{
> > 
> > I think that's wrong and needs to be conditional on TYPE_UNSIGNED
> > of the SSA name.
> > 
> > +  else if (vr_value[i]->type == VR_ANTI_RANGE)
> > +{
> > +  /* VR_ANTI_RANGE ~[min, max] is encoded compactly as
> > + [max + 1, min - 1] without additional attributes.
> > + When min value > max value, we know that it is
> > + VR_ANTI_RANGE; it is VR_RANGE othewise.  */
> > +  set_range_info (name,
> > +  tree_to_double_int (vr_value[i]->max)
> > +  + double_int_one,
> > +  tree_to_double_int (vr_value[i]->min)
> > +  - double_int_one);
> > 
> > there is a complication for when max + 1 or min - 1 overflow - those
> > should be non-canonical ranges I think, but double-check this
> > (check set_and_canonicalize_value_range).
> > 
> I have now added a check for min == 0 for unsigned type. AFAIK, For double_int
> type, this is the only case we should check.
> 
> I have also made the other changes you have asked me to do. Please find the
> modified patch and ChangeLog.
> 
> Bootstrapped and regtested for x86_64-unknown-linux-gnu.  Is this OK.
> 
> Thanks,
> Kugan
> 
> 
> +2013-09-17  Kugan Vivekanandarajah  
> +
> + * gimple-pretty-print.c (dump_ssaname_info) : New function.
> + * gimple-pretty-print.c (dump_gimple_phi) : Dump range info.
> + * (pp_gimple_stmt_1) : Likewise.

ChangeLog should be formated

* gimple-pretty-print.c (dump_ssaname_info): New function.
(dump_gimple_phi): Call it.
(pp_gimple_stmt_1: Likewise.
* tree-pretty-print.c (dump_intger_cst_node): New function.
...


+pp_printf (buffer, "# RANGE ");
+pp_printf (buffer, "%s[", range_type == VR_RANG

Re: [ping][PATCH][1 of 2] Add value range info to SSA_NAME for zero sign extension elimination in RTL

[Richard Biener]

On Wed, 18 Sep 2013, Jan Hubicka wrote:

> > On Wed, Sep 18, 2013 at 10:57:57AM +0200, Richard Biener wrote:
> > > On Wed, 18 Sep 2013, Richard Earnshaw wrote:
> > > 
> > > > On 16/09/13 15:13, Richard Biener wrote:
> > > > > +void
> > > > > +get_range_info (tree name, double_int &min, double_int &max,
> > > > > +enum value_range_type &range_type)
> > > > > 
> > > > > I'm not sure we want to use references.  Well - first time.
> > > > 
> > > > Personally, I don't think we should ever allow non-const references.
> > > > Use of references means you can't tell from the source code that an
> > > > argument to a function can be modified.  It leads to confusion and makes
> > > > things harder to debug.
> 
> I use non-const references in ipa-devirt code and speculative indirect call 
> removal.
> I am not thrilled by them, just it seems common in C++ source bases.  If we 
> don't want
> them, i will remove these (they are used on two or three places, so it is  
> easy)

Yeah, I think we should amend the coding conventions appropriately.

Richard.

Re: [v3] More noexcept for lists

[Paolo Carlini]

Hi,

On 09/17/2013 08:44 PM, Marc Glisse wrote:

Hello,

after vectors, lists. I didn't touch the throw we were discussing 
earlier today for now. There will be an inconsistency with debug list 
iterators because they use a general wrapper:
- I would need François to tell if that wrapper is ever used with 
iterators that can throw,
- the same wrapper is used for several containers, so unless we change 
all containers at once it can't stay consistent.
Thus the idea is changing first all the containers and eventually go 
back to __gnu_debug::_Safe_iterator and consistently add the noexcepts 
there? Let's not forget that! (or alternately leave out all the 
iterators related bits for the time being ;)

Bootstrap+testsuite ok.

Patch is otherwise Ok with me, thanks.

Paolo.

RE: [PATCH 1/n] Add conditional compare support

[Zhenqiang Chen]

> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: Tuesday, August 27, 2013 8:18 PM
> To: Richard Earnshaw
> Cc: Zhenqiang Chen; GCC Patches
> Subject: Re: [PATCH 1/n] Add conditional compare support
> 
> On Tue, Aug 27, 2013 at 1:56 PM, Richard Earnshaw 
> wrote:
> > On 27/08/13 12:10, Richard Biener wrote:
> >> What's this for and what's the desired semantics? I don't like having
> >> extra tree codes for this.  Is this for a specific instruction set
> >> feature?
> >
> > The background is to support the conditional compare instructions in
> > ARM (more effectively) and AArch64 at all.
> >
> > The current method used in ARM is to expand into a series of
> > store-flag instructions and then hope that combine can optimize them
> > away (though that fails far too often, particularly when the first
> > instruction in the sequence is combined into another pattern).  To
> > make it work at all the compiler has to lie about the costs of various
> > store-flag type operations which overall risks producing worse code
> > and means we also have to support many more complex multi-instruction
> > patterns than is desirable.  I really don't want to go down the same
route
> for AArch64.
> >
> > The idea behind all this is to capture potential conditional compare
> > operations early enough in the mid end that we can keep track of them
> > until RTL expand time and then to emit the correct logic on all
> > targets depending on what is the best thing for that target.  The
> > current method of lowering into store-flag sequences doesn't really cut
it.
> 
> It seems to me that then the initial instruction selection process (aka
RTL
> expansion) needs to be improved.  As we are expanding with having the CFG
> around it should be easy enough to detect AND/ORIF cases and do better
> here.  Yeah, I suppose this asks to turn existing jump expansion
optimizations
> up-side-down to optimize with the GIMPLE CFG in mind.
> 
> The current way of LOGICAL_OP_NON_SHORT_CIRCUIT is certainly bogus -
> fold-const.c is way too early to decide this.  Similar to the ongoing work
of
> expanding / building-up switch expressions in a GIMPLE pass, moving expand
> complexity up the pipeline this asks for a GIMPLE phase that moves this
> decision down closer to RTL expansion.
> (We have tree-ssa-ifcombine.c that is a related GIMPLE transform pass)
>

The patch is updated according to your comments. It is a basic support,
which does not touch ifcombine and jump related optimizations yet.

Current method is:
1) In fold-const, if HAVE_conditional_compare, set
LOGICAL_OP_NON_SHORT_CIRCUIT
   to optimize_function_for_speed_p. So we do not depend on BRANCH_COST.
2) Identify CCMP during expanding. A CCMP candidate is a BIT_AND_EXPR
   or BIT_IOR_EXPR, whose operators are compares.
3) Add a new op in optab to expand the CCMP to optimized RTL,
e.g. and_scc_scc/ior_scc_scc in ARM.

Bootstrap on ARM Chrome book.
No make check regression on Pandaboard.

Thanks!
-Zhenqiang

ChangeLog:
2013-09-18  Zhenqiang Chen  

* config/arm/arm.md (conditional_compare): New.
* expr.c (is_conditional_compare_candidate_p, expand_ccmp_expr):
New.
(expand_expr_real_1): Identify conditional compare.
* fold-const.c (LOGICAL_OP_NON_SHORT_CIRCUIT): Update.
* optabs.c (expand_ccmp_op): New.
(get_rtx_code): Handle BIT_AND_EXPR and BIT_IOR_EXPR.
* optabs.def (ccmp_optab): New.
* optabs.h (expand_ccmp_op): New.

basic-conditional-compare-support2.patch
Description: Binary data

Re: [Patch, AArch64, ILP32] 1/5 Initial support - configury changes

[Andreas Schwab]

Yufeng Zhang  writes:

> (ASM_SPEC): Update to also substitute -mabi.

You should check that the assembler actually understands that option.
Currently it is impossible to build an aarch64-linux compiler with
binutils from the binutils-2_23 branch.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

[Ada] Fix bogus return value for function with In Out parameter

[Eric Botcazou]

This fixes an oversight in the recent implementation of functions with In Out 
parameters for Ada 2012, which leads to wrong code if the function contains a 
nested subprogram which also takes an In Out parameter with elementary type.

Tested on x86_64-suse-linux, applied on all active branches.


2013-09-18  Eric Botcazou  

* gcc-interface/trans.c (Subprogram_Body_to_gnu): Pop the stack of
return variables for subprograms using the CICO mechanism.


2013-09-18  Eric Botcazou  

* gnat.dg/in_out_parameter4.adb: New test.


-- 
Eric BotcazouIndex: gcc-interface/trans.c
===
--- gcc-interface/trans.c	(revision 202681)
+++ gcc-interface/trans.c	(working copy)
@@ -3605,6 +3605,8 @@ Subprogram_Body_to_gnu (Node_Id gnat_nod
 {
   tree gnu_retval;
 
+  gnu_return_var_stack->pop ();
+
   add_stmt (gnu_result);
   add_stmt (build1 (LABEL_EXPR, void_type_node,
 			gnu_return_label_stack->last ()));-- { dg-do run }
-- { dg-options "-gnat12 -gnatVa" }

procedure In_Out_Parameter4 is

   type Enum is (E_Undetermined, E_Down, E_Up);
   subtype Status_T is Enum range E_Down .. E_Up;

   function Recurse (Val : in out Integer) return Status_T is

 Result : Status_T;

 procedure Dummy (I : in out Integer) is begin null; end;

   begin
 if Val > 500 then
   Val := Val - 1;
   Result := Recurse (Val);
   return Result;
 else
   return E_UP;
 end if;
   end;

   Val : Integer := 501;
   S : Status_T;

begin
   S := Recurse (Val);
end;

Re: [PATCH v2 1/6] Convert symtab, cgraph and varpool nodes into a real class hierarchy

[Richard Biener]

On Wed, Sep 18, 2013 at 9:24 AM, Jan Hubicka  wrote:
>> > > +cgraph_node *cgn = static_cast  (x);
>> > > +gt_ggc_m_11cgraph_edge (cgn->callers);
>> > > +gt_ggc_m_11cgraph_node (cgn->origin);
>> > > +gt_ggc_m_11cgraph_node (cgn->nested);
>> > > +gt_ggc_m_11cgraph_node (cgn->next_nested);
>> > > +gt_ggc_m_11cgraph_node (cgn->next_sibling_clone);
>> > > +gt_ggc_m_11cgraph_node (cgn->prev_sibling_clone);
>> > > +gt_ggc_m_11cgraph_node (cgn->clones);
>> > > +gt_ggc_m_11cgraph_node (cgn->clone_of);
>> > Same as here.
>>
>> Sorry, it's not clear to me what you meant by "Same as here." here.  Do
>> you mean that I can skip marking them because they're within the symbol
>> table?   If so, are you referring to all 10 fields above ("callees"
>> through "clone_of")?
>
> All those pointers above points inside symbol table, so none of them needs
> to be marked.  Actually those two needs however, I missed them with prevoius
> reading:
>> > > +gt_ggc_m_11cgraph_edge (cgn->indirect_calls);
>> > > +gt_ggc_m_11cgraph_edge (cgn->callees);
>
> Otherwise edges will probably get lost.
>>
>>
>> >
>> > > +gt_ggc_m_P11cgraph_edge4htab (cgn->call_site_hash);
>> > Move call site hash out of GGC rather than introducing hack.
>>
>> I see that this is allocated in cgraph_edge (), and it appears to be an
>> index.  I can create it with htab_create rather than htab_create_ggc,
>> but if so, there doesn't seem a natural place to call htab_delete.  Is
>> that OK?
>
> Delete it in cgraph_remove_node.
>>
>>
>> > > +gt_ggc_m_9tree_node (cgn->former_clone_of);
>> > > +gt_ggc_m_11cgraph_node (cgn->global.inlined_to);
>> > And here
>>
>> Again, do you mean that "inlined_to" can be skipped since it's in the
>> symbol table?
>
> yes.
>> > > +cgraph_node *cgn = static_cast  (x);
>> > > +gt_pch_n_11cgraph_edge (cgn->callees);
>> > > +gt_pch_n_11cgraph_edge (cgn->callers);
>> > > +gt_pch_n_11cgraph_edge (cgn->indirect_calls);
>> > > +gt_pch_n_11cgraph_node (cgn->origin);
>> > > +gt_pch_n_11cgraph_node (cgn->nested);
>> > > +gt_pch_n_11cgraph_node (cgn->next_nested);
>> > > +gt_pch_n_11cgraph_node (cgn->next_sibling_clone);
>> > > +gt_pch_n_11cgraph_node (cgn->prev_sibling_clone);
>> > > +gt_pch_n_11cgraph_node (cgn->clones);
>> > > +gt_pch_n_11cgraph_node (cgn->clone_of);
>> > > +gt_pch_n_P11cgraph_edge4htab (cgn->call_site_hash);
>> > > +gt_pch_n_9tree_node (cgn->former_clone_of);
>> > > +gt_pch_n_11cgraph_node (cgn->global.inlined_to);
>> > > +gt_pch_n_28vec_ipa_replace_map_p_va_gc_ 
>> > > (cgn->clone.tree_map);
>> > > +gt_pch_n_15bitmap_head_def (cgn->clone.args_to_skip);
>> > > +gt_pch_n_15bitmap_head_def 
>> > > (cgn->clone.combined_args_to_skip);
>> > > +gt_pch_n_9tree_node (cgn->thunk.alias);
>> >
>> > We can skip good part of those. Just small of those is build at PCH time. 
>> > But lets do that incrementally, PCH is touchy business.
>>
>> OK.  I'll just make analogous changes here to those made to the
>> gt_ggc_mx function.
>
> I think some of the pointers that do not need to be marked still needs to be
> streamed and fixed by PCH, so we probably want to keep them.  All the cloning
> pointers above are not live at PCH time (they are always NULL).  Only reason
> why PCH lives at that point is that C++ FE produces Cgraph nodes early for
> funny reason. The nodes are not analyzed at that point and call edges do not
> exist (if I recall right) Probably I can do this incrementally - we do not 
> want
> to break PCH with a large patch and then spend weeks analyzing it.  That 
> things
> can bite ;)

Debugging omissions / errors in manually written markers will indeed be a
PITA :/

Richard.

> Honza

Re: [PING][PATCH] ICE with combination of -fopenmp and -femit-struct-debug-reduced/baseonly

[Kyrill Tkachov]

Hi Cary, Evgeny
On 13/09/13 23:38, Cary Coutant wrote:

I’ve attached fix for this issue:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57737
There are fix, two tests and change log message.

Is it ok?

Cary, can you commit it for me?

Ping this patch, http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00053.html

Thanks for the fix, and sorry for the delay! I've committed it for you
at r202582.

The tests should be guarded to not run on targets
 that don't support openmp, such as bare metal targets.

This patch adds an effective target check for openmp.

Ok to apply?

Thanks,
Kyrill



-cary


2013-09-13  Evgeny Gavrin 

gcc/
 * dwarf2out.c (should_emit_struct_debug): Add check
 for type_decl variable is not NULL.

gcc/testsuite
 * gcc.dg/debug/dwarf2/omp-fesdr.c: Add test.
 * g++.dg/debug/dwarf2/omp-fesdr.C: Add test.

diff --git a/gcc/testsuite/g++.dg/debug/dwarf2/omp-fesdr.C b/gcc/testsuite/g++.dg/debug/dwarf2/omp-fesdr.C
index 005acdf..b3b65e9 100644
--- a/gcc/testsuite/g++.dg/debug/dwarf2/omp-fesdr.C
+++ b/gcc/testsuite/g++.dg/debug/dwarf2/omp-fesdr.C
@@ -1,4 +1,5 @@
 /* { dg-do compile } */
+/* { dg-require-effective-target fopenmp } */
 /* { dg-options "-g -fopenmp -gdwarf-2 -femit-struct-debug-reduced" } */
 
 struct aa
diff --git a/gcc/testsuite/gcc.dg/debug/dwarf2/omp-fesdr.c b/gcc/testsuite/gcc.dg/debug/dwarf2/omp-fesdr.c
index 005acdf..d7b0319 100644
--- a/gcc/testsuite/gcc.dg/debug/dwarf2/omp-fesdr.c
+++ b/gcc/testsuite/gcc.dg/debug/dwarf2/omp-fesdr.c
@@ -1,4 +1,5 @@
 /* { dg-do compile } */
+/* { dg-require-effective-target fopenmp }  */
 /* { dg-options "-g -fopenmp -gdwarf-2 -femit-struct-debug-reduced" } */
 
 struct aa

[Ada] Fix crash in ASIS mode

[Eric Botcazou]

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


2013-09-18  Eric Botcazou  

* gcc-interface/decl.c (gnat_to_gnu_entity) : New.


-- 
Eric BotcazouIndex: gcc-interface/decl.c
===
--- gcc-interface/decl.c	(revision 202681)
+++ gcc-interface/decl.c	(working copy)
@@ -4812,6 +4812,12 @@ gnat_to_gnu_entity (Entity_Id gnat_entit
   saved = true;
   break;
 
+case E_Abstract_State:
+  /* This is a SPARK annotation that only reaches here when compiling in
+	 ASIS mode and has no characteristics to annotate.  */
+  gcc_assert (type_annotate_only);
+  return error_mark_node;
+
 default:
   gcc_unreachable ();
 }

Re: [Patch, AArch64, ILP32] 1/5 Initial support - configury changes

[Yufeng Zhang]

On 09/18/13 11:21, Andreas Schwab wrote:

Yufeng Zhang  writes:


 (ASM_SPEC): Update to also substitute -mabi.


You should check that the assembler actually understands that option.
Currently it is impossible to build an aarch64-linux compiler with
binutils from the binutils-2_23 branch.


Ah, I didn't think too much at then on the backward compatibility issue 
with binutils-2_23.  One potential solution can be to backport part of 
configury change from binutils trunk to 2_23.  Can I ask if there is any 
particular reason that you wouldn't like to build the trunk compiler 
with the trunk binutils?  Also since binutils 2.24 release shall not be 
far away, would you be happy to wait for that instead?


Thanks,
Yufeng

Re: [PING][PATCH] ICE with combination of -fopenmp and -femit-struct-debug-reduced/baseonly

[Jakub Jelinek]

On Wed, Sep 18, 2013 at 11:34:23AM +0100, Kyrill Tkachov wrote:
> Hi Cary, Evgeny
> On 13/09/13 23:38, Cary Coutant wrote:
> >>I’ve attached fix for this issue:
> >>http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57737
> >>There are fix, two tests and change log message.
> >>
> >>Is it ok?
> >>
> >>Cary, can you commit it for me?
> >>
> >>Ping this patch, http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00053.html
> >Thanks for the fix, and sorry for the delay! I've committed it for you
> >at r202582.
> The tests should be guarded to not run on targets
>  that don't support openmp, such as bare metal targets.
> 
> This patch adds an effective target check for openmp.
> 
> Ok to apply?

Yes, with appropriate ChangeLog entry.

> --- a/gcc/testsuite/g++.dg/debug/dwarf2/omp-fesdr.C
> +++ b/gcc/testsuite/g++.dg/debug/dwarf2/omp-fesdr.C
> @@ -1,4 +1,5 @@
>  /* { dg-do compile } */
> +/* { dg-require-effective-target fopenmp } */
>  /* { dg-options "-g -fopenmp -gdwarf-2 -femit-struct-debug-reduced" } */
>  
>  struct aa
> diff --git a/gcc/testsuite/gcc.dg/debug/dwarf2/omp-fesdr.c 
> b/gcc/testsuite/gcc.dg/debug/dwarf2/omp-fesdr.c
> index 005acdf..d7b0319 100644
> --- a/gcc/testsuite/gcc.dg/debug/dwarf2/omp-fesdr.c
> +++ b/gcc/testsuite/gcc.dg/debug/dwarf2/omp-fesdr.c
> @@ -1,4 +1,5 @@
>  /* { dg-do compile } */
> +/* { dg-require-effective-target fopenmp }  */
>  /* { dg-options "-g -fopenmp -gdwarf-2 -femit-struct-debug-reduced" } */
>  
>  struct aa

Jakub

[gomp4, committed] Fix a merge glitch

[Jakub Jelinek]

Hi!

I've merged again trunk into gomp-4_0-branch, but have noticed
that in the earlier merge I've added the #defines together with
the corresponding structures/enums into tree-core.h, when apparently
the defines belong into tree.h.

2013-09-18  Jakub Jelinek  

* tree-core.h (OMP_CLAUSE_DEPEND_KIND, OMP_CLAUSE_MAP_KIND,
OMP_CLAUSE_MAP_ZERO_BIAS_ARRAY_SECTION, OMP_CLAUSE_PROC_BIND_KIND):
Move definitions...
* tree.h (OMP_CLAUSE_DEPEND_KIND, OMP_CLAUSE_MAP_KIND,
OMP_CLAUSE_MAP_ZERO_BIAS_ARRAY_SECTION, OMP_CLAUSE_PROC_BIND_KIND):
... here.

--- gcc/tree-core.h.jj  2013-09-16 15:53:39.0 +0200
+++ gcc/tree-core.h 2013-09-16 16:03:12.526490432 +0200
@@ -1083,9 +1083,6 @@ enum omp_clause_depend_kind
   OMP_CLAUSE_DEPEND_INOUT
 };
 
-#define OMP_CLAUSE_DEPEND_KIND(NODE) \
-  (OMP_CLAUSE_SUBCODE_CHECK (NODE, 
OMP_CLAUSE_DEPEND)->omp_clause.subcode.depend_kind)
-
 enum omp_clause_map_kind
 {
   OMP_CLAUSE_MAP_ALLOC,
@@ -1098,15 +1095,6 @@ enum omp_clause_map_kind
   OMP_CLAUSE_MAP_POINTER
 };
 
-#define OMP_CLAUSE_MAP_KIND(NODE) \
-  (OMP_CLAUSE_SUBCODE_CHECK (NODE, 
OMP_CLAUSE_MAP)->omp_clause.subcode.map_kind)
-
-/* Nonzero if this map clause is for array (rather than pointer) based array
-   section with zero bias.  Both the non-decl OMP_CLAUSE_MAP and
-   correspoidng OMP_CLAUSE_MAP_POINTER clause are marked with this flag.  */
-#define OMP_CLAUSE_MAP_ZERO_BIAS_ARRAY_SECTION(NODE) \
-  (OMP_CLAUSE_SUBCODE_CHECK (NODE, OMP_CLAUSE_MAP)->base.public_flag)
-
 enum omp_clause_proc_bind_kind
 {
   /* Numbers should match omp_proc_bind_t enum in omp.h.  */
@@ -1117,9 +1105,6 @@ enum omp_clause_proc_bind_kind
   OMP_CLAUSE_PROC_BIND_SPREAD = 4
 };
 
-#define OMP_CLAUSE_PROC_BIND_KIND(NODE) \
-  (OMP_CLAUSE_SUBCODE_CHECK (NODE, 
OMP_CLAUSE_PROC_BIND)->omp_clause.subcode.proc_bind_kind)
-
 struct GTY(()) tree_exp {
   struct tree_typed typed;
   location_t locus;
--- gcc/tree.h.jj   2013-09-16 15:52:31.0 +0200
+++ gcc/tree.h  2013-09-16 16:08:22.134892606 +0200
@@ -1266,6 +1266,21 @@ extern void protected_set_expr_location
 #define OMP_CLAUSE_SCHEDULE_CHUNK_EXPR(NODE) \
   OMP_CLAUSE_OPERAND (OMP_CLAUSE_SUBCODE_CHECK (NODE, OMP_CLAUSE_SCHEDULE), 0)
 
+#define OMP_CLAUSE_DEPEND_KIND(NODE) \
+  (OMP_CLAUSE_SUBCODE_CHECK (NODE, 
OMP_CLAUSE_DEPEND)->omp_clause.subcode.depend_kind)
+
+#define OMP_CLAUSE_MAP_KIND(NODE) \
+  (OMP_CLAUSE_SUBCODE_CHECK (NODE, 
OMP_CLAUSE_MAP)->omp_clause.subcode.map_kind)
+
+/* Nonzero if this map clause is for array (rather than pointer) based array
+   section with zero bias.  Both the non-decl OMP_CLAUSE_MAP and
+   correspoidng OMP_CLAUSE_MAP_POINTER clause are marked with this flag.  */
+#define OMP_CLAUSE_MAP_ZERO_BIAS_ARRAY_SECTION(NODE) \
+  (OMP_CLAUSE_SUBCODE_CHECK (NODE, OMP_CLAUSE_MAP)->base.public_flag)
+
+#define OMP_CLAUSE_PROC_BIND_KIND(NODE) \
+  (OMP_CLAUSE_SUBCODE_CHECK (NODE, 
OMP_CLAUSE_PROC_BIND)->omp_clause.subcode.proc_bind_kind)
+
 #define OMP_CLAUSE_COLLAPSE_EXPR(NODE) \
   OMP_CLAUSE_OPERAND (OMP_CLAUSE_SUBCODE_CHECK (NODE, OMP_CLAUSE_COLLAPSE), 0)
 #define OMP_CLAUSE_COLLAPSE_ITERVAR(NODE) \


Jakub

Re: [PATCH 1/n] Add conditional compare support

[Richard Biener]

On Wed, Sep 18, 2013 at 11:45 AM, Zhenqiang Chen  wrote:
>
>> -Original Message-
>> From: Richard Biener [mailto:richard.guent...@gmail.com]
>> Sent: Tuesday, August 27, 2013 8:18 PM
>> To: Richard Earnshaw
>> Cc: Zhenqiang Chen; GCC Patches
>> Subject: Re: [PATCH 1/n] Add conditional compare support
>>
>> On Tue, Aug 27, 2013 at 1:56 PM, Richard Earnshaw 
>> wrote:
>> > On 27/08/13 12:10, Richard Biener wrote:
>> >> What's this for and what's the desired semantics? I don't like having
>> >> extra tree codes for this.  Is this for a specific instruction set
>> >> feature?
>> >
>> > The background is to support the conditional compare instructions in
>> > ARM (more effectively) and AArch64 at all.
>> >
>> > The current method used in ARM is to expand into a series of
>> > store-flag instructions and then hope that combine can optimize them
>> > away (though that fails far too often, particularly when the first
>> > instruction in the sequence is combined into another pattern).  To
>> > make it work at all the compiler has to lie about the costs of various
>> > store-flag type operations which overall risks producing worse code
>> > and means we also have to support many more complex multi-instruction
>> > patterns than is desirable.  I really don't want to go down the same
> route
>> for AArch64.
>> >
>> > The idea behind all this is to capture potential conditional compare
>> > operations early enough in the mid end that we can keep track of them
>> > until RTL expand time and then to emit the correct logic on all
>> > targets depending on what is the best thing for that target.  The
>> > current method of lowering into store-flag sequences doesn't really cut
> it.
>>
>> It seems to me that then the initial instruction selection process (aka
> RTL
>> expansion) needs to be improved.  As we are expanding with having the CFG
>> around it should be easy enough to detect AND/ORIF cases and do better
>> here.  Yeah, I suppose this asks to turn existing jump expansion
> optimizations
>> up-side-down to optimize with the GIMPLE CFG in mind.
>>
>> The current way of LOGICAL_OP_NON_SHORT_CIRCUIT is certainly bogus -
>> fold-const.c is way too early to decide this.  Similar to the ongoing work
> of
>> expanding / building-up switch expressions in a GIMPLE pass, moving expand
>> complexity up the pipeline this asks for a GIMPLE phase that moves this
>> decision down closer to RTL expansion.
>> (We have tree-ssa-ifcombine.c that is a related GIMPLE transform pass)
>>
>
> The patch is updated according to your comments. It is a basic support,
> which does not touch ifcombine and jump related optimizations yet.
>
> Current method is:
> 1) In fold-const, if HAVE_conditional_compare, set
> LOGICAL_OP_NON_SHORT_CIRCUIT
>to optimize_function_for_speed_p. So we do not depend on BRANCH_COST.
> 2) Identify CCMP during expanding. A CCMP candidate is a BIT_AND_EXPR
>or BIT_IOR_EXPR, whose operators are compares.
> 3) Add a new op in optab to expand the CCMP to optimized RTL,
> e.g. and_scc_scc/ior_scc_scc in ARM.
>
> Bootstrap on ARM Chrome book.
> No make check regression on Pandaboard.

That's better.  A few observations

+static bool
+is_conditional_compare_candidate_p (gimple g)
+{
+  tree rhs = gimple_assign_rhs_to_tree (g);
+  tree lhs, op0, op1;
+  gimple gs0, gs1;
+
+  if (TREE_CODE (rhs) != BIT_AND_EXPR && TREE_CODE (rhs) != BIT_IOR_EXPR)
+return false;
+
+  lhs = gimple_assign_lhs (g);
+  op0 = TREE_OPERAND (rhs, 0);
+  op1 = TREE_OPERAND (rhs, 1);
+
+  if ((TREE_CODE (op0) != SSA_NAME) || (TREE_CODE (op1) != SSA_NAME)
+  || !has_single_use (lhs))
+return false;
+
+  gs0 = SSA_NAME_DEF_STMT (op0);
+  gs1 = SSA_NAME_DEF_STMT (op1);

you are not allowed to use arbitrary definition stmts for code generation (you
may have a look at them though).  Use the get_gimple_for_ssa_name helper
to only access definition stmts that have no code generated yet and that
you can modify.

+  gimple gs0 = SSA_NAME_DEF_STMT (TREE_OPERAND (exp, 0));
+  gimple gs1 = SSA_NAME_DEF_STMT (TREE_OPERAND (exp, 1));

See above.

+  if (INTEGRAL_TYPE_P (TREE_TYPE (gimple_assign_rhs1 (gs0)))
+  && INTEGRAL_TYPE_P (TREE_TYPE (gimple_assign_rhs1 (gs1
+{
+  rtx op0, op1, op2, op3, tmp;
+  tree cmp0_op0, cmp0_op1, cmp1_op0, cmp1_op1;
+  enum machine_mode mode;
+
+  cmp0_op0 = gimple_assign_rhs1 (gs0);
+  cmp0_op1 = gimple_assign_rhs2 (gs0);
+  cmp1_op0 = gimple_assign_rhs1 (gs1);
+  cmp1_op1 = gimple_assign_rhs2 (gs1);
+
+  expand_operands (cmp0_op0, cmp0_op1, NULL_RTX, &op0, &op1,
EXPAND_NORMAL);
+  expand_operands (cmp1_op0, cmp1_op1, NULL_RTX, &op2, &op3,
EXPAND_NORMAL);

as you are not expanding the result of gs0 or gs1 you indeed have to
use get_gimple_for_ssa_name.

+ else
+   r = expand_expr_real (rhs, target, tmode, modifier, NULL);
+#else
+ r = expand_expr_real (rhs, target, tmode, modifier, NULL);
+#endif

just place the #else after the else, n

Re: [v3] More noexcept for lists

[Marc Glisse]

On Wed, 18 Sep 2013, Paolo Carlini wrote:

On 09/17/2013 08:44 PM, Marc Glisse wrote:
after vectors, lists. I didn't touch the throw we were discussing earlier 
today for now. There will be an inconsistency with debug list iterators 
because they use a general wrapper:
- I would need François to tell if that wrapper is ever used with iterators 
that can throw,
- the same wrapper is used for several containers, so unless we change all 
containers at once it can't stay consistent.
Thus the idea is changing first all the containers and eventually go back to 
__gnu_debug::_Safe_iterator and consistently add the noexcepts there?


Yes.

Let's not forget that! (or alternately leave out all the iterators 
related bits for the time being ;)


That would mean one mega-patch doing all the iterators at once :-(


Patch is otherwise Ok with me, thanks.


Ok, I'll commit it now and move to other containers.

--
Marc Glisse

[Ada] Fix PR ada/58264

[Eric Botcazou]

This fixes the incorrect computation of the bounds of an object with 
unconstrained array nominal subtype, which is initialized by the dereference 
of an access value obtained as the result of a function call.

Tested on x86_64-suse-linux, applied on the mainline and 4.8 branch.


2013-09-18  Eric Botcazou  

PR ada/58264
* gcc-interface/trans.c (Attribute_to_gnu): Define GNAT_PREFIX local
variable and use it throughout.
: Note whether the prefix is the dereference of a pointer
to unconstrained array and, in this case, capture the result for both
Attr_First and Attr_Last.


2013-09-18  Eric Botcazou  

*  gnat.dg/array_bounds_test2.adb: New test.


-- 
Eric BotcazouIndex: gcc-interface/trans.c
===
--- gcc-interface/trans.c	(revision 202688)
+++ gcc-interface/trans.c	(working copy)
@@ -1391,6 +1391,7 @@ Pragma_to_gnu (Node_Id gnat_node)
 static tree
 Attribute_to_gnu (Node_Id gnat_node, tree *gnu_result_type_p, int attribute)
 {
+  const Node_Id gnat_prefix = Prefix (gnat_node);
   tree gnu_prefix, gnu_type, gnu_expr;
   tree gnu_result_type, gnu_result = error_mark_node;
   bool prefix_unused = false;
@@ -1400,13 +1401,13 @@ Attribute_to_gnu (Node_Id gnat_node, tre
  parameter types might be incomplete types coming from a limited with.  */
   if (Ekind (Etype (gnat_node)) == E_Access_Subprogram_Type
   && Is_Dispatch_Table_Entity (Etype (gnat_node))
-  && Nkind (Prefix (gnat_node)) == N_Identifier
-  && Is_Subprogram (Entity (Prefix (gnat_node)))
-  && Is_Public (Entity (Prefix (gnat_node)))
-  && !present_gnu_tree (Entity (Prefix (gnat_node
-gnu_prefix = get_minimal_subprog_decl (Entity (Prefix (gnat_node)));
+  && Nkind (gnat_prefix) == N_Identifier
+  && Is_Subprogram (Entity (gnat_prefix))
+  && Is_Public (Entity (gnat_prefix))
+  && !present_gnu_tree (Entity (gnat_prefix)))
+gnu_prefix = get_minimal_subprog_decl (Entity (gnat_prefix));
   else
-gnu_prefix = gnat_to_gnu (Prefix (gnat_node));
+gnu_prefix = gnat_to_gnu (gnat_prefix);
   gnu_type = TREE_TYPE (gnu_prefix);
 
   /* If the input is a NULL_EXPR, make a new one.  */
@@ -1549,8 +1550,8 @@ Attribute_to_gnu (Node_Id gnat_node, tre
 	 since it can use a special calling convention on some platforms,
 	 which cannot be propagated to the access type.  */
   else if (attribute == Attr_Access
-	   && Nkind (Prefix (gnat_node)) == N_Identifier
-	   && is_cplusplus_method (Entity (Prefix (gnat_node
+	   && Nkind (gnat_prefix) == N_Identifier
+	   && is_cplusplus_method (Entity (gnat_prefix)))
 	post_error ("access to C++ constructor or member function not allowed",
 		gnat_node);
 
@@ -1661,13 +1662,12 @@ Attribute_to_gnu (Node_Id gnat_node, tre
 	  /* If this is a dereference and we have a special dynamic constrained
 	 subtype on the prefix, use it to compute the size; otherwise, use
 	 the designated subtype.  */
-	  if (Nkind (Prefix (gnat_node)) == N_Explicit_Dereference)
+	  if (Nkind (gnat_prefix) == N_Explicit_Dereference)
 	{
-	  Node_Id gnat_deref = Prefix (gnat_node);
 	  Node_Id gnat_actual_subtype
-		= Actual_Designated_Subtype (gnat_deref);
+		= Actual_Designated_Subtype (gnat_prefix);
 	  tree gnu_ptr_type
-		= TREE_TYPE (gnat_to_gnu (Prefix (gnat_deref)));
+		= TREE_TYPE (gnat_to_gnu (Prefix (gnat_prefix)));
 
 	  if (TYPE_IS_FAT_OR_THIN_POINTER_P (gnu_ptr_type)
 		  && Present (gnat_actual_subtype))
@@ -1728,7 +1728,6 @@ Attribute_to_gnu (Node_Id gnat_node, tre
 	  align = DECL_ALIGN (TREE_OPERAND (gnu_prefix, 1)) / BITS_PER_UNIT;
 	else
 	  {
-	Node_Id gnat_prefix = Prefix (gnat_node);
 	Entity_Id gnat_type = Etype (gnat_prefix);
 	unsigned int double_align;
 	bool is_capped_double, align_clause;
@@ -1800,28 +1799,38 @@ Attribute_to_gnu (Node_Id gnat_node, tre
 			 : 1), i;
 	struct parm_attr_d *pa = NULL;
 	Entity_Id gnat_param = Empty;
+	bool unconstrained_ptr_deref = false;
 
 	/* Make sure any implicit dereference gets done.  */
 	gnu_prefix = maybe_implicit_deref (gnu_prefix);
 	gnu_prefix = maybe_unconstrained_array (gnu_prefix);
 
-	/* We treat unconstrained array In parameters specially.  */
-	if (!Is_Constrained (Etype (Prefix (gnat_node
-	  {
-	Node_Id gnat_prefix = Prefix (gnat_node);
+	/* We treat unconstrained array In parameters specially.  We also note
+	   whether we are dereferencing a pointer to unconstrained array.  */
+	if (!Is_Constrained (Etype (gnat_prefix)))
+	  switch (Nkind (gnat_prefix))
+	{
+	case N_Identifier:
+	  /* This is the direct case.  */
+	  if (Ekind (Entity (gnat_prefix)) == E_In_Parameter)
+		gnat_param = Entity (gnat_prefix);
+	  break;
+
+	case N_Explicit_Dereference:
+	  /* This is the indirect case.  Note that we need to be sure that
+		 the access value cannot be null as we'll hoist the load.  */
+	  if (N

[C++ doc patch, trivial] PR 58458

[Paolo Carlini]

Hi,

committed to mainline/4_8/4_7.

Thanks,
Paolo.

/
2013-09-18  Daniel Morris  
Paolo Carlini  

PR c++/58458
* doc/implement-cxx.texi: Fix references to the C++ standards.
Index: doc/implement-cxx.texi
===
--- doc/implement-cxx.texi  (revision 202668)
+++ doc/implement-cxx.texi  (working copy)
@@ -9,8 +9,8 @@
 A conforming implementation of ISO C++ is required to document its
 choice of behavior in each of the areas that are designated
 ``implementation defined''.  The following lists all such areas,
-along with the section numbers from the ISO/IEC 14822:1998 and ISO/IEC
-14822:2003 standards.  Some areas are only implementation-defined in
+along with the section numbers from the ISO/IEC 14882:1998 and ISO/IEC
+14882:2003 standards.  Some areas are only implementation-defined in
 one version of the standard.
 
 Some choices depend on the externally determined ABI for the platform

Re: [wide-int] Fix mode choice in convert_modes

[Kenneth Zadeck]

this is fine with me.

kenny

On 09/18/2013 03:27 AM, Richard Sandiford wrote:

Ping

Richard Sandiford  writes:

Enabling the CONST_INT assert showed that this branch-local code was
passing the wrong mode to std::make_pair.  The mode of X is OLDMODE,
and we're supposed to be converting it to MODE.

In the case where OLDMODE is VOIDmode, I think we have to assume
that every bit of the input is significant.

Tested on x86_64-linux-gnu.  OK to install?

This and the other patches that I just committed to trunk are enough
for a bootstrap and regression test to pass on x86_64-linux-gnu with
the assertion for a canonical CONST_INT enabled.  I think it would be
better to leave the assertion out until after the merge though,
so we can deal with any fallout separately.

Thanks,
Richard


Index: gcc/expr.c
===
--- gcc/expr.c  2013-09-09 11:32:33.734617409 +0100
+++ gcc/expr.c  2013-09-09 11:45:27.381001353 +0100
@@ -714,13 +714,14 @@ convert_modes (enum machine_mode mode, e
&& GET_MODE_CLASS (mode) == MODE_INT
&& (oldmode == VOIDmode || GET_MODE_CLASS (oldmode) == MODE_INT))
  {
-  wide_int w = std::make_pair (x, mode);
/* If the caller did not tell us the old mode, then there is
-not much to do with respect to canonization.  */
-  if (oldmode != VOIDmode
- && GET_MODE_PRECISION (mode) > GET_MODE_PRECISION (oldmode))
-   w = wi::ext (w, GET_MODE_PRECISION (oldmode),
-unsignedp ? UNSIGNED : SIGNED);
+not much to do with respect to canonization.  We have to assume
+that all the bits are significant.  */
+  if (oldmode == VOIDmode)
+   oldmode = MAX_MODE_INT;
+  wide_int w = wide_int::from (std::make_pair (x, oldmode),
+  GET_MODE_PRECISION (mode),
+  unsignedp ? UNSIGNED : SIGNED);
return immed_wide_int_const (w, mode);
  }
  

[patch] Fix ICE in insert_clobber_before_stack_restore

[Eric Botcazou]

Hi,

this is a regression present on mainline and 4.8 branch (and latent on the 4.7 
branch), which is visible with the attached Ada testcase for targets using the 
SJLJ exception scheme:

eric@polaris:~/gnat/bugs/M823-029> ~/build/gcc-4_8-branch/native/gcc/gnat1 -
quiet p.adb -O2
+===GNAT BUG DETECTED==+
| 4.8.2 20130916 (prerelease) [gcc-4_8-branch revision 202625] (x86_64-suse-
linux) GCC error:|
| in insert_clobber_before_stack_restore, at tree-ssa-ccp.c:1711   |
| Error detected around p.adb:5:3

The problem is that insert_clobber_before_stack_restore recurses on PHI nodes, 
but stops on copy assignment statements, which appears to be just an oversight 
in this new function.  The SSA_NAMEs have SSA_NAME_OCCURS_IN_ABNORMAL_PHI here 
(because of the SJLJ exception scheme), which very likely explains the copy 
assignment statement.

Tested on x86_64-suse-linux, OK for mainline and 4.8 branch?  What about the 
4.7 branch?


2013-09-18  Eric Botcazou  

* tree-ssa-ccp.c (insert_clobber_before_stack_restore): Recurse on copy
assignment statements.


2013-09-18  Eric Botcazou  

* gnat.dg/opt28.ad[sb]: New test.
* gnat.dg/opt28_pkg.ads: New helper.


-- 
Eric BotcazouIndex: tree-ssa-ccp.c
===
--- tree-ssa-ccp.c	(revision 202588)
+++ tree-ssa-ccp.c	(working copy)
@@ -1728,6 +1728,9 @@ insert_clobber_before_stack_restore (tre
 	insert_clobber_before_stack_restore (gimple_phi_result (stmt), var,
 	 visited);
   }
+else if (gimple_assign_ssa_name_copy_p (stmt))
+  insert_clobber_before_stack_restore (gimple_assign_lhs (stmt), var,
+	   visited);
 else
   gcc_assert (is_gimple_debug (stmt));
 }
with Opt28_Pkg; use Opt28_Pkg;

package body Opt28 is

  function Full_Filename (Filename : String) return String is
Path : constant String := "PATH";
Posix_Path : constant Posix_String := To_Posix (Path);
  begin

declare
  M : constant Posix_String := Value_Of (Posix_Path);
  N : constant Posix_String (1 .. M'Length) := M;
  Var : constant String := To_String (Str => N);
  Start_Pos : Natural := 1;
  End_Pos   : Natural := 1;
begin
  while Start_Pos <= Var'Length loop
End_Pos := Position (Var (Start_Pos .. Var'Length));

if Is_File (To_Posix (Var (Start_Pos .. End_Pos - 1) & Filename)) then
  return Var (Start_Pos .. End_Pos - 1) & Filename;
else
  Start_Pos := End_Pos + 1;
end if;
  end loop;
end;

return "";
  end;

end Opt28;
-- { dg-do compile }
-- { dg-options "-O2" }

package Opt28 is

  function Full_Filename (Filename : String) return String;

end Opt28;
package Opt28_Pkg is

  type Posix_String is array (Positive range <>) of aliased Character;

  function To_Posix (Str : String) return Posix_String;
  function To_String (Str : Posix_String) return String;
  function Is_File (Str : Posix_String) return Boolean;
  function Value_Of (Name : Posix_String) return Posix_String;
  function Position (In_Line : String) return Natural;

end Opt28_Pkg;

[gomp4] C UDR support

[Jakub Jelinek]

Hi!

This is the C FE counterpart of the C++ FE OpenMP 4.0 user defined
reductions, as C has no templates, class inheritance, doesn't
allow #pragma omp declare reduction in structs/unions, the implementation is
significantly simpler.

Joseph, any comments on this?

2013-09-18  Jakub Jelinek  

* c-tree.h (c_omp_reduction_id, c_omp_reduction_decl,
c_omp_reduction_lookup, c_check_omp_declare_reduction_r): New
prototypes.
* c-typeck.c: Include tree-inline.h.
(c_clone_udr, c_find_omp_placeholder_r): New functions.
(c_finish_omp_clauses): Handle user defined reductions.
* Make-lang.in (c-typeck.o): Depend on $(TREE_INLINE_H).
* c-parser.c (c_parser_omp_clause_reduction): Handle user
defined reductions.
(c_parser_omp_declare_reduction): New function.
(c_parser_omp_declare): Call it.
* c-decl.c (c_omp_reduction_id, c_omp_reduction_decl,
c_omp_reduction_lookup, c_check_omp_declare_reduction_r): New
functions.
gcc/testsuite/
* gcc.dg/gomp/udr-1.c: New test.
* gcc.dg/gomp/udr-2.c: New test.
* gcc.dg/gomp/udr-3.c: New test.
* gcc.dg/gomp/udr-4.c: New test.
* gcc.dg/gomp/clause-1.c: Adjust error messages.
libgomp/
* testsuite/libgomp.c/simd-4.c: New test.
* testsuite/libgomp.c/simd-5.c: New test.
* testsuite/libgomp.c/udr-1.c: New test.
* testsuite/libgomp.c/udr-2.c: New test.
* testsuite/libgomp.c/udr-3.c: New test.
* testsuite/libgomp.c++/udr-9.C: New test.

--- gcc/c/c-tree.h.jj   2013-09-18 12:06:04.051769378 +0200
+++ gcc/c/c-tree.h  2013-09-18 13:07:50.792969161 +0200
@@ -670,6 +670,10 @@ extern enum machine_mode c_default_point
 /* In c-decl.c */
 extern void c_finish_incomplete_decl (tree);
 extern void c_write_global_declarations (void);
+extern tree c_omp_reduction_id (enum tree_code, tree);
+extern tree c_omp_reduction_decl (tree);
+extern tree c_omp_reduction_lookup (tree, tree);
+extern tree c_check_omp_declare_reduction_r (tree *, int *, void *);
 
 /* In c-errors.c */
 extern void pedwarn_c90 (location_t, int opt, const char *, ...) 
ATTRIBUTE_GCC_DIAG(3,4);
--- gcc/c/c-typeck.c.jj 2013-09-18 12:17:36.814044593 +0200
+++ gcc/c/c-typeck.c2013-09-18 13:07:50.795968751 +0200
@@ -37,6 +37,7 @@ along with GCC; see the file COPYING3.
 #include "tree-iterator.h"
 #include "bitmap.h"
 #include "gimple.h"
+#include "tree-inline.h"
 #include "c-family/c-objc.h"
 #include "c-family/c-common.h"
 #include "c-family/c-ubsan.h"
@@ -11209,6 +11210,48 @@ handle_omp_array_sections (tree c)
   return false;
 }
 
+/* Helper function of finish_omp_clauses.  Clone STMT as if we were making
+   an inline call.  But, remap
+   the OMP_DECL1 VAR_DECL (omp_out resp. omp_orig) to PLACEHOLDER
+   and OMP_DECL2 VAR_DECL (omp_in resp. omp_priv) to DECL.  */
+
+static tree
+c_clone_omp_udr (tree stmt, tree omp_decl1, tree omp_decl2,
+tree decl, tree placeholder)
+{
+  copy_body_data id;
+  struct pointer_map_t *decl_map = pointer_map_create ();
+
+  *pointer_map_insert (decl_map, omp_decl1) = placeholder;
+  *pointer_map_insert (decl_map, omp_decl2) = decl;
+  memset (&id, 0, sizeof (id));
+  id.src_fn = DECL_CONTEXT (omp_decl1);
+  id.dst_fn = current_function_decl;
+  id.src_cfun = DECL_STRUCT_FUNCTION (id.src_fn);
+  id.decl_map = decl_map;
+
+  id.copy_decl = copy_decl_no_change;
+  id.transform_call_graph_edges = CB_CGE_DUPLICATE;
+  id.transform_new_cfg = true;
+  id.transform_return_to_modify = false;
+  id.transform_lang_insert_block = NULL;
+  id.eh_lp_nr = 0;
+  walk_tree (&stmt, copy_tree_body_r, &id, NULL);
+  pointer_map_destroy (decl_map);
+  return stmt;
+}
+
+/* Helper function of c_finish_omp_clauses, called via walk_tree.
+   Find OMP_CLAUSE_PLACEHOLDER (passed in DATA) in *TP.  */
+
+static tree
+c_find_omp_placeholder_r (tree *tp, int *, void *data)
+{
+  if (*tp == (tree) data)
+return *tp;
+  return NULL_TREE;
+}
+
 /* For all elements of CLAUSES, validate them vs OpenMP constraints.
Remove any elements from the list that are invalid.  */
 
@@ -11252,14 +11295,8 @@ c_finish_omp_clauses (tree clauses)
  name = "reduction";
  need_implicitly_determined = true;
  t = OMP_CLAUSE_DECL (c);
- if (AGGREGATE_TYPE_P (TREE_TYPE (t))
- || POINTER_TYPE_P (TREE_TYPE (t)))
-   {
- error_at (OMP_CLAUSE_LOCATION (c),
-   "%qE has invalid type for %", t);
- remove = true;
-   }
- else if (FLOAT_TYPE_P (TREE_TYPE (t)))
+ if (OMP_CLAUSE_REDUCTION_PLACEHOLDER (c) == NULL_TREE
+ && FLOAT_TYPE_P (TREE_TYPE (t)))
{
  enum tree_code r_code = OMP_CLAUSE_REDUCTION_CODE (c);
  const char *r_name = NULL;
@@ -11298,6 +11335,73 @@ c_finish_omp_clauses (tree clauses)
  remove = true;
}
}
+ else if (

Re: [PATCH v3 05/18] convert the C front end to automatic dependencies

[Paolo Bonzini]

Il 16/09/2013 22:58, Tom Tromey ha scritto:
> Paolo> The series looks okay to me with that change.
> 
> Two last questions while I'm testing my rebase --
> 
> First, do you mind if I resend the whole series?  Otherwise I can try to
> pick out just the patches that have changed, plus the additional
> patches.
> 
> Second, should I get a separate ok for the changes in the fortran
> directory?  Or does your approval here cover those?

I didn't review them because I saw front-end maintainers were looking at
their own patches, but I can approve them when you resend the whole series.

Paolo

Re: [Patch, AArch64, ILP32] 1/5 Initial support - configury changes

[Andreas Schwab]

Yufeng Zhang  writes:

> Ah, I didn't think too much at then on the backward compatibility issue
> with binutils-2_23.  One potential solution can be to backport part of
> configury change from binutils trunk to 2_23.  Can I ask if there is any
> particular reason that you wouldn't like to build the trunk compiler with
> the trunk binutils?

You also get the error with a slightly older binutils trunk.  There
should be a configure check instead of failing to build.  It should
either require that the assembler is new enough, or drop the unknown
option (for aarch64-linux where multilibs are not enabled you don't need
it anyway).

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

[PATCH] Fix PR58417

[Richard Biener]

This PR shows that we may not fold chrec operations with chrecs
that are not properly instantiated (and thus may contain symbols
that are defined in the varying loop).  To fix that the patch
makes sure to instantiate them and adds asserts to catch issues
elsewhere (hopefully not too many).  For this to work the
recursion prevention of instantiation has to be globalized
as we can recurse through analyze_scalar_evolution.  This also
fixes a reallocation issue with the current cache.

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

Richard.

2013-09-18  Richard Biener  

PR tree-optimization/58417
* tree-chrec.c (chrec_fold_plus_1): Assert that we do not
have chrecs with symbols defined in the loop as operands.
(chrec_fold_multiply): Likewise.
* tree-scalar-evolution.c (interpret_rhs_expr): Instantiate
parameters before folding binary operations.
(struct instantiate_cache_entry_hasher): Remove.
(struct instantiate_cache_type): Use a pointer-map.
(instantiate_cache_type::instantiate_cache_type): New function.
(instantiate_cache_type::get): Likewise.
(instantiate_cache_type::set): Likewise.
(instantiate_cache_type::~instantiate_cache_type): Adjust.
(get_instantiated_value_entry): Likewise.
(global_cache): New global.
(instantiate_scev_r, instantiate_scev_poly, instantiate_scev_binary,
instantiate_array_ref, instantiate_scev_convert, instantiate_scev_3,
instantiate_scev_2, instantiate_scev_1): Do not pass along cache.
(instantiate_scev_name): Adjust.
(instantiate_scev): Construct global instead of local cache.
(resolve_mixers): Likewise.

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

Index: gcc/tree-chrec.c
===
*** gcc/tree-chrec.c(revision 202681)
--- gcc/tree-chrec.c(working copy)
*** chrec_fold_plus_1 (enum tree_code code,
*** 268,276 
--- 268,281 
switch (TREE_CODE (op0))
  {
  case POLYNOMIAL_CHREC:
+   gcc_checking_assert
+   (!chrec_contains_symbols_defined_in_loop (op0, CHREC_VARIABLE (op0)));
switch (TREE_CODE (op1))
{
case POLYNOMIAL_CHREC:
+ gcc_checking_assert
+   (!chrec_contains_symbols_defined_in_loop (op1,
+ CHREC_VARIABLE (op1)));
  return chrec_fold_plus_poly_poly (code, type, op0, op1);
  
CASE_CONVERT:
*** chrec_fold_plus_1 (enum tree_code code,
*** 298,303 
--- 303,311 
switch (TREE_CODE (op1))
{
case POLYNOMIAL_CHREC:
+ gcc_checking_assert
+   (!chrec_contains_symbols_defined_in_loop (op1,
+ CHREC_VARIABLE (op1)));
  if (code == PLUS_EXPR || code == POINTER_PLUS_EXPR)
return build_polynomial_chrec
  (CHREC_VARIABLE (op1),
*** chrec_fold_multiply (tree type,
*** 396,404 
--- 404,417 
switch (TREE_CODE (op0))
  {
  case POLYNOMIAL_CHREC:
+   gcc_checking_assert
+   (!chrec_contains_symbols_defined_in_loop (op0, CHREC_VARIABLE (op0)));
switch (TREE_CODE (op1))
{
case POLYNOMIAL_CHREC:
+ gcc_checking_assert
+   (!chrec_contains_symbols_defined_in_loop (op1,
+ CHREC_VARIABLE (op1)));
  return chrec_fold_multiply_poly_poly (type, op0, op1);
  
CASE_CONVERT:
*** chrec_fold_multiply (tree type,
*** 431,436 
--- 444,452 
switch (TREE_CODE (op1))
{
case POLYNOMIAL_CHREC:
+ gcc_checking_assert
+   (!chrec_contains_symbols_defined_in_loop (op1,
+ CHREC_VARIABLE (op1)));
  return build_polynomial_chrec
(CHREC_VARIABLE (op1),
 chrec_fold_multiply (type, CHREC_LEFT (op1), op0),
Index: gcc/tree-scalar-evolution.c
===
*** gcc/tree-scalar-evolution.c (revision 202681)
--- gcc/tree-scalar-evolution.c (working copy)
*** interpret_rhs_expr (struct loop *loop, g
*** 1648,1653 
--- 1648,1655 
  chrec2 = analyze_scalar_evolution (loop, rhs2);
  chrec1 = chrec_convert (type, chrec1, at_stmt);
  chrec2 = chrec_convert (TREE_TYPE (rhs2), chrec2, at_stmt);
+ chrec1 = instantiate_parameters (loop, chrec1);
+ chrec2 = instantiate_parameters (loop, chrec2);
  res = chrec_fold_plus (type, chrec1, chrec2);
}
  else
*** interpret_rhs_expr (struct loop *loop, g
*** 1661,1666 
--- 1663,1669 
{
  chrec2 = analyze_scalar_evolution (loop, offset);
  chrec2 = chrec_convert

Re: [PATCH], PR target/58452, Fix gcc 4.8/trunk linuxpaired breakage

[David Edelsohn]

On Tue, Sep 17, 2013 at 8:03 PM, Michael Meissner
 wrote:
> While doing some work on power8, I wanted to make sure that for existing
> systems, I was generating the same code.  So I built some code and ran it
> through various -mcpu= options.  When I built a powerpc-linuxpaired
> compiler, the compiler has trouble with a simple loop that should be
> vectorized.  I traced the code to changes in the vectorizer that required the
> predicates for movmismalign* to accept memory operands.

> I will do the usual bootstrap/make check tomorrow.  Assuming it has no
> regressions, can I check this patch it to both the 4.8 branch and trunk?
>
> 2013-09-17  Michael Meissner  
>
> PR target/58452
> * config/rs6000/paired.md (movmisalignv2sf): Fix to allow memory
> operaands.

Okay.

Thanks, David

Re: [PATCH, committed] SH: Fix PR58314 (unsatisfied constraints)

[Oleg Endo]

On Wed, 2013-09-18 at 09:55 +0200, Christian Bruel wrote:
> Hi Richard,
> 
> On 09/16/2013 07:10 PM, Richard Sandiford wrote:
> > Hi Christian,
> >
> > Christian Bruel  writes:
> >> @@ -6893,11 +6894,14 @@ label:
> >>  ;; reloading MAC subregs otherwise.  For that probably special patterns
> >>  ;; would be required.
> >>  (define_insn "*mov_reg_reg"
> >> -  [(set (match_operand:QIHI 0 "arith_reg_dest" "=r")
> >> -  (match_operand:QIHI 1 "register_operand" "r"))]
> >> +  [(set (match_operand:QIHI 0 "arith_reg_dest" "=r,m,*z")
> >> +  (match_operand:QIHI 1 "register_operand" "r,*z,m"))]
> > If the constraints allow "m", the predicates need to accept memories too.
> > (It'd be worth having an insn condition that rejects both operands
> > being memories though.)
> >
> > Thanks,
> > Richard
> Thanks for your comment,
> 
> I was wondering this too when doing the fix. I felt that a memory
> operand would be matched by the *movhi" patterns bellow.  As  I wanted
> to fix only the spilling case, so the original operand is a pseudo reg
> having matched the register predicate.
> Without the predicate memory not found, I wonder how I never hit a kind
> of "insn not found" error,  well, 'll give a try to adding a memory
> condition in the predicate, 
> but I fear that the movhi patterns will stop
> to match,

Yes, this will be the case.  The order of the movhi and movqi patterns
in the md file is important.  To address the predicates vs. constraints
issue, the following seems to work:

(define_insn "*mov_reg_reg"
  [(set (match_operand:QIHI 0 "general_movsrc_operand" "=r,m,*z")
(match_operand:QIHI 1 "general_movdst_operand" "r,*z,m"))]
  "TARGET_SH1 && !t_reg_operand (operands[1], VOIDmode)
   && (arith_reg_operand (operands[0], mode)
   || arith_reg_operand (operands[1], mode))
   && (!can_create_pseudo_p () && REG_P (operands[0]) && REG_P (operands[1]))"
  "@
mov %1,%0
mov.%1,%0
mov.%1,%0"
  [(set_attr "type" "move,store,load")])

.. at least it survives the test case for this PR.  I haven't done
further tests.

BTW, in the test case (gcc.target/sh/torture/pr58314.c), this 

/* { dg-options "-Os" } */

defeats the purpose of the torture tests.

Cheers,
Oleg

Re: [PATCH], PR target/58452, Fix gcc 4.8/trunk linuxpaired breakage

[Jakub Jelinek]

On Wed, Sep 18, 2013 at 08:58:03AM -0400, David Edelsohn wrote:
> On Tue, Sep 17, 2013 at 8:03 PM, Michael Meissner
>  wrote:
> > While doing some work on power8, I wanted to make sure that for existing
> > systems, I was generating the same code.  So I built some code and ran it
> > through various -mcpu= options.  When I built a powerpc-linuxpaired
> > compiler, the compiler has trouble with a simple loop that should be
> > vectorized.  I traced the code to changes in the vectorizer that required 
> > the
> > predicates for movmismalign* to accept memory operands.
> 
> > I will do the usual bootstrap/make check tomorrow.  Assuming it has no
> > regressions, can I check this patch it to both the 4.8 branch and trunk?
> >
> > 2013-09-17  Michael Meissner  
> >
> > PR target/58452
> > * config/rs6000/paired.md (movmisalignv2sf): Fix to allow memory
> > operaands.
> 
> Okay.

s/aa/a/ in the ChangeLog entry.

Jakub

[PATCH] Properly honor -fsanitize options (PR sanitizer/58443)

[Marek Polacek]

As mentioned in the PR, we weren't properly using the SANITIZE_* flags,
which resulted in sanitizing shifts even though we only should sanitize
divisions and vice versa.  It also removed one unnecessary check; it's
sufficient to check that instrument_expr != NULL.  I also found a mistake
in a test, it assumed that -fsanitize=shift also turns sanitizing of
divisions.  Thus fixed.

Ran ubsan testsuite/bootstrap-ubsan on x86_64-linux, ok for trunk?

2013-09-18  Marek Polacek  

PR sanitize/58443
cp/
* typeck.c (cp_build_binary_op): Properly honor -fsanitize options.
Remove unnecessary check.

c/
* c-typeck.c (build_binary_op): Properly honor -fsanitize options.
Remove unnecessary check.

testsuite/
* g++.dg/ubsan/div-by-zero-1.C: Use the integer-divide-by-zero option
instead of the shift option.
* c-c++-common/ubsan/pr58443-1.c: New test.
* c-c++-common/ubsan/pr58443-3.c: New test.
* c-c++-common/ubsan/pr58443-2.c: New test.

--- gcc/cp/typeck.c.mp  2013-09-18 14:00:14.303869196 +0200
+++ gcc/cp/typeck.c 2013-09-18 14:08:21.287770112 +0200
@@ -4884,7 +4884,7 @@ cp_build_binary_op (location_t location,
   if (build_type == NULL_TREE)
 build_type = result_type;
 
-  if ((flag_sanitize & SANITIZE_UNDEFINED)
+  if ((flag_sanitize & SANITIZE_SHIFT || flag_sanitize & SANITIZE_DIVIDE)
   && !processing_template_decl
   && current_function_decl != 0
   && !lookup_attribute ("no_sanitize_undefined",
@@ -4898,7 +4898,7 @@ cp_build_binary_op (location_t location,
  tf_none));
   op1 = maybe_constant_value (fold_non_dependent_expr_sfinae (op1,
  tf_none));
-  if (doing_div_or_mod)
+  if (doing_div_or_mod && flag_sanitize & SANITIZE_DIVIDE)
{
  /* For diagnostics we want to use the promoted types without
 shorten_binary_op.  So convert the arguments to the
@@ -4912,7 +4912,7 @@ cp_build_binary_op (location_t location,
}
  instrument_expr = ubsan_instrument_division (location, cop0, cop1);
}
-  else if (doing_shift)
+  else if (doing_shift && flag_sanitize & SANITIZE_SHIFT)
instrument_expr = ubsan_instrument_shift (location, code, op0, op1);
 }
 
@@ -4926,7 +4926,7 @@ cp_build_binary_op (location_t location,
   && !TREE_OVERFLOW_P (op1))
 overflow_warning (location, result);
 
-  if ((flag_sanitize & SANITIZE_UNDEFINED) && instrument_expr != NULL)
+  if (instrument_expr != NULL)
 result = fold_build2 (COMPOUND_EXPR, TREE_TYPE (result),
  instrument_expr, result);
 
--- gcc/c/c-typeck.c.mp 2013-09-18 14:00:06.704837584 +0200
+++ gcc/c/c-typeck.c2013-09-18 14:04:57.372968880 +0200
@@ -10496,7 +10496,7 @@ build_binary_op (location_t location, en
return error_mark_node;
 }
 
-  if (flag_sanitize & SANITIZE_UNDEFINED
+  if ((flag_sanitize & SANITIZE_SHIFT || flag_sanitize & SANITIZE_DIVIDE)
   && current_function_decl != 0
   && !lookup_attribute ("no_sanitize_undefined",
DECL_ATTRIBUTES (current_function_decl))
@@ -10507,9 +10507,9 @@ build_binary_op (location_t location, en
   op1 = c_save_expr (op1);
   op0 = c_fully_fold (op0, false, NULL);
   op1 = c_fully_fold (op1, false, NULL);
-  if (doing_div_or_mod)
+  if (doing_div_or_mod && flag_sanitize & SANITIZE_DIVIDE)
instrument_expr = ubsan_instrument_division (location, op0, op1);
-  else if (doing_shift)
+  else if (doing_shift && flag_sanitize & SANITIZE_SHIFT)
instrument_expr = ubsan_instrument_shift (location, code, op0, op1);
 }
 
@@ -10537,7 +10537,7 @@ build_binary_op (location_t location, en
 ret = build1 (EXCESS_PRECISION_EXPR, semantic_result_type, ret);
   protected_set_expr_location (ret, location);
 
-  if ((flag_sanitize & SANITIZE_UNDEFINED) && instrument_expr != NULL)
+  if (instrument_expr != NULL)
 ret = fold_build2 (COMPOUND_EXPR, TREE_TYPE (ret),
   instrument_expr, ret);
 
--- gcc/testsuite/g++.dg/ubsan/div-by-zero-1.C.mp   2013-09-18 
14:24:42.735312422 +0200
+++ gcc/testsuite/g++.dg/ubsan/div-by-zero-1.C  2013-09-18 14:25:28.965491706 
+0200
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-fsanitize=shift -w" } */
+/* { dg-options "-fsanitize=integer-divide-by-zero -w" } */
 
 void
 foo (int i)
--- gcc/testsuite/c-c++-common/ubsan/pr58443-1.c.mp 2013-09-18 
14:20:18.633348043 +0200
+++ gcc/testsuite/c-c++-common/ubsan/pr58443-1.c2013-09-18 
14:30:45.403701302 +0200
@@ -0,0 +1,11 @@
+/* PR sanitizer/58443 */
+/* { dg-do compile } */
+/* { dg-options "-fsanitize=shift,unreachable -w" } */
+
+int
+foo (int u, int o)
+{
+  return u / o;
+}
+
+/* { dg-final { scan-assembler-not "__ubsan_handle_divrem_overflow" } } */
--- gcc/testsuite/c-c++-common/ubsan/pr5844

Re: [Patch, Fortran] PR43366 - add invalid-diagnostic for poly assignment

[Janus Weil]

Hi,

> (Side remark: That's Janus' email which didn't make it past GCC's mail
> server.)

... for whatever reason. I hope this one will make it through.


 Fortran 2008 permits assignment to polymorphic variables with some
 constraints. The patch, which was sitting in my tree, adds diagnostic to
 reject invalid use. For valid code, it runs into the existing
 not-yet-implemented error.

 Build + regtested on x86-64-gnu-linux.
 OK for the trunk?
>>
>> a few comments:
>> 1) How about a test case?
>
> I added one - and fixed an issue with gfc_expr_attr for codimension.

Ok, thanks. I hadn't noticed the codimension problem.


>> 2) Why not leave in the comment with the F03 reference for now, since
>> you're not modifying that part?
>
> Well, the F2003 reference is wrong (its about something else).

No, it's not. F03:7.4.1.2 is about intrinsic assignments, just like F08:7.2.1.2.

However, F03:7.2.1.2 is not (maybe this is what you were looking at?).


> That's not
> surprising as assignment to an allocatable polymorphic variable is a Fortran
> 2008 feature. (Reading it as F2008 section number leads one to the intrinsic
> assignment section, which is fine.)
>
>
>> 3) You might wanna modify the FIXME note, since your patch addresses
>> at least part of it (namely the invalid-rejection). The only missing
>> item now is to allow the things that are valid in F08, I guess.
>
> I have now updated the comment - and made the error message clearer.

Ok, looks better to me. After the realloc-on-assign is fully
implemented, one should replace the "not implemented" error by a
gfc_notify_std, of course (where the F03:7.2.1.2 reference would still
make sense).


> Attached is the updated patch.
> OK for the trunk?

Yes, fine with me. Thanks for the patch.


>> Btw, the patch at http://gcc.gnu.org/ml/fortran/2013-08/msg00026.html
>> was half-approved by Mikael, but is still waiting for your agreement,
>> Tobias, since you had some criticism in the PR ...
>
> Sorry for the delay. However, it seems as if I have now a bit more time for
> GCC/gfortran. I try to get an overview about the August backlog and reply to
> the missing items; in particular to that patch.

That would be great, it's been hanging in there for a while now ...

Cheers,
Janus

Re: [PATCH] Properly honor -fsanitize options (PR sanitizer/58443)

[Jakub Jelinek]

On Wed, Sep 18, 2013 at 03:10:42PM +0200, Marek Polacek wrote:
> --- gcc/cp/typeck.c.mp2013-09-18 14:00:14.303869196 +0200
> +++ gcc/cp/typeck.c   2013-09-18 14:08:21.287770112 +0200
> @@ -4884,7 +4884,7 @@ cp_build_binary_op (location_t location,
>if (build_type == NULL_TREE)
>  build_type = result_type;
>  
> -  if ((flag_sanitize & SANITIZE_UNDEFINED)
> +  if ((flag_sanitize & SANITIZE_SHIFT || flag_sanitize & SANITIZE_DIVIDE)

I'd suggest to use
if ((flag & (SANITIZE_SHIFT | SANITIZE_DIVIDE))
instead.

>&& !processing_template_decl
>&& current_function_decl != 0
>&& !lookup_attribute ("no_sanitize_undefined",
> @@ -4898,7 +4898,7 @@ cp_build_binary_op (location_t location,
> tf_none));
>op1 = maybe_constant_value (fold_non_dependent_expr_sfinae (op1,
> tf_none));
> -  if (doing_div_or_mod)
> +  if (doing_div_or_mod && flag_sanitize & SANITIZE_DIVIDE)

And, while the operator precedence is right, I think it would be better
to use if (doing_div_or_mod && (flag_sanitize & SANITIZE_DIVIDE))

Jakub

Re: [PATCH] Properly honor -fsanitize options (PR sanitizer/58443)

[Marek Polacek]

On Wed, Sep 18, 2013 at 03:15:05PM +0200, Jakub Jelinek wrote:
> On Wed, Sep 18, 2013 at 03:10:42PM +0200, Marek Polacek wrote:
> > --- gcc/cp/typeck.c.mp  2013-09-18 14:00:14.303869196 +0200
> > +++ gcc/cp/typeck.c 2013-09-18 14:08:21.287770112 +0200
> > @@ -4884,7 +4884,7 @@ cp_build_binary_op (location_t location,
> >if (build_type == NULL_TREE)
> >  build_type = result_type;
> >  
> > -  if ((flag_sanitize & SANITIZE_UNDEFINED)
> > +  if ((flag_sanitize & SANITIZE_SHIFT || flag_sanitize & SANITIZE_DIVIDE)
> 
> I'd suggest to use
> if ((flag & (SANITIZE_SHIFT | SANITIZE_DIVIDE))
> instead.
> 
> >&& !processing_template_decl
> >&& current_function_decl != 0
> >&& !lookup_attribute ("no_sanitize_undefined",
> > @@ -4898,7 +4898,7 @@ cp_build_binary_op (location_t location,
> >   tf_none));
> >op1 = maybe_constant_value (fold_non_dependent_expr_sfinae (op1,
> >   tf_none));
> > -  if (doing_div_or_mod)
> > +  if (doing_div_or_mod && flag_sanitize & SANITIZE_DIVIDE)
> 
> And, while the operator precedence is right, I think it would be better
> to use if (doing_div_or_mod && (flag_sanitize & SANITIZE_DIVIDE))

Thanks, fixed in both FEs.  Re-ran the ubsan testsuite.  Ok now?

2013-09-18  Marek Polacek  

PR sanitize/58443
cp/
* typeck.c (cp_build_binary_op): Properly honor -fsanitize options.
Remove unnecessary check.

c/
* c-typeck.c (build_binary_op): Properly honor -fsanitize options.
Remove unnecessary check.

testsuite/
* g++.dg/ubsan/div-by-zero-1.C: Use the integer-divide-by-zero option
instead of the shift option.
* c-c++-common/ubsan/pr58443-1.c: New test.
* c-c++-common/ubsan/pr58443-3.c: New test.
* c-c++-common/ubsan/pr58443-2.c: New test.

--- gcc/cp/typeck.c.mp  2013-09-18 14:00:14.303869196 +0200
+++ gcc/cp/typeck.c 2013-09-18 15:19:56.601920206 +0200
@@ -4884,7 +4884,7 @@ cp_build_binary_op (location_t location,
   if (build_type == NULL_TREE)
 build_type = result_type;
 
-  if ((flag_sanitize & SANITIZE_UNDEFINED)
+  if ((flag_sanitize & (SANITIZE_SHIFT | SANITIZE_DIVIDE))
   && !processing_template_decl
   && current_function_decl != 0
   && !lookup_attribute ("no_sanitize_undefined",
@@ -4898,7 +4898,7 @@ cp_build_binary_op (location_t location,
  tf_none));
   op1 = maybe_constant_value (fold_non_dependent_expr_sfinae (op1,
  tf_none));
-  if (doing_div_or_mod)
+  if (doing_div_or_mod && (flag_sanitize & SANITIZE_DIVIDE))
{
  /* For diagnostics we want to use the promoted types without
 shorten_binary_op.  So convert the arguments to the
@@ -4912,7 +4912,7 @@ cp_build_binary_op (location_t location,
}
  instrument_expr = ubsan_instrument_division (location, cop0, cop1);
}
-  else if (doing_shift)
+  else if (doing_shift && (flag_sanitize & SANITIZE_SHIFT))
instrument_expr = ubsan_instrument_shift (location, code, op0, op1);
 }
 
@@ -4926,7 +4926,7 @@ cp_build_binary_op (location_t location,
   && !TREE_OVERFLOW_P (op1))
 overflow_warning (location, result);
 
-  if ((flag_sanitize & SANITIZE_UNDEFINED) && instrument_expr != NULL)
+  if (instrument_expr != NULL)
 result = fold_build2 (COMPOUND_EXPR, TREE_TYPE (result),
  instrument_expr, result);
 
--- gcc/c/c-typeck.c.mp 2013-09-18 14:00:06.704837584 +0200
+++ gcc/c/c-typeck.c2013-09-18 15:20:10.263972487 +0200
@@ -10496,7 +10496,7 @@ build_binary_op (location_t location, en
return error_mark_node;
 }
 
-  if (flag_sanitize & SANITIZE_UNDEFINED
+  if ((flag_sanitize & (SANITIZE_SHIFT | SANITIZE_DIVIDE))
   && current_function_decl != 0
   && !lookup_attribute ("no_sanitize_undefined",
DECL_ATTRIBUTES (current_function_decl))
@@ -10507,9 +10507,9 @@ build_binary_op (location_t location, en
   op1 = c_save_expr (op1);
   op0 = c_fully_fold (op0, false, NULL);
   op1 = c_fully_fold (op1, false, NULL);
-  if (doing_div_or_mod)
+  if (doing_div_or_mod && (flag_sanitize & SANITIZE_DIVIDE))
instrument_expr = ubsan_instrument_division (location, op0, op1);
-  else if (doing_shift)
+  else if (doing_shift && (flag_sanitize & SANITIZE_SHIFT))
instrument_expr = ubsan_instrument_shift (location, code, op0, op1);
 }
 
@@ -10537,7 +10537,7 @@ build_binary_op (location_t location, en
 ret = build1 (EXCESS_PRECISION_EXPR, semantic_result_type, ret);
   protected_set_expr_location (ret, location);
 
-  if ((flag_sanitize & SANITIZE_UNDEFINED) && instrument_expr != NULL)
+  if (instrument_expr != NULL)
 ret = fold_build2 (COMPOUND_EX

Re: [PATCH] Properly honor -fsanitize options (PR sanitizer/58443)

[Jakub Jelinek]

On Wed, Sep 18, 2013 at 03:23:24PM +0200, Marek Polacek wrote:
> Thanks, fixed in both FEs.  Re-ran the ubsan testsuite.  Ok now?

Ok, thanks.

Jakub

[gomp4] Tweak GOMP_target{,_data,_update} arguments

[Jakub Jelinek]

Hi!

As discussed earlier, I'd like to pass __OPENMP_TARGET__ argument to
all of GOMP_target{,_data,_update}, so that all those functions
can get at the offloading data section in the shared library or binary
making the call, so that the first time they encounter such a call
in the shared library or binary, it can attempt to actually offload
it to the target (and, if that fails, remember it, and do host fallback).
The reason to pass this also to GOMP_target_data and GOMP_target_update is
that even for those calls the global vars will already need to be mapped,
and to make sure e.g. GOMP_target_data doesn't perform on the target device,
while GOMP_target with the same device clause is performed as host fallback
(that could result in wrong code, e.g. when target data copies data from
device to host at the end, while target construct would modify the host
copies, thus the current host copy would be overwritten by stale target
copy).

As weak undefined hidden symbols don't seem to work as I hoped they would
do, I'm just passing NULL for now, we'll need to wait until we have a linker
plugin that will create the offloading section for us and add hidden
__OPENMP_TARGET__ symbol.

2013-09-18  Jakub Jelinek  

* omp-builtins.def (BUILT_IN_GOMP_TARGET_DATA,
BUILT_IN_GOMP_TARGET_UPDATE): Use BT_FN_VOID_INT_PTR_SIZE_PTR_PTR_PTR
rather than BT_FN_VOID_INT_SIZE_PTR_PTR_PTR.
* builtin-types.def (BT_FN_VOID_INT_SIZE_PTR_PTR_PTR): Remove.
(BT_FN_VOID_INT_PTR_SIZE_PTR_PTR_PTR): New.
* omp-low.c (expand_omp_target): Remove fnname argument from
GOMP_target, add openmp_target argument to GOMP_target,
GOMP_target_data and GOMP_target_update calls.
gcc/fortran/
* types.def (BT_FN_VOID_INT_SIZE_PTR_PTR_PTR): Remove.
(BT_FN_VOID_INT_PTR_SIZE_PTR_PTR_PTR): New.
libgomp/
* libgomp_g.h (GOMP_target): Change 3rd argument to const void *.
(GOMP_target_data, GOMP_target_update): Add openmp_target argument.
* target.c (GOMP_target): Change fnname argument to openmp_target,
with const void * type.
(GOMP_target_data, GOMP_target_update): Add openmp_target argument.

--- gcc/omp-builtins.def.jj 2013-09-05 09:19:03.0 +0200
+++ gcc/omp-builtins.def2013-09-18 14:16:38.522988068 +0200
@@ -229,10 +229,10 @@ DEF_GOMP_BUILTIN (BUILT_IN_GOMP_TARGET,
  BT_FN_VOID_INT_OMPFN_PTR_SIZE_PTR_PTR_PTR,
  ATTR_NOTHROW_LIST)
 DEF_GOMP_BUILTIN (BUILT_IN_GOMP_TARGET_DATA, "GOMP_target_data",
- BT_FN_VOID_INT_SIZE_PTR_PTR_PTR, ATTR_NOTHROW_LIST)
+ BT_FN_VOID_INT_PTR_SIZE_PTR_PTR_PTR, ATTR_NOTHROW_LIST)
 DEF_GOMP_BUILTIN (BUILT_IN_GOMP_TARGET_END_DATA, "GOMP_target_end_data",
  BT_FN_VOID, ATTR_NOTHROW_LIST)
 DEF_GOMP_BUILTIN (BUILT_IN_GOMP_TARGET_UPDATE, "GOMP_target_update",
- BT_FN_VOID_INT_SIZE_PTR_PTR_PTR, ATTR_NOTHROW_LIST)
+ BT_FN_VOID_INT_PTR_SIZE_PTR_PTR_PTR, ATTR_NOTHROW_LIST)
 DEF_GOMP_BUILTIN (BUILT_IN_GOMP_TEAMS, "GOMP_teams",
  BT_FN_VOID_UINT_UINT, ATTR_NOTHROW_LIST)
--- gcc/builtin-types.def.jj2013-09-05 09:19:03.0 +0200
+++ gcc/builtin-types.def   2013-09-18 14:17:20.964764926 +0200
@@ -473,8 +473,6 @@ DEF_FUNCTION_TYPE_5 (BT_FN_BOOL_VPTR_PTR
 DEF_FUNCTION_TYPE_5 (BT_FN_VOID_OMPFN_PTR_UINT_UINT_UINT,
 BT_VOID, BT_PTR_FN_VOID_PTR, BT_PTR, BT_UINT, BT_UINT,
 BT_UINT)
-DEF_FUNCTION_TYPE_5 (BT_FN_VOID_INT_SIZE_PTR_PTR_PTR,
-BT_VOID, BT_INT, BT_SIZE, BT_PTR, BT_PTR, BT_PTR)
 
 DEF_FUNCTION_TYPE_6 (BT_FN_INT_STRING_SIZE_INT_SIZE_CONST_STRING_VALIST_ARG,
 BT_INT, BT_STRING, BT_SIZE, BT_INT, BT_SIZE,
@@ -502,6 +500,8 @@ DEF_FUNCTION_TYPE_6 (BT_FN_BOOL_VPTR_PTR
 BT_INT)
 DEF_FUNCTION_TYPE_6 (BT_FN_BOOL_SIZE_VPTR_PTR_PTR_INT_INT, BT_BOOL, BT_SIZE,
 BT_VOLATILE_PTR, BT_PTR, BT_PTR, BT_INT, BT_INT)
+DEF_FUNCTION_TYPE_6 (BT_FN_VOID_INT_PTR_SIZE_PTR_PTR_PTR,
+BT_VOID, BT_INT, BT_PTR, BT_SIZE, BT_PTR, BT_PTR, BT_PTR)
 
 DEF_FUNCTION_TYPE_7 (BT_FN_VOID_OMPFN_PTR_UINT_LONG_LONG_LONG_UINT,
 BT_VOID, BT_PTR_FN_VOID_PTR, BT_PTR, BT_UINT,
--- gcc/fortran/types.def.jj2013-09-05 09:19:03.0 +0200
+++ gcc/fortran/types.def   2013-09-18 14:23:23.914822416 +0200
@@ -168,8 +168,6 @@ DEF_FUNCTION_TYPE_5 (BT_FN_BOOL_LONG_LON
 BT_PTR_LONG, BT_PTR_LONG)
 DEF_FUNCTION_TYPE_5 (BT_FN_VOID_SIZE_VPTR_PTR_PTR_INT, BT_VOID, BT_SIZE,
 BT_VOLATILE_PTR, BT_PTR, BT_PTR, BT_INT)
-DEF_FUNCTION_TYPE_5 (BT_FN_VOID_INT_SIZE_PTR_PTR_PTR,
-BT_VOID, BT_INT, BT_SIZE, BT_PTR, BT_PTR, BT_PTR)
 
 DEF_FUNCTION_TYPE_6 (BT_FN_BOOL_LONG_LONG_LONG_LONG_LONGPTR_LONGPTR,
  BT_BOOL, BT_LONG, BT_LONG, BT_LONG, BT_LONG,
@@ -194,6 +192,8 @@ DEF_FUNCTION_TYPE_6 (BT_FN_BOOL_VPTR_PTR

RE: [PATCH] disable use_vector_fp_converts for m_CORE_ALL

[Zamyatin, Igor]

Ccing Uros. Changes in i386.md could be related to the fix for PR57954.

Thanks,
Igor

-Original Message-
From: Wei Mi [mailto:w...@google.com] 
Sent: Thursday, September 12, 2013 2:51 AM
To: GCC Patches
Cc: David Li; Zamyatin, Igor
Subject: [PATCH] disable use_vector_fp_converts for m_CORE_ALL

For the following testcase 1.c, on westmere and sandybridge, performance with 
the option -mtune=^use_vector_fp_converts is better (improves from 3.46s to 
2.83s). It means cvtss2sd is often better than
unpcklps+cvtps2pd on recent x86 platforms.

1.c:
float total = 0.2;
int k = 5;

int main() {
 int i;

 for (i = 0; i < 10; i++) {
   total += (0.5 + k);
 }

 return total == 0.3;
}

assembly generated by gcc-r201963 without -mtune=^use_vector_fp_converts
.L2:
unpcklps%xmm0, %xmm0
subl$1, %eax
cvtps2pd%xmm0, %xmm0
addsd   %xmm1, %xmm0
unpcklpd%xmm0, %xmm0
cvtpd2ps%xmm0, %xmm0
jne .L2

assembly generated by gcc-r201963 with -mtune=^use_vector_fp_converts
.L2:
cvtss2sd%xmm0, %xmm0
subl$1, %eax
addsd   %xmm1, %xmm0
cvtsd2ss%xmm0, %xmm0
jne .L2

But for testcase 2.c (Thanks to Igor Zamyatin for the testcase), performance 
with the option -mtune=^use_vector_fp_converts is worse.
Analysis to the assembly shows the performance degradation comes from partial 
reg stall caused by cvtsd2ss. Adding pxor %xmm0, %xmm0 before cvtsd2ss 
b(,%rdx,8), %xmm0 gets the performance back.

2.c:
double b[1024];

float a[1024];

int main()
{
int i;
for(i = 0 ; i < 1024 * 1024 * 256; i++)
  a[i & 1023] = a[i & 1023] * (float)b[i & 1023];
return (int)a[512];
}

without -mtune-crtl=^use_vector_fp_converts
.L2:
movl%eax, %edx
addl$1, %eax
andl$1023, %edx
cmpl$268435456, %eax
movsd   b(,%rdx,8), %xmm0
cvtpd2ps%xmm0, %xmm0==> without partial reg stall
because of movsd.
mulss   a(,%rdx,4), %xmm0
movss   %xmm0, a(,%rdx,4)
jne .L2

with -mtune-crtl=^use_vector_fp_converts
.L2:
movl%eax, %edx
addl$1, %eax
andl$1023, %edx
cmpl$268435456, %eax
cvtsd2ssb(,%rdx,8), %xmm0   ==> with partial reg
stall. Needs to insert "pxor %xmm0, %xmm0" before current insn.
mulss   a(,%rdx,4), %xmm0
movss   %xmm0, a(,%rdx,4)
jne .L2

So the patch is to turn off use_vector_fp_converts for m_CORE_ALL to use 
cvtss2sd/cvtsd2ss directly,  and add "pxor %xmmreg %xmmreg" before 
cvtss2sd/cvtsd2ss to break partial reg stall (similar as what r201308 does for 
cvtsi2ss/cvtsi2sd). bootstrap and regression pass. ok for trunk?

Thanks,
Wei Mi.

2013-09-11  Wei Mi  

* config/i386/x86-tune.def (DEF_TUNE): Remove
m_CORE_ALL.
* config/i386/i386.md: Add define_peephole2 to
break partial reg stall for cvtss2sd/cvtsd2ss.

Index: config/i386/x86-tune.def
===
--- config/i386/x86-tune.def(revision 201963)
+++ config/i386/x86-tune.def(working copy)
@@ -189,7 +189,7 @@ DEF_TUNE (X86_TUNE_NOT_VECTORMODE, "not_
 /* X86_TUNE_USE_VECTOR_FP_CONVERTS: Prefer vector packed SSE conversion
from FP to FP. */
 DEF_TUNE (X86_TUNE_USE_VECTOR_FP_CONVERTS, "use_vector_fp_converts",
-  m_CORE_ALL | m_AMDFAM10 | m_GENERIC)
+  m_AMDFAM10 | m_GENERIC)
 /* X86_TUNE_USE_VECTOR_CONVERTS: Prefer vector packed SSE conversion
from integer to FP. */
 DEF_TUNE (X86_TUNE_USE_VECTOR_CONVERTS, "use_vector_converts", m_AMDFAM10)
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 201963)
+++ config/i386/i386.md (working copy)
@@ -5075,6 +5075,63 @@
   emit_move_insn (operands[0], CONST0_RTX (mode));
 })

+;; Break partial reg stall for cvtsd2ss.
+
+(define_peephole2
+  [(set (match_operand:SF 0 "register_operand")
+(float_truncate:SF
+ (match_operand:DF 1 "nonimmediate_operand")))]
+  "TARGET_SSE2 && TARGET_SSE_MATH
+   && TARGET_SSE_PARTIAL_REG_DEPENDENCY
+   && optimize_function_for_speed_p (cfun)
+   && reload_completed && SSE_REG_P (operands[0])
+   && peep2_reg_dead_p (0, operands[0])
+   && (!SSE_REG_P (operands[1])
+   || REGNO (operands[0]) != REGNO (operands[1]))"
+  [(set (match_dup 0)
+   (vec_merge:V4SF
+ (vec_duplicate:V4SF
+   (float_truncate:V2SF
+ (match_dup 1)))
+ (match_dup 0)
+ (const_int 1)))]
+{
+  operands[0] = simplify_gen_subreg (V4SFmode, operands[0],
+SFmode, 0);
+  operands[1] = simplify_gen_subreg (V2DFmode, operands[1],
+DFmode, 0);
+  emit_move_insn (operands[0], CONST0_RTX (V4SFmode));
+})
+
+;; Break partial reg stall for cvtss2sd.
+
+(define_peephole2
+  [(set (match_operand

[PATCH, ARM] Validate that target really supports LDRD/STRD before use

[Richard Earnshaw]

On ARM targets that normally support LDRD/STRD there are tuning
parameters that express the preference for using these instructions over
LDM/STM.  However, that's only a preference and when the architecture
and tuning options differ (for example, tuning for Cortex-A15 but using
the ARMv5 ISA) then it is essential to ensure that the architecture also
has the instructions.

R.

2013-09-18  Richard Earnshaw  

* arm.c (arm_get_frame_offsets): Validate architecture supports
LDRD/STRD before accepting the tuning preference.
(arm_expand_prologue): Likewise.
(arm_expand_epilogue): Likewise.

Committed to trunk.  A 4.8 back-port will follow.

R.

Re: [PATCH, ARM] Validate that target really supports LDRD/STRD before use

[Richard Earnshaw]

On 18/09/13 15:00, Richard Earnshaw wrote:
> On ARM targets that normally support LDRD/STRD there are tuning
> parameters that express the preference for using these instructions over
> LDM/STM.  However, that's only a preference and when the architecture
> and tuning options differ (for example, tuning for Cortex-A15 but using
> the ARMv5 ISA) then it is essential to ensure that the architecture also
> has the instructions.
> 
> R.
> 
> 2013-09-18  Richard Earnshaw  
> 
>   * arm.c (arm_get_frame_offsets): Validate architecture supports
>   LDRD/STRD before accepting the tuning preference.
>   (arm_expand_prologue): Likewise.
>   (arm_expand_epilogue): Likewise.
> 
> Committed to trunk.  A 4.8 back-port will follow.
> 
> R.
> 
> 

And this time with the patch...

R.--- arm.c   (revision 202671)
+++ arm.c   (local)
@@ -17955,7 +17956,8 @@ arm_get_frame_offsets (void)
   if (! any_sibcall_could_use_r3 ()
  && arm_size_return_regs () <= 12
  && (offsets->saved_regs_mask & (1 << 3)) == 0
-  && (TARGET_THUMB2 || !current_tune->prefer_ldrd_strd))
+  && (TARGET_THUMB2
+ || !(TARGET_LDRD && current_tune->prefer_ldrd_strd)))
{
  reg = 3;
}
@@ -18380,7 +18382,8 @@ arm_expand_prologue (void)
}
}
 
-  if (current_tune->prefer_ldrd_strd
+  if (TARGET_LDRD
+ && current_tune->prefer_ldrd_strd
   && !optimize_function_for_size_p (cfun))
 {
   if (TARGET_THUMB2)
@@ -24649,7 +24652,8 @@ arm_expand_epilogue (bool really_return)
 }
   else
 {
-  if (current_tune->prefer_ldrd_strd
+  if (TARGET_LDRD
+ && current_tune->prefer_ldrd_strd
   && !optimize_function_for_size_p (cfun))
 {
   if (TARGET_THUMB2)

[PATCH][committed] Use signed char for loop var in gcc.c-torture/execute/pr58419.c

[Kyrill Tkachov]

Hi all,

The recently added testcase gcc.c-torture/execute/pr58419.c uses a char 
variable to count down with negative values.
But on some architectures (like arm) a char is by default unsigned, 
causing the loop to be infinite.


I've committed the attached patch to explicitly label the variable as 
signed char.

Committed as r202703.

This fixes a timeout failure I've observed on arm an aarch64.

Thanks,
Kyrill

[gcc/testsuite/]
2013-09-18  Kyrylo Tkachov  

* gcc.c-torture/execute/pr58419.c (b): Change type to signed char.diff --git a/gcc/testsuite/gcc.c-torture/execute/pr58419.c b/gcc/testsuite/gcc.c-torture/execute/pr58419.c
index 527fcb7..69cc040 100644
--- a/gcc/testsuite/gcc.c-torture/execute/pr58419.c
+++ b/gcc/testsuite/gcc.c-torture/execute/pr58419.c
@@ -1,7 +1,8 @@
 int printf(const char *, ...);
 
-int a, g, i, k, *p; 
-char b, e;
+int a, g, i, k, *p;
+signed char b;
+char e;
 short c, h;
 static short *d = &c;
 

Re: [gomp4] Tweak GOMP_target{,_data,_update} arguments

[Michael V. Zolotukhin]

> As discussed earlier, I'd like to pass __OPENMP_TARGET__ argument to
> all of GOMP_target{,_data,_update}, so that all those functions
> can get at the offloading data section in the shared library or binary
> making the call, so that the first time they encounter such a call
> in the shared library or binary, it can attempt to actually offload
> it to the target (and, if that fails, remember it, and do host fallback).
Actually, I thought that that we'd perform loading the target code in
gomp-initialization.  So, first time libgomp is called, it loads target image
(from somewhere) and starts the target-side MAIN on the target (which actually
just starts to wait for offload requests).  Then, when GOMP_target is called, it
just passes address (or name, as it was initially) to this target-side MAIN and
the target executes the requested function.  I thought that at the moment
GOMP_target is called everything is ready and loaded as initialization has been
already executed.  Isn't that correct?  Maybe I misunderstood something - do you
want to load target images only in GOMP_target, not earlier?

And I still not quite get it, how would target code know, which function to call
in this scheme.  How will it figure out, which function to call if we didn't
even pass the function name?  As far as I understand, __OPENMP_TARGET__ will
lead to a dedicated section, which contains addresses of host-side versions of
the functions.  But how could we obtain the corresponding addresses for the
target?  COI, e.g., as I understand it, currently doesn't have a capability of
returning target-side function address - it only could call a function by name.
Or am I missing something?

Thanks, Michael
>   Jakub

Re: libtool update for powerpc64le-linux

[David Edelsohn]

I guess I can't really expect to gain an approval to import the
upstream libtool into gcc.  Even *I* don't really trust me, although
having looked at it a little I think I could even update
libjava/libltdl.  So how about just continuing the status quo and
applying a libtool patch that is already upstream?  Bootstrapped
powerpc64le-linux and powerpc64-linux.  OK to apply?

  * libtool.m4 (_LT_ENABLE_LOCK ): Remove non-canonical
ppc host match.  Support little-endian powerpc linux hosts.
libjava/libltdl/
  * acinclude.m4 (_LT_ENABLE_LOCK ): Remove non-canonical
ppc host match.  Support little-endian powerpc linux hosts.
  * configure: Regenerate.
boehm-gc/
* configure: Regenerate.
gcc/
* configure: Regenerate.
* aclocal.m4: Regenerate.
fixincludes/
* configure: Regenerate.
libatomic/
* configure: Regenerate.
libbacktrace/
* configure: Regenerate.
libffi/
* configure: Regenerate.
libgfortran/
* configure: Regenerate.
libgomp/
* configure: Regenerate.
libitm/
* configure: Regenerate.
libjava/
* configure: Regenerate.
libjava/classpath/
* configure: Regenerate.
libmudflap/
* configure: Regenerate.
libobjc/
* configure: Regenerate.
libquadmath/
* configure: Regenerate.
libsanitizer/
* configure: Regenerate.
libssp/
* configure: Regenerate.
libstdc++-v3/
* configure: Regenerate.
libvtv/
* configure: Regenerate.
lto-plugin/
* configure: Regenerate.
zlib/
* configure: Regenerate.

This is okay.

Please ensure that you use the correct version of autoconf to
regenerate the files. I don't think that the same version of autoconf
is used in all directories. Please visually inspect the diff, which
only should change the specific lines.

And please manually re-generate any configure files shared with "src".

Thanks, David

Re: [gomp4] Tweak GOMP_target{,_data,_update} arguments

[Jakub Jelinek]

On Wed, Sep 18, 2013 at 06:13:25PM +0400, Michael V. Zolotukhin wrote:
> > As discussed earlier, I'd like to pass __OPENMP_TARGET__ argument to
> > all of GOMP_target{,_data,_update}, so that all those functions
> > can get at the offloading data section in the shared library or binary
> > making the call, so that the first time they encounter such a call
> > in the shared library or binary, it can attempt to actually offload
> > it to the target (and, if that fails, remember it, and do host fallback).
> Actually, I thought that that we'd perform loading the target code in
> gomp-initialization.  So, first time libgomp is called, it loads target image
> (from somewhere) and starts the target-side MAIN on the target (which actually
> just starts to wait for offload requests).  Then, when GOMP_target is called, 
> it
> just passes address (or name, as it was initially) to this target-side MAIN 
> and
> the target executes the requested function.  I thought that at the moment
> GOMP_target is called everything is ready and loaded as initialization has 
> been
> already executed.  Isn't that correct?  Maybe I misunderstood something - do 
> you
> want to load target images only in GOMP_target, not earlier?

Yes, I want to load target images only in GOMP_target{,_data,_update}.
Loading it earlier is both premature (if you have say two MICs, one HSAIL
available, why would you upload everything to all 3 devices, even when you
don't know if the program will just print usage and exit and never enter any
target region), and hard to do (a program can have many shared libraries
(plus the binary), and each of them can have their offload stuff, how do you
find out what to offload and what not, and from where?).

__OPENMP_TARGET__ would be a linker plugin inserted symbol at the start of
some linker plugin created data section, which would start with some header
and then data.
Say
uleb128 number_of_supported_targets - n
uleb128 number_of_host_var_pairs - m
[ name of offload target (asciiz?)
  relative offset to the start of the offload data for the target (in MIC case 
embedded DSO)
  size of the offload data
  perhaps something how to find the target addresses array
] repeated n times
[ host_address, size ] repeated m times
(for the functions passed to GOMP_target the pair would be [ foobar.omp_fn.25, 
1 ] ).

If no offload data is provided at all, then the section would be just one
byte - 0 (or two bytes, 0 0)?

So, when GOMP_target{,_data,_update} is called, it could easily determine
if the calling shared library resp. binary has been offloaded or not (it
could e.g. have a few entries array as cache, otherwise lookup the
__OPENMP_TARGET__ address in the splay tree or something?
If it sees it hasn't been initialized yet, if it is the very first time,
for MIC it would upload the binary (from the plugin data section?), libgomp
and finally the shared library from the __OPENMP_TARGET__ and initialize the
splay tree with the variables.

> And I still not quite get it, how would target code know, which function to 
> call
> in this scheme.  How will it figure out, which function to call if we didn't
> even pass the function name?  As far as I understand, __OPENMP_TARGET__ will

See earlier mail, function names aren't neccessarily unique.  After the
__OPENMP_TARGET__ shared library is dlopened in the target and splay tree
initialized from the host array of [host_address, size] pairs and
corresponding array of target_address in the target code, you just lookup
the [ fnaddr, 1 ] in the splay tree and use the target address from that
mapping.

> lead to a dedicated section, which contains addresses of host-side versions of
> the functions.  But how could we obtain the corresponding addresses for the
> target?  COI, e.g., as I understand it, currently doesn't have a capability of
> returning target-side function address - it only could call a function by 
> name.
> Or am I missing something?

Jakub

RE: [PATCH 1/n] Add conditional compare support

[Michael Matz]

Hi,

On Wed, 18 Sep 2013, Zhenqiang Chen wrote:

> The patch is updated according to your comments. It is a basic support,
> which does not touch ifcombine and jump related optimizations yet.
> 
> Current method is:
> 1) In fold-const, if HAVE_conditional_compare, set
> LOGICAL_OP_NON_SHORT_CIRCUIT
>to optimize_function_for_speed_p. So we do not depend on BRANCH_COST.
> 2) Identify CCMP during expanding. A CCMP candidate is a BIT_AND_EXPR
>or BIT_IOR_EXPR, whose operators are compares.
> 3) Add a new op in optab to expand the CCMP to optimized RTL,

In addition to what Richi said, some comments on style/naming: Settle 
either on "ccmp" or "conditional_compare" (or some shorter variant) 
consistently, for the whole patch (as part of the patterns, as part of 
function names, as part of macro names).

+static bool
+is_conditional_compare_candidate_p (gimple g)
+{

Either is_ or _p, choose one, not a mix.  RTL code (and me) 
prefers the _p variant.


Ciao,
Michael.

[C++ Patch] PR 58457

[Paolo Carlini]

Hi,

in this 4.8/4.9 Regression having to do with using declarations we ICE 
at the gcc_assert in instantiate_type:


   gcc_assert (TREE_CODE (rhs) == ADDR_EXPR
   || TREE_CODE (rhs) == COMPONENT_REF
   || really_overloaded_fn (rhs)
   || (flag_ms_extensions && TREE_CODE (rhs) == FUNCTION_DECL));

because really_overloaded_fn (rhs) is false. Marek figured out that the 
ICE started with the representation change:


http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=184873

which means that OVERLOADs are *always* built for using-decls. Thus I 
think it could make sense to simply loosen a bit the gcc_assert. The 
below passes testing + fixes c++/57444 too.


Thanks,
Paolo.

//

/cp
2013-09-18

PR c++/58457
* class.c (instantiate_type): Loosen a bit the gcc_assert.

/testsuite
2013-09-18

PR c++/58457
* g++.dg/parse/using4.C: New.
Index: cp/class.c
===
--- cp/class.c  (revision 202703)
+++ cp/class.c  (working copy)
@@ -7627,7 +7627,7 @@ instantiate_type (tree lhstype, tree rhs, tsubst_f
  dependent on overload resolution.  */
   gcc_assert (TREE_CODE (rhs) == ADDR_EXPR
  || TREE_CODE (rhs) == COMPONENT_REF
- || really_overloaded_fn (rhs)
+ || is_overloaded_fn (rhs)
  || (flag_ms_extensions && TREE_CODE (rhs) == FUNCTION_DECL));
 
   /* This should really only be used when attempting to distinguish
Index: testsuite/g++.dg/parse/using4.C
===
--- testsuite/g++.dg/parse/using4.C (revision 0)
+++ testsuite/g++.dg/parse/using4.C (working copy)
@@ -0,0 +1,20 @@
+// PR c++/58457
+
+struct allocator
+{
+  void operator delete (void*);
+  void* operator new (__SIZE_TYPE__, void*);
+};
+
+struct type : public allocator
+{
+  type() {}
+  using allocator::operator new;
+  using allocator::operator delete;
+};
+
+int main()
+{
+  new (0) type;
+  return 0;
+}

Re: [PATCH v3 05/18] convert the C front end to automatic dependencies

[Tom Tromey]

Paolo> As I wrote in another reply, I suspect this breaks bootstrap with
Paolo> compilers that do not support "-c -o", if it is not broken yet.

It occurred to me this morning that AC_PROG_CC_C_O only checks the C
compiler, but we're generally using the C++ compiler for gcc now.  So I
think this was already all obsolete.

Tom

Re: [PATCH, committed] SH: Fix PR58314 (unsatisfied constraints)

[Christian Bruel]

Hi Oleg,

On 09/18/2013 02:59 PM, Oleg Endo wrote:
> On Wed, 2013-09-18 at 09:55 +0200, Christian Bruel wrote:
>> Hi Richard,
>>
>> On 09/16/2013 07:10 PM, Richard Sandiford wrote:
>>> Hi Christian,
>>>
>>> Christian Bruel  writes:
 @@ -6893,11 +6894,14 @@ label:
  ;; reloading MAC subregs otherwise.  For that probably special patterns
  ;; would be required.
  (define_insn "*mov_reg_reg"
 -  [(set (match_operand:QIHI 0 "arith_reg_dest" "=r")
 -  (match_operand:QIHI 1 "register_operand" "r"))]
 +  [(set (match_operand:QIHI 0 "arith_reg_dest" "=r,m,*z")
 +  (match_operand:QIHI 1 "register_operand" "r,*z,m"))]
>>> If the constraints allow "m", the predicates need to accept memories too.
>>> (It'd be worth having an insn condition that rejects both operands
>>> being memories though.)
>>>
>>> Thanks,
>>> Richard
>> Thanks for your comment,
>>
>> I was wondering this too when doing the fix. I felt that a memory
>> operand would be matched by the *movhi" patterns bellow.  As  I wanted
>> to fix only the spilling case, so the original operand is a pseudo reg
>> having matched the register predicate.
>> Without the predicate memory not found, I wonder how I never hit a kind
>> of "insn not found" error,  well, 'll give a try to adding a memory
>> condition in the predicate, 
>> but I fear that the movhi patterns will stop
>> to match,
> Yes, this will be the case.  The order of the movhi and movqi patterns
> in the md file is important.  To address the predicates vs. constraints
> issue, the following seems to work:
>
> (define_insn "*mov_reg_reg"
>   [(set (match_operand:QIHI 0 "general_movsrc_operand" "=r,m,*z")
>   (match_operand:QIHI 1 "general_movdst_operand" "r,*z,m"))]
>   "TARGET_SH1 && !t_reg_operand (operands[1], VOIDmode)
>&& (arith_reg_operand (operands[0], mode)
>|| arith_reg_operand (operands[1], mode))
>&& (!can_create_pseudo_p () && REG_P (operands[0]) && REG_P (operands[1]))"
>   "@
>   mov %1,%0
>   mov.%1,%0
>   mov.%1,%0"
>   [(set_attr "type" "move,store,load")])
>
> .. at least it survives the test case for this PR.  I haven't done
> further tests.

yes I agree (although it seems a weird idea of have a predicate set
larger that what the insn can accept :-),

I was validating a similar change, more simple:

(define_insn "*mov_reg_reg"
  [(set (match_operand:QIHI 0 "general_movsrc_operand" "=r,m,*z")
(match_operand:QIHI 1 "general_movdst_operand "r,*z,m"))]
  "TARGET_SH1 && !t_reg_operand (operands[1], VOIDmode)
   && arith_reg_operand (operands[0], mode)
   && arith_reg_operand (operands[1], mode))"

do you think your line :

&& (!can_create_pseudo_p () && REG_P (operands[0]) && REG_P (operands[1]))"

is necessary ?


>
> BTW, in the test case (gcc.target/sh/torture/pr58314.c), this 
>
> /* { dg-options "-Os" } */
>
> defeats the purpose of the torture tests.

does it ? I though that the dg-option would be a force it in addition to
the torture-option list (which should include -Os anyway, but it's just
to make sure). In my log I have

PASS: gcc.target/sh/torture/pr58314.c  -O0  (test for excess errors)
PASS: gcc.target/sh/torture/pr58314.c  -O1  (test for excess errors)
PASS: gcc.target/sh/torture/pr58314.c  -O2  (test for excess errors)
PASS: gcc.target/sh/torture/pr58314.c  -O3 -funroll-loops  (test for
excess errors)
PASS: gcc.target/sh/torture/pr58314.c  -O3 -funroll-all-loops
-finline-functions  (test for excess errors)
PASS: gcc.target/sh/torture/pr58314.c  -O3 -g  (test for excess errors)
PASS: gcc.target/sh/torture/pr58314.c  -Os  (test for excess errors)

Cheers

Christian

>
> Cheers,
> Oleg
>

[v3] More noexcept -- 3rd

[Marc Glisse]

Hello,

some more containers...

In debug array, we already have throw in noexcept functions, but if I
understand correctly it is only because of syntax limitations for constexpr
functions and aborts before throwing, although the use of
_GLIBCXX_THROW_OR_ABORT is suspicious. In any case, I am not changing this
with my patch.

I replaced throw with abort in list, as discussed, and thus removed the
corresponding testcase.

bootstrap+testsuite ok.

2013-09-19  Marc Glisse  

PR libstdc++/58338
* include/bits/stl_iterator.h (__normal_iterator) [__normal_iterator,
_M_const_cast, operator*, operator->, operator++, operator--,
operator[], operator+=, operator+, operator-=, operator-, base]:
Mark as noexcept.
(operator==(const __normal_iterator&, const __normal_iterator&),
operator!=(const __normal_iterator&, const __normal_iterator&),
operator<(const __normal_iterator&, const __normal_iterator&),
operator>(const __normal_iterator&, const __normal_iterator&),
operator<=(const __normal_iterator&, const __normal_iterator&),
operator>=(const __normal_iterator&, const __normal_iterator&),
operator-(const __normal_iterator&, const __normal_iterator&),
operator+(difference_type, const __normal_iterator&)): Likewise.
* include/bits/stl_list.h (list) [splice, _M_check_equal_allocators]:
Likewise.
(list::_M_check_equal_allocators): Abort instead of throwing.
* include/debug/array (array) [operator[], front, back]: Mark as
noexcept.
* include/profile/array (array) [operator[], front, back]: Likewise.
* include/std/array (array) [operator[], front, back]: Likewise.
* include/debug/list (list::splice): Likewise.
* include/profile/list (list::splice): Likewise.
* testsuite/23_containers/list/operations/5.cc: Remove file.
* testsuite/23_containers/list/operations/5.h: Likewise.

--
Marc GlisseIndex: include/bits/stl_iterator.h
===
--- include/bits/stl_iterator.h (revision 202699)
+++ include/bits/stl_iterator.h (working copy)
@@ -714,216 +714,232 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   typedef iterator_traits<_Iterator>   __traits_type;
 
 public:
   typedef _Iteratoriterator_type;
   typedef typename __traits_type::iterator_category iterator_category;
   typedef typename __traits_type::value_type   value_type;
   typedef typename __traits_type::difference_type  difference_type;
   typedef typename __traits_type::referencereference;
   typedef typename __traits_type::pointer  pointer;
 
-  _GLIBCXX_CONSTEXPR __normal_iterator() : _M_current(_Iterator()) { }
+  _GLIBCXX_CONSTEXPR __normal_iterator() _GLIBCXX_NOEXCEPT
+  : _M_current(_Iterator()) { }
 
   explicit
-  __normal_iterator(const _Iterator& __i) : _M_current(__i) { }
+  __normal_iterator(const _Iterator& __i) _GLIBCXX_NOEXCEPT
+  : _M_current(__i) { }
 
   // Allow iterator to const_iterator conversion
   template
 __normal_iterator(const __normal_iterator<_Iter,
  typename __enable_if<
   (std::__are_same<_Iter, typename _Container::pointer>::__value),
- _Container>::__type>& __i)
+ _Container>::__type>& __i) _GLIBCXX_NOEXCEPT
 : _M_current(__i.base()) { }
 
 #if __cplusplus >= 201103L
   __normal_iterator
-  _M_const_cast() const
+  _M_const_cast() const noexcept
   {
using _PTraits = std::pointer_traits;
return __normal_iterator
  (_PTraits::pointer_to(const_cast
(*_M_current)));
   }
 #else
   __normal_iterator
   _M_const_cast() const
   { return *this; }
 #endif
 
   // Forward iterator requirements
   reference
-  operator*() const
+  operator*() const _GLIBCXX_NOEXCEPT
   { return *_M_current; }
 
   pointer
-  operator->() const
+  operator->() const _GLIBCXX_NOEXCEPT
   { return _M_current; }
 
   __normal_iterator&
-  operator++()
+  operator++() _GLIBCXX_NOEXCEPT
   {
++_M_current;
return *this;
   }
 
   __normal_iterator
-  operator++(int)
+  operator++(int) _GLIBCXX_NOEXCEPT
   { return __normal_iterator(_M_current++); }
 
   // Bidirectional iterator requirements
   __normal_iterator&
-  operator--()
+  operator--() _GLIBCXX_NOEXCEPT
   {
--_M_current;
return *this;
   }
 
   __normal_iterator
-  operator--(int)
+  operator--(int) _GLIBCXX_NOEXCEPT
   { return __normal_iterator(_M_current--); }
 
   // Random access iterator requirements
   reference
-  operator[](difference_type __n) const
+  operator[](difference_type __n) const 

Re: [Patch] Implement regex_match and regex_search

[Tim Shen]

On Tue, Sep 17, 2013 at 4:35 AM, Paolo Carlini  wrote:
> Great. Tim, please complete the testing on -m32 etc, if everything goes
> well, just wait a day or so and commit.

Tested under -m32, -m64 and check-debug, and committed, with changing
the date of the new file to today.

Thank you!


-- 
Tim Shen

Re: [v3] More noexcept -- 3rd

[Jonathan Wakely]

On 18 September 2013 16:51, Marc Glisse wrote:
> Hello,
>
> some more containers...
>
> In debug array, we already have throw in noexcept functions, but if I
> understand correctly it is only because of syntax limitations for constexpr
> functions and aborts before throwing, although the use of
> _GLIBCXX_THROW_OR_ABORT is suspicious. In any case, I am not changing this
> with my patch.
>
> I replaced throw with abort in list, as discussed, and thus removed the
> corresponding testcase.
>
> bootstrap+testsuite ok.
>
> 2013-09-19  Marc Glisse  
>
> PR libstdc++/58338
> * include/bits/stl_iterator.h (__normal_iterator)
> [__normal_iterator,
> _M_const_cast, operator*, operator->, operator++, operator--,
> operator[], operator+=, operator+, operator-=, operator-, base]:
> Mark as noexcept.
> (operator==(const __normal_iterator&, const __normal_iterator&),
> operator!=(const __normal_iterator&, const __normal_iterator&),
> operator<(const __normal_iterator&, const __normal_iterator&),
> operator>(const __normal_iterator&, const __normal_iterator&),
> operator<=(const __normal_iterator&, const __normal_iterator&),
> operator>=(const __normal_iterator&, const __normal_iterator&),
> operator-(const __normal_iterator&, const __normal_iterator&),
> operator+(difference_type, const __normal_iterator&)): Likewise.
> * include/bits/stl_list.h (list) [splice,
> _M_check_equal_allocators]:
> Likewise.
> (list::_M_check_equal_allocators): Abort instead of throwing.
> * include/debug/array (array) [operator[], front, back]: Mark as
> noexcept.
> * include/profile/array (array) [operator[], front, back]: Likewise.
> * include/std/array (array) [operator[], front, back]: Likewise.
> * include/debug/list (list::splice): Likewise.
> * include/profile/list (list::splice): Likewise.
> * testsuite/23_containers/list/operations/5.cc: Remove file.
> * testsuite/23_containers/list/operations/5.h: Likewise.


This patch looks good to me, thanks again.

Re: [PATCH] manage dom-walk_data initialization and finalization with constructors and destructors

[Michael Matz]

Hello,

On Tue, 17 Sep 2013, Jeff Law wrote:

> I put the attached patch through a bootstrap and regression test cycle on
> x86_64-unknown-linux-gnu.  As expected no regressions.  Installed onto the
> trunk.
> 
> Thanks Trevor!

You missed one comment style nit, and some ChangeLog entry nits.

I'm irritated by the member name uglification (e.g. equiv_stack_ with 
trailing underscore).  I know that's a certain style to mark private 
members, but I think it's a bad style (like prefixing variable names with 
their type), and before it sets a precedent in GCCs c++ coding style I'd 
like this to be changed, like in the below.

I'd also like us to not use member privatization in our classes, but 
that's not in the patch, but if we could agree on that it would be nice.

Regstrapped on x86-64-linux, okay?


Ciao,
Michael.

* domwalk.h (dom_walker::dom_direction_): Rename to dom_direction.
* domwalk.c (dom_walker::walk): Adjust.
* graphite-sese-to-poly.c (sese_dom_walker::region_): Rename to
region.
(sese_dom_walker::sese_dom_walker, sese_dom_walker::~sese_dom_walker,
sese_dom_walker::before_dom_children,
sese_dom_walker::after_dom_children): Adjust.
* tree-into-ssa.c (mark_def_dom_walker::kills_): Rename to
kills.
(mark_def_dom_walker::mark_def_dom_walker,
mark_def_dom_walker::before_dom_children): Adjust.
* tree-ssa-dom.c (dom_opt_dom_walker::dummy_cond_): Rename to
dummy_cond.
(dom_opt_dom_walker::thread_across_edge): Adjust.
* tree-ssa-loop-im.c (move_computations_dom_walker::todo_): Rename
to todo.
(move_computations_dom_walker::before_dom,
move_computations): Adjust.
* tree-ssa-phiopt.c (nontrapping_dom_walker::nontrapping_): Rename
to nontrapping.
(nontrapping_dom_walker::before_dom_child): Adjust.
* tree-ssa-uncprop.c (uncprop_dom_walker::equiv_stack_): Rename
to equiv_stack.
(uncprop_dom_walker::uncprop_dom_walker,
uncprop_dom_walker::~uncprop_dom_walker,
uncprop_dom_walker::after_dom_children): Adjust.

Index: domwalk.h
===
--- domwalk.h   (revision 202698)
+++ domwalk.h   (working copy)
@@ -21,16 +21,14 @@ along with GCC; see the file COPYING3.
 #ifndef GCC_DOM_WALK_H
 #define GCC_DOM_WALK_H
 
-/**
- * This is the main class for the dominator walker. It is expected that
- * consumers will have a custom class inheriting from it, which will over ride
- * at least one of before_dom_children and after_dom_children to implement the
- * custom behavior.
- */
+/* This is the main class for the dominator walker.  It is expected that
+   consumers will have a custom class inheriting from it, which will over ride
+   at least one of before_dom_children and after_dom_children to implement the
+   custom behavior.  */
 class dom_walker
 {
 public:
-  dom_walker (cdi_direction direction) : dom_direction_ (direction) {}
+  dom_walker (cdi_direction direction) : dom_direction (direction) {}
 
   /* Walk the dominator tree.  */
   void walk (basic_block);
@@ -46,7 +44,7 @@ private:
  if it is set to CDI_DOMINATORS, then we walk the dominator tree,
  if it is set to CDI_POST_DOMINATORS, then we walk the post
  dominator tree.  */
-  const ENUM_BITFIELD (cdi_direction) dom_direction_ : 2;
+  const ENUM_BITFIELD (cdi_direction) dom_direction : 2;
 };
 
 #endif
Index: domwalk.c
===
--- domwalk.c   (revision 202698)
+++ domwalk.c   (working copy)
@@ -154,7 +154,7 @@ dom_walker::walk (basic_block bb)
   int sp = 0;
   int *postorder, postorder_num;
 
-  if (dom_direction_ == CDI_DOMINATORS)
+  if (dom_direction == CDI_DOMINATORS)
 {
   postorder = XNEWVEC (int, n_basic_blocks);
   postorder_num = inverted_post_order_compute (postorder);
@@ -181,10 +181,10 @@ dom_walker::walk (basic_block bb)
  worklist[sp++] = NULL;
 
  int saved_sp = sp;
- for (dest = first_dom_son (dom_direction_, bb);
-  dest; dest = next_dom_son (dom_direction_, dest))
+ for (dest = first_dom_son (dom_direction, bb);
+  dest; dest = next_dom_son (dom_direction, dest))
worklist[sp++] = dest;
- if (dom_direction_ == CDI_DOMINATORS)
+ if (dom_direction == CDI_DOMINATORS)
switch (sp - saved_sp)
  {
  case 0:
@@ -210,7 +210,7 @@ dom_walker::walk (basic_block bb)
   else
break;
 }
-  if (dom_direction_ == CDI_DOMINATORS)
+  if (dom_direction == CDI_DOMINATORS)
 {
   free (bb_postorder);
   bb_postorder = NULL;
Index: graphite-sese-to-poly.c
===
--- graphite-sese-to-poly.c (revision 202698)
+++ graphite-sese-to-poly.c (working copy)
@@ -1226,21 +1226,21 @@ public:
   virtual void after_dom_chi

Re: [v3] More noexcept -- 3rd

[Marc Glisse]

On Wed, 18 Sep 2013, Paolo Carlini wrote:

On 09/18/2013 05:51 PM, Marc Glisse wrote:

In debug array, we already have throw in noexcept functions, but if I
understand correctly it is only because of syntax limitations for constexpr
functions and aborts before throwing, although the use of
_GLIBCXX_THROW_OR_ABORT is suspicious. In any case, I am not changing this
with my patch.
If I remember correctly, somebody invented that mild hack and suggested it to 
indeed have a check as part of a constexpr function, not a trivial task. Jon 
participated to that discussion. After a while I resurrected that old 
discussion, tested the code and it appeared to work well. In practice, are 
you experiencing specific problems with it?


No, no problem. For some reason I thought there would be issues when the 
macro expands to __builtin_abort(), but there aren't, great.


Any other comments on the patch? (Jon's "great" doesn't really sound like 
an "ok")


--
Marc Glisse

Re: [v3] More noexcept -- 3rd

[Paolo Carlini]

Hi,

On 09/18/2013 05:51 PM, Marc Glisse wrote:

Hello,

some more containers...

In debug array, we already have throw in noexcept functions, but if I
understand correctly it is only because of syntax limitations for 
constexpr

functions and aborts before throwing, although the use of
_GLIBCXX_THROW_OR_ABORT is suspicious. In any case, I am not changing 
this

with my patch.
If I remember correctly, somebody invented that mild hack and suggested 
it to indeed have a check as part of a constexpr function, not a trivial 
task. Jon participated to that discussion. After a while I resurrected 
that old discussion, tested the code and it appeared to work well. In 
practice, are you experiencing specific problems with it?


Thanks,
Paolo.

Re: [v3] More noexcept -- 3rd

[Jonathan Wakely]

On 18 September 2013 17:27, Marc Glisse  wrote:
> On Wed, 18 Sep 2013, Paolo Carlini wrote:
>>
>> On 09/18/2013 05:51 PM, Marc Glisse wrote:
>>>
>>> In debug array, we already have throw in noexcept functions, but if I
>>> understand correctly it is only because of syntax limitations for
>>> constexpr
>>> functions and aborts before throwing, although the use of
>>> _GLIBCXX_THROW_OR_ABORT is suspicious. In any case, I am not changing
>>> this
>>> with my patch.
>>
>> If I remember correctly, somebody invented that mild hack and suggested it
>> to indeed have a check as part of a constexpr function, not a trivial task.
>> Jon participated to that discussion. After a while I resurrected that old
>> discussion, tested the code and it appeared to work well. In practice, are
>> you experiencing specific problems with it?
>
>
> No, no problem. For some reason I thought there would be issues when the
> macro expands to __builtin_abort(), but there aren't, great.
>
> Any other comments on the patch? (Jon's "great" doesn't really sound like an
> "ok")

It wasn't, as I hadn't reviewed the patch at that time, but I sent
another mail with an "ok" after reading it :)

Re: [v3] More noexcept -- 3rd

[Jonathan Wakely]

On 18 September 2013 17:00, Paolo Carlini wrote:
> Hi,
>
>
> On 09/18/2013 05:51 PM, Marc Glisse wrote:
>>
>> Hello,
>>
>> some more containers...

Great, thanks for working your way through all these!

>> In debug array, we already have throw in noexcept functions, but if I
>> understand correctly it is only because of syntax limitations for
>> constexpr
>> functions and aborts before throwing, although the use of
>> _GLIBCXX_THROW_OR_ABORT is suspicious. In any case, I am not changing this
>> with my patch.
>
> If I remember correctly, somebody invented that mild hack and suggested it
> to indeed have a check as part of a constexpr function, not a trivial task.
> Jon participated to that discussion.

I think that old discussion was in the "Should _GLIBCXX_DEBUG affect
tr1/array?" thread in January 2012.

> After a while I resurrected that old
> discussion, tested the code and it appeared to work well. In practice, are
> you experiencing specific problems with it?

Re: [PATCH] manage dom-walk_data initialization and finalization with constructors and destructors

[Jeff Law]

On 09/18/2013 10:24 AM, Michael Matz wrote:


I'm irritated by the member name uglification (e.g. equiv_stack_ with
trailing underscore).  I know that's a certain style to mark private
members, but I think it's a bad style (like prefixing variable names with
their type), and before it sets a precedent in GCCs c++ coding style I'd
like this to be changed, like in the below.
We're already using the trailing underscore idiom for private objects 
moving into classes (see the pass class).  Furthermore, we've used 
similar idioms in the past when moving objects from the global namespace 
into structures (the x_ prefixing you'll find in various structures).


You really should have chimed in before now.



I'd also like us to not use member privatization in our classes, but
that's not in the patch, but if we could agree on that it would be nice.
Member privatization is quite natural.  What specifically do you not 
like about the practice?


Regstrapped on x86-64-linux, okay?
Obviously any ChangeLog, formatting and such can go in.  However, the 
trailing underscore should stay given it's already established practice 
and has several nice benefits.


jeff

[GOOGLE] disable slp for AutoFDO

[Dehao Chen]

This patch disables SLP for AutoFDO.

Bootstrapped and passed unittests.

OK for google-4_8?

Thanks,
Dehao

Index: gcc/opts.c
===
--- gcc/opts.c (revision 202709)
+++ gcc/opts.c (working copy)
@@ -1661,9 +1661,6 @@ common_handle_option (struct gcc_options *opts,
   if (!opts_set->x_flag_tree_loop_vectorize
   && !opts_set->x_flag_tree_vectorize)
  opts->x_flag_tree_loop_vectorize = value;
-  if (!opts_set->x_flag_tree_slp_vectorize
-  && !opts_set->x_flag_tree_vectorize)
- opts->x_flag_tree_slp_vectorize = value;
   if (!opts_set->x_flag_vect_cost_model)
  opts->x_flag_vect_cost_model = value;
   if (!opts_set->x_flag_tree_loop_distribute_patterns)

Re: [PATCH v3 05/18] convert the C front end to automatic dependencies

[Mike Stump]

On Sep 18, 2013, at 8:36 AM, Tom Tromey  wrote:
> It occurred to me this morning that AC_PROG_CC_C_O only checks the C
> compiler, but we're generally using the C++ compiler for gcc now.  So I
> think this was already all obsolete.

The reality is that checking the C compiler is likely enough on all the systems 
we care about; though, it is non-optimal…

Re: [PATCH] manage dom-walk_data initialization and finalization with constructors and destructors

[Michael Matz]

Hi,

On Wed, 18 Sep 2013, Jeff Law wrote:

> On 09/18/2013 10:24 AM, Michael Matz wrote:
> > 
> > I'm irritated by the member name uglification (e.g. equiv_stack_ with
> > trailing underscore).  I know that's a certain style to mark private
> > members, but I think it's a bad style (like prefixing variable names with
> > their type), and before it sets a precedent in GCCs c++ coding style I'd
> > like this to be changed, like in the below.
> 
> We're already using the trailing underscore idiom for private objects 
> moving into classes (see the pass class).

I know, and I don't like it there either.

> Furthermore, we've used similar idioms in the past when moving objects 
> from the global namespace into structures (the x_ prefixing you'll find 
> in various structures).

Yes, but that is usually done to not confuse ourself when there are 
accessor macros of the same name as the accessed member/variable, i.e. 
when we want to make really sure that we never, from no code, access the 
variable itself.  I.e. the uglification serves the purpose of avoiding 
access to that name.

That's not the case with these class members.  They are quite clearly 
accessed in all the member functions, and they are intended to be accessed 
from them.  So they should have no uglified name.

> You really should have chimed in before now.

Yes I should have, but better late than never.  As of now it's no trend of 
uglification yet, the only preexisting cases of the same type (uglified 
class member names) are the pass manager and bit_field_mode_iterator, both 
fairly recent.  The other case (vec.h) should have been changed to 
non-ugly names when it was converted to classes.  In any case we should 
not introduce more of these.

> > I'd also like us to not use member privatization in our classes, but
> > that's not in the patch, but if we could agree on that it would be nice.
> Member privatization is quite natural.  What specifically do you not like
> about the practice?

http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00302.html

That was conditional on "when we need to jump through hoops", but for 
constistency it'd make sense to avoid it everywhere.
(I know that Ian agreed to that mail, but somehow the mailing list 
archives don't have that!?)

> > Regstrapped on x86-64-linux, okay?
> 
> Obviously any ChangeLog, formatting and such can go in.  However, the 
> trailing underscore should stay given it's already established practice 
> and has several nice benefits.

What's the benefit of reading and writing such noisy lines? :

  *out_mode = mode_;
  mode_ = GET_MODE_WIDER_MODE (mode_);
  count_++;

The uglification merely makes code harder to write and read, it should be 
used in cases where you _don't_ want developers to write such names.


Ciao,
Michael.

Re: [C++ Patch] PR 58457

[Jason Merrill]

OK.

Jason

Re: [PATCH] RTEMS: Add LEON3/SPARC multilibs

[Ralf Corsépius]

On 09/17/2013 08:12 PM, Joel Sherrill wrote:

Committed to the head.

Is this too radical to also go on the 4.8 branch?
We would need to discuss it on the RTEMS side but it
only impacts us if the multilib is there for sparc-elf
on 4.8.


Not quite. The problem is not GCC-4.8 vs. GCC-4.9, the problems are in 
RTEMS.


Why? sparc-rtems*gccs < 4.8 doesn't support -mcpu=leon3 and thus will 
abort when -mcpu=leon3 will be used.


I.e. you
a) CANNOT use -mcpu=leon3 in RTEMS's bsp_specs and in RTEMS cpukit, 
until the toolchains are guaranteed to support it.

or
b) MUST backport -mcpu=leon3 to GCC-4.8

In other words, if you are sure leon3 works with GCC-4.8, you'd better 
off backporting this to GCC-4.8. If there are known bugs in 
GCC-4.8/leon3, you'd better of not using -mcpu=leon3 in RTEMS.


To my knowledge, GCC up to 4.8.1 doesn't support -mcpu=leon3 at all, but 
I don't know about the status on current gcc-4_8-branch.


Ralf

Re: [GOOGLE] disable slp for AutoFDO

[Xinliang David Li]

Ok.

David

On Wed, Sep 18, 2013 at 10:21 AM, Dehao Chen  wrote:
> This patch disables SLP for AutoFDO.
>
> Bootstrapped and passed unittests.
>
> OK for google-4_8?
>
> Thanks,
> Dehao
>
> Index: gcc/opts.c
> ===
> --- gcc/opts.c (revision 202709)
> +++ gcc/opts.c (working copy)
> @@ -1661,9 +1661,6 @@ common_handle_option (struct gcc_options *opts,
>if (!opts_set->x_flag_tree_loop_vectorize
>&& !opts_set->x_flag_tree_vectorize)
>   opts->x_flag_tree_loop_vectorize = value;
> -  if (!opts_set->x_flag_tree_slp_vectorize
> -  && !opts_set->x_flag_tree_vectorize)
> - opts->x_flag_tree_slp_vectorize = value;
>if (!opts_set->x_flag_vect_cost_model)
>   opts->x_flag_vect_cost_model = value;
>if (!opts_set->x_flag_tree_loop_distribute_patterns)

patch to fix PR58348

[Vladimir Makarov]

The following patch fixes

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

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

Committed as rev. 202714.

2013-09-18  Vladimir Makarov  

PR rtl-optimization/58438
* lra.c (lra): Clear lra_optional_reload_pseudos in upper loop.
* lra-constraints.c (undo_optional_reloads): Keep optional reloads
from previous subpasses.

2013-09-18  Vladimir Makarov  

PR rtl-optimization/58438
* g++.dg/pr58438.C: New test.

Index: lra.c
===
--- lra.c	(revision 202626)
+++ lra.c	(working copy)
@@ -2315,7 +2315,6 @@ lra (FILE *f)
 {
   for (;;)
 	{
-	  bitmap_clear (&lra_optional_reload_pseudos);
 	  /* We should try to assign hard registers to scratches even
 	 if there were no RTL transformations in
 	 lra_constraints.  */
@@ -2367,6 +2366,9 @@ lra (FILE *f)
 		lra_clear_live_ranges ();
 	}
 	}
+  /* Don't clear optional reloads bitmap until all constraints are
+	 satisfied as we need to differ them from regular reloads.  */
+  bitmap_clear (&lra_optional_reload_pseudos);
   bitmap_clear (&lra_subreg_reload_pseudos);
   bitmap_clear (&lra_inheritance_pseudos);
   bitmap_clear (&lra_split_regs);
Index: lra-constraints.c
===
--- lra-constraints.c	(revision 202630)
+++ lra-constraints.c	(working copy)
@@ -5456,10 +5456,12 @@ undo_optional_reloads (void)
   EXECUTE_IF_SET_IN_BITMAP (&lra_optional_reload_pseudos, 0, regno, bi)
 {
   keep_p = false;
-  if (reg_renumber[lra_reg_info[regno].restore_regno] >= 0)
-	/* If the original pseudo changed its allocation, just
-	   removing the optional pseudo is dangerous as the original
-	   pseudo will have longer live range.  */
+  /* Keep optional reloads from previous subpasses.  */
+  if (lra_reg_info[regno].restore_regno < 0
+	  /* If the original pseudo changed its allocation, just
+	 removing the optional pseudo is dangerous as the original
+	 pseudo will have longer live range.  */
+	  || reg_renumber[lra_reg_info[regno].restore_regno] >= 0)
 	keep_p = true;
   else if (reg_renumber[regno] >= 0)
 	EXECUTE_IF_SET_IN_BITMAP (&lra_reg_info[regno].insn_bitmap, 0, uid, bi2)

Re: patch to fix PR58335

[Vladimir Makarov]

On 09/12/2013 02:27 PM, Vladimir Makarov wrote:
>   The following patch fixes
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58335
>
>   It required to implement a new approach for elimination updates for
> insn frame_pointer = hard_frame_pointer + offset.  The previous
> implementation used parsing insns generated for offset elimination for
> given insn.  It is hard to parse all possible variants for such
> elimination on different targets.  For example, s390 code is quite
> different from x86/x86-64 code and that was the reason for the PR.
> The new implementation uses temporarily REG_EQUAL notes to avoid
> generated insns
> parsing.  It solves the problem and makes LRA more portable.
>
>   The patch was successfully bootstrapped and tested on x86/x86-64 and s390.
>
> Committed as rev. 202536.

It is actually 202714.
>
> 2013-09-12  Vladimir Makarov  
>
> PR middle-end/58335
> * lra-eliminations.c (remove_reg_equal_offset_note): New.
> (eliminate_regs_in_insn): Rewrite frame pointer to hard frame
> pointer elimination with using remove_reg_equal_offset_note.
>
Sorry, I missed to commit the test suite.

The patch is in attachment.

Committed as rev. 202715.

Index: testsuite/g++.dg/pr58438.C
===
--- testsuite/g++.dg/pr58438.C	(revision 0)
+++ testsuite/g++.dg/pr58438.C	(working copy)
@@ -0,0 +1,45 @@
+/* { dg-do compile { target i?86-*-* x86_64-*-* } } */
+/* { dg-options "-march=amdfam10 -O3 -fprofile-generate" } */
+enum gimple_code {};
+struct A {
+  gimple_code code;
+};
+struct B {
+  A gsbase;
+};
+int **a;
+int b, d, e, f, g, h, i, j, k, l, m, n, o;
+gimple_code c, p;
+class C {
+  virtual unsigned m_fn1();
+};
+B q;
+static int fn1() {
+  int r;
+  if (k)
+i = 0;
+  for (; i; j++) {
+b = c <= 0;
+if (b)
+  n = *a[0];
+b = p && c;
+if (b)
+  r = *a[0];
+b = q.gsbase.code && c;
+if (b)
+  o = *a[0];
+m = o;
+if (e || 1 & r || d || l)
+  return 0;
+  }
+}
+
+class D : C {
+  unsigned m_fn1() {
+fn1();
+for (; h; g++)
+  for (;; f++)
+;
+  }
+};
+void fn2() { new D; }

Go patch committed: Fix bug in type of shortcut operation

[Ian Lance Taylor]

When the Go frontend converts a shortcut operator like && or || to an if
statement, it used the wrong type for the temporary variable.  It always
used bool, but the operator could be using a named version of bool.
This matters when the type has methods.  This patch fixes the problem.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline and 4.8 branch.

Ian

diff -r 35afa97b6c21 go/gogo.cc
--- a/go/gogo.cc	Tue Sep 17 15:09:45 2013 -0700
+++ b/go/gogo.cc	Wed Sep 18 11:30:33 2013 -0700
@@ -2367,7 +2367,7 @@
   Block* retblock = new Block(enclosing, loc);
   retblock->set_end_location(loc);
 
-  Temporary_statement* ts = Statement::make_temporary(Type::lookup_bool_type(),
+  Temporary_statement* ts = Statement::make_temporary(shortcut->type(),
 		  left, loc);
   retblock->add_statement(ts);
 

patch to support HARD_REGNO_CALL_PART_CLOBBERED in LRA

[Vladimir Makarov]

Yvan Roux working on porting LRA to AARCH64 reported that LRA does not
support macro HARD_REGNO_CALL_PART_CLOBBERED.

Here is the patch implementing such support.  Yvan wrote me that the
patch solves the problem (removing some gcc testsuite failures).

The patch was bootstrapped on x86/x86-64.

Committed as rev. 202721.

2013-09-18  Vladimir Makarov  

* lra-constraints.c (need_for_all_save_p): Use macro
HARD_REGNO_CALL_PART_CLOBBERED.
* lra-lives.c (check_pseudos_live_through_calls): Use the macro to
set up pseudo conflict hard regs.

Index: lra-constraints.c
===
--- lra-constraints.c	(revision 202714)
+++ lra-constraints.c	(working copy)
@@ -4335,7 +4335,9 @@ need_for_call_save_p (int regno)
   return (usage_insns[regno].calls_num < calls_num
 	  && (overlaps_hard_reg_set_p
 	  (call_used_reg_set,
-	   PSEUDO_REGNO_MODE (regno), reg_renumber[regno])));
+	   PSEUDO_REGNO_MODE (regno), reg_renumber[regno])
+	  || HARD_REGNO_CALL_PART_CLOBBERED (reg_renumber[regno],
+		 PSEUDO_REGNO_MODE (regno;
 }
 
 /* Global registers occurring in the current EBB.  */
Index: lra-lives.c
===
--- lra-lives.c	(revision 202626)
+++ lra-lives.c	(working copy)
@@ -457,11 +457,17 @@ lra_setup_reload_pseudo_preferenced_hard
 static inline void
 check_pseudos_live_through_calls (int regno)
 {
+  int hr;
+
   if (! sparseset_bit_p (pseudos_live_through_calls, regno))
 return;
   sparseset_clear_bit (pseudos_live_through_calls, regno);
   IOR_HARD_REG_SET (lra_reg_info[regno].conflict_hard_regs,
 		call_used_reg_set);
+
+  for (hr = 0; hr < FIRST_PSEUDO_REGISTER; hr++)
+if (HARD_REGNO_CALL_PART_CLOBBERED (hr, PSEUDO_REGNO_MODE (regno)))
+  SET_HARD_REG_BIT (lra_reg_info[regno].conflict_hard_regs, hr);
 #ifdef ENABLE_CHECKING
   lra_reg_info[regno].call_p = true;
 #endif

Re: [patch] Make cxxfilt demangle internal-linkage templates

[Paul Pluzhnikov]

Ping x3?

2013/9/11 Paul Pluzhnikov :
> Ping x2?
>
> Original message:
> http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00394.html

Thanks,
-- 
Paul Pluzhnikov

Re: [PATCH] Fix PR58417 -- r202700 appears to be causing ICEs

[Paul Pluzhnikov]

Richard,

I am seeing ICEs in libstdc++ make check that I didn't see yesterday:


spawn /home/ppluzhnikov/Archive/gcc-svn/build/./gcc/xg++
-shared-libgcc -B/home/ppluzhnikov/Archive/gcc-svn/build/./gcc
-nostdinc++ 
-L/home/ppluzhnikov/Archive/gcc-svn/build/x86_64-unknown-linux-gnu/libstdc++-v3/src
-L/home/ppluzhnikov/Archive/gcc-svn/build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home/ppluzhnikov/Archive/gcc-svn/build/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/home/ppluzhnikov/Archive/gcc-svn-install/x86_64-unknown-linux-gnu/bin/
-B/home/ppluzhnikov/Archive/gcc-svn-install/x86_64-unknown-linux-gnu/lib/
-isystem 
/home/ppluzhnikov/Archive/gcc-svn-install/x86_64-unknown-linux-gnu/include
-isystem 
/home/ppluzhnikov/Archive/gcc-svn-install/x86_64-unknown-linux-gnu/sys-include
-B/home/ppluzhnikov/Archive/gcc-svn/build/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections
-fdata-sections -g -O2 -D_GNU_SOURCE -g -O2 -D_GNU_SOURCE
-DLOCALEDIR="." -nostdinc++
-I/home/ppluzhnikov/Archive/gcc-svn/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu
-I/home/ppluzhnikov/Archive/gcc-svn/build/x86_64-unknown-linux-gnu/libstdc++-v3/include
-I/home/ppluzhnikov/Archive/gcc-svn/libstdc++-v3/libsupc++
-I/home/ppluzhnikov/Archive/gcc-svn/libstdc++-v3/include/backward
-I/home/ppluzhnikov/Archive/gcc-svn/libstdc++-v3/testsuite/util
/home/ppluzhnikov/Archive/gcc-svn/libstdc++-v3/testsuite/ext/random/normal_mv_distribution/cons/default.cc
-std=c++0x ./libtestc++.a -Wl,--gc-sections -lm -o ./default.exe
/home/ppluzhnikov/Archive/gcc-svn/libstdc++-v3/testsuite/ext/random/normal_mv_distribution/cons/default.cc:
In constructor '__gnu_cxx::normal_mv_distribution<_Dimen,
_RealType>::param_type::param_type() [with long unsigned int _Dimen =
2ul; _RealType = double]':
/home/ppluzhnikov/Archive/gcc-svn/libstdc++-v3/testsuite/ext/random/normal_mv_distribution/cons/default.cc:49:1:
internal compiler error: in build_polynomial_chrec, at
tree-chrec.h:148
 }
 ^
0xf57001 build_polynomial_chrec
../../gcc/tree-chrec.h:148
0xf5b8ab chrec_fold_plus_1
../../gcc/tree-chrec.c:321
0xf5c441 chrec_fold_plus_poly_poly
../../gcc/tree-chrec.c:153
0xf5c441 chrec_fold_plus_1
../../gcc/tree-chrec.c:279
0xb6ef7a interpret_rhs_expr
../../gcc/tree-scalar-evolution.c:1692
0xb6fecd interpret_gimple_assign
../../gcc/tree-scalar-evolution.c:1810
0xb6fecd analyze_scalar_evolution_1
../../gcc/tree-scalar-evolution.c:1892
0xb707b2 analyze_scalar_evolution(loop*, tree_node*)
../../gcc/tree-scalar-evolution.c:1947
0xb73667 analyze_scalar_evolution_in_loop
../../gcc/tree-scalar-evolution.c:2043
0xb73eaf simple_iv(loop*, loop*, tree_node*, affine_iv*, bool)
../../gcc/tree-scalar-evolution.c:3167
0x9817c6 estimate_function_body_sizes
../../gcc/ipa-inline-analysis.c:2563
0x9822e0 compute_inline_parameters(cgraph_node*, bool)
../../gcc/ipa-inline-analysis.c:2696
0x982630 inline_analyze_function
../../gcc/ipa-inline-analysis.c:3684
0x9827c7 inline_generate_summary()
../../gcc/ipa-inline-analysis.c:3735
0xa30df6 execute_ipa_summary_passes(ipa_opt_pass_d*)
../../gcc/passes.c:2000
0x7e8844 ipa_passes
../../gcc/cgraphunit.c:2008
0x7e8844 compile()
../../gcc/cgraphunit.c:2115
0x7e8a89 finalize_compilation_unit()
../../gcc/cgraphunit.c:2269
0x5fcc20 cp_write_global_declarations()
../../gcc/cp/decl2.c:4360
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
compiler exited with status 1


Perhaps they are related to your commit:


r202700 | rguenth | 2013-09-18 05:31:45 -0700 (Wed, 18 Sep 2013) | 25 lines

2013-09-18  Richard Biener  

PR tree-optimization/58417
* tree-chrec.c (chrec_fold_plus_1): Assert that we do not
have chrecs with symbols defined in the loop as operands.
(chrec_fold_multiply): Likewise.
* tree-scalar-evolution.c (interpret_rhs_expr): Instantiate
parameters before folding binary operations.
(struct instantiate_cache_entry_hasher): Remove.
(struct instantiate_cache_type): Use a pointer-map.
(instantiate_cache_type::instantiate_cache_type): New function.
(instantiate_cache_type::get): Likewise.
(instantiate_cache_type::set): Likewise.
(instantiate_cache_type::~instantiate_cache_type): Adjust.
(get_instantiated_value_entry): Likewise.
(global_cache): New global.
(instantiate_scev_r, instantiate_scev_poly, instantiate_scev_binary,
instantiate_array_ref, instantiate_scev_convert, instantiate_scev_3,
instantiate_scev_2, instantiate_scev_1): Do not pass along cache.
(instantiate_scev_name): Adjust.
(instantiate_scev): Construct global instead 

Re: [patch] Make vector::at() assertion message more useful (try #2)

[Paul Pluzhnikov]

On Fri, Sep 13, 2013 at 3:02 AM, Paolo Carlini  wrote:

> - The game with the variadic and the non-variadic __throw_out_of_range makes
> me a little nervous. Let's just name the new one differently, like
> __throw_out_of_range_var.

Replaced with __throw_out_of_range_fmt.

> - Please consistently use __builtin_alloca everywhere, alloca isn't a
> standard function.

Done.

> - I would rather call the file itself snprintf_lite.cc, in order not to fool
> somebody that it actually implements the whole snprintf.

Done.

> - I'm a bit confused about __concat_size_t returning -1. Since it only
> formats integers, I think we can be *sure* that the buffer is big enough.

How so? The caller could do this:

  __snprintf_lite("aaa: %zu, 8, 12345678);

By the time we get to __concat_size_t, we only have 3 characters left.

> Then, if it returns -1 something is going *very badly* wrong, shouldn't we
> __builtin_abort() or something similar?

I've re-worked this part -- if this ever happens, throw a logic_error with
a message to file a bug.

> - In terms of buffer sizes, this comment:
>
> // enough for expanding up to 5 size_t's in the format.
>
> and then the actual code in __snprintf_lite makes me a little nervous.
> Agreed, we are not going to overflow the buffer, but truncating with no
> diagnostic whatsoever seems rather gross. We can probably sort out this
> later, new ideas welcome, anyway.

Re-worked.

> - While we are at it, shouldn't we use the new facility at least in array,
> vector and deque too? For consistency over the containers.

Done.

I also expanded snprintf_lite to handle '%s', as that comes handy inside
string _M_check.

Thanks,

P.S. In the process of updating callers of __throw_out_of_range, I've
discovered that two of them had already used __builtin_sprintf.

P.P.S. Sorry this patch grew ... I can split it into parts if that's easier
to review.


-- 
Paul Pluzhnikov


libstdc++-v3/ChangeLog:

* include/bits/functexcept.h (__throw_out_of_range_fmt): New.
* src/c++11/functexcept.cc (__throw_out_of_range_fmt): New.
* src/c++11/snprintf_lite.cc: New.
* src/c++11/Makefile.am: Add snprintf_lite.cc.
* src/c++11/Makefile.in: Regenerate.
* config/abi/pre/gnu.ver: Add _ZSt24__throw_out_of_range_fmtPKcz.
* include/std/array (at): Use __throw_out_of_range_fmt.
* include/debug/array (at): Likewise.
* include/profile/array (at): Likewise.
* include/std/bitset (_M_check_initial_position, _M_check): New.
(bitset::bitset): Use _M_check_initial_position.
(set, reset, flip, test): Use _M_check.
* include/ext/vstring.h (_M_check, at): Use __throw_out_of_range_fmt.
* include/bits/stl_vector.h (_M_range_check): Likewise.
* include/bits/stl_bvector.h (_M_range_check): Likewise.
* include/bits/stl_deque.h (_M_range_check): Likewise.
* include/bits/basic_string.h (_M_check, at): Likewise.
* testsuite/23_containers/vector/requirements/dr438/assign_neg.cc: 
Adjust.
* testsuite/23_containers/vector/requirements/dr438/insert_neg.cc: 
Likewise.
* 
testsuite/23_containers/vector/requirements/dr438/constructor_1_neg.cc:
Likewise.
* 
testsuite/23_containers/vector/requirements/dr438/constructor_2_neg.cc:
Likewise.
* testsuite/23_containers/deque/requirements/dr438/assign_neg.cc: 
Likewise.
* testsuite/23_containers/deque/requirements/dr438/insert_neg.cc: 
Likewise.
* testsuite/23_containers/deque/requirements/dr438/constructor_1_neg.cc:
Likewise.
* testsuite/23_containers/deque/requirements/dr438/constructor_2_neg.cc:
Likewise.
* testsuite/23_containers/array/tuple_interface/tuple_element_neg.cc: 
Likewise.
* testsuite/23_containers/array/tuple_interface/get_neg.cc: Likewise.
* testsuite/util/exception/safety.h (generate): Use 
__throw_out_of_range_fmt.
Index: libstdc++-v3/include/bits/functexcept.h
===
--- libstdc++-v3/include/bits/functexcept.h (revision 202709)
+++ libstdc++-v3/include/bits/functexcept.h (working copy)
@@ -75,6 +75,10 @@
   __throw_out_of_range(const char*) __attribute__((__noreturn__));
 
   void
+  __throw_out_of_range_fmt(const char*, ...) __attribute__((__noreturn__))
+__attribute__((__format__(__printf__, 1, 2)));
+
+  void
   __throw_runtime_error(const char*) __attribute__((__noreturn__));
 
   void
Index: libstdc++-v3/src/c++11/functexcept.cc
===
--- libstdc++-v3/src/c++11/functexcept.cc   (revision 202709)
+++ libstdc++-v3/src/c++11/functexcept.cc   (working copy)
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef _GLIBCXX_USE_NLS
 # include 
@@ -39,6 +40,12 @@
 # define _(msgid)   (msgid)
 #endif
 
+namespace __gnu_cxx
+{
+  int __snprintf_lite(char *__buf, size_t __bufsize, const char *__fmt,
+   

Re: New GCC options for loop vectorization

[Xinliang David Li]

On Tue, Sep 17, 2013 at 1:20 AM, Richard Biener
 wrote:
> On Mon, Sep 16, 2013 at 10:24 PM, Xinliang David Li  
> wrote:
>> On Mon, Sep 16, 2013 at 3:13 AM, Richard Biener
>>  wrote:
>>> On Fri, Sep 13, 2013 at 5:16 PM, Xinliang David Li  
>>> wrote:
 On Fri, Sep 13, 2013 at 1:30 AM, Richard Biener
  wrote:
> On Thu, Sep 12, 2013 at 10:31 PM, Xinliang David Li  
> wrote:
>> Currently -ftree-vectorize turns on both loop and slp vectorizations,
>> but there is no simple way to turn on loop vectorization alone. The
>> logic for default O3 setting is also complicated.
>>
>> In this patch, two new options are introduced:
>>
>> 1) -ftree-loop-vectorize
>>
>> This option is used to turn on loop vectorization only. option
>> -ftree-slp-vectorize also becomes a first class citizen, and no funny
>> business of Init(2) is needed.  With this change, -ftree-vectorize
>> becomes a simple alias to -ftree-loop-vectorize +
>> -ftree-slp-vectorize.
>>
>> For instance, to turn on only slp vectorize at O3, the old way is:
>>
>>  -O3 -fno-tree-vectorize -ftree-slp-vectorize
>>
>> With the new change it becomes:
>>
>> -O3 -fno-loop-vectorize
>>
>>
>> To turn on only loop vectorize at O2, the old way is
>>
>> -O2 -ftree-vectorize -fno-slp-vectorize
>>
>> The new way is
>>
>> -O2 -ftree-loop-vectorize
>>
>>
>>
>> 2) -ftree-vect-loop-peeling
>>
>> This option is used to turn on/off loop peeling for alignment.  In the
>> long run, this should be folded into the cheap cost model proposed by
>> Richard.  This option is also useful in scenarios where peeling can
>> introduce runtime problems:
>> http://gcc.gnu.org/ml/gcc/2005-12/msg00390.html  which happens to be
>> common in practice.
>>
>>
>>
>> Patch attached. Compiler boostrapped. Ok after testing?
>
> I'd like you to split 1) and 2), mainly because I agree on 1) but not on 
> 2).

 Ok. Can you also comment on 2) ?
>>>
>>> I think we want to decide how granular we want to control the vectorizer
>>> and using which mechanism.  My cost-model re-org makes
>>> ftree-vect-loop-version a no-op (basically removes it), so 2) looks like
>>> a step backwards in this context.
>>
>> Using cost model to do a coarse grain control/configuration is
>> certainly something we want, but having a fine grain control is still
>> useful.
>>
>>>
>>> So, can you summarize what pieces (including versioning) of the vectorizer
>>> you'd want to be able to disable separately?
>>
>> Loop peeling seems to be the main one. There is also a correctness
>> issue related. For instance, the following code is common in practice,
>> but loop peeling wrongly assumes initial base-alignment and generates
>> aligned mov instruction after peeling, leading to SEGV.  Peeling is
>> not something we can blindly turned on -- even when it is on, there
>> should be a way to turn it off explicitly:
>>
>> char a[1];
>>
>> void foo(int n)
>> {
>>   int* b = (int*)(a+n);
>>   int i = 0;
>>   for (; i < 1000; ++i)
>> b[i] = 1;
>> }
>>
>> int main(int argn, char** argv)
>> {
>>   foo(argn);
>> }
>
> But that's just a bug that should be fixed (looking into it).
>
>>>  Just disabling peeling for
>>> alignment may get you into the versioning for alignment path (and thus
>>> an unvectorized loop at runtime).
>>
>> This is not true for target supporting mis-aligned access. I have not
>> seen a case where alignment driver loop version happens on x86.
>>
>>>Also it's know that the alignment peeling
>>> code needs some serious TLC (it's outcome depends on the order of DRs,
>>> the cost model it uses leaves to be desired as we cannot distinguish
>>> between unaligned load and store costs).
>>
>> Yet another reason to turn it off as it is not effective anyways?
>
> As said I'll disable all remains of -ftree-vect-loop-version with the cost 
> model
> patch because it wasn't guarding versioning for aliasing but only versioning
> for alignment.
>
> We have to be consistent here - if we add a way to disable peeling for
> alignment then we certainly don't want to remove the ability to disable
> versioning for alignment, no?

We already have the ability to turn off versioning -- via --param. It
is a more natural way to fine tune a pass instead of introducing a -f
option. For this reason, your planned deprecation of the option is a
good thing to do.

For consistency, I think we should introduce a new parameter to turn
on/off peeling. This can also be tied closely with the cost model
change.

The proposed patch attached. Does this one look ok?

thanks,

David



>
> Richard.
>
>>
>> thanks,
>>
>> David
>>
>>>
>>> Richard.
>>>
>
> I've stopped a quick try doing 1) myself because
>
> @@ -1691,6 +1695,12 @@ common_handle_option (struct gcc_options
>  opts->x_flag_ipa_reference = false;
>   

Cleanup Linux libc selection and Android support

[Maxim Kuvyrkov]

Following recent breakage caused by adding nominal Android support to all 
*linux* targets [*] this patch series cleans up libc selection for Linux 
targets (-mglibc/-muclibc/-mbionic), splits libc selection logic from Android 
support, and removes Android handling from targets that don't support it.

[*] http://thread.gmane.org/gmane.comp.gcc.patches/277430/focus=292362

Special thanks goes to Alexander who tested and reviewed initial versions of 
these patches and fixed several problems.

The patch series was tested on various Linux and uClinux targets including arm, 
bfin, c6x, m68k, mips, powerpc, x86, x86_64.

Patches will be posted in their separate threads, and below is a summary.  
Individually the patches are all borderline trivial.

Reviews and approvals are welcome!

- 0001-Rename-files-for-libc-selection-on-Linux-targets
Mechanical rename of files in preparation for splitting Android handling from 
libc selection.

- 0002-Rename-functions-relating-to-libc-support-on-Linux-t
Mechanical rename of functions.

- 0003-Robustify-check-for-IFUNC-support
Trivial fix.

- 0004-Cleanup-definitions-of-libc-related-target-hooks
Consolidate definitions of libc target hooks in linux.h

- 0005-Cleanup-libc-selection-and-Android-support
Split Android handling from libc selection and remove Android handling from 
targets that don't support it.

Thanks,

--
Maxim Kuvyrkov
www.kugelworks.com

[PATCH 1/5] Rename files for libc selection on Linux targets

[Maxim Kuvyrkov]

Mechanical rename of files in preparation for splitting Android handling from 
libc selection.

The patch series was tested on various Linux and uClinux targets including arm, 
bfin, c6x, m68k, mips, powerpc, x86, x86_64.

OK to apply?

--
Maxim Kuvyrkov
www.kugelworks.com



0001-Rename-files-for-libc-selection-on-Linux-targets.patch
Description: Binary data

[PATCH 2/5] Rename functions relating to libc support on Linux targets

[Maxim Kuvyrkov]

Mechanical rename of functions.

The patch series was tested on various Linux and uClinux targets including arm, 
bfin, c6x, m68k, mips, powerpc, x86, x86_64.

OK to apply?

--
Maxim Kuvyrkov
www.kugelworks.com



0002-Rename-functions-relating-to-libc-support-on-Linux-t.patch
Description: Binary data

Re: [PATCH] manage dom-walk_data initialization and finalization with constructors and destructors

[Trevor Saunders]

On Wed, Sep 18, 2013 at 07:17:35PM +0200, Michael Matz wrote:
> > > I'd also like us to not use member privatization in our classes, but
> > > that's not in the patch, but if we could agree on that it would be nice.
> > Member privatization is quite natural.  What specifically do you not like
> > about the practice?
> 
> http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00302.html
> 
> That was conditional on "when we need to jump through hoops", but for 
> constistency it'd make sense to avoid it everywhere.

If you need to jump through a bunch of hoops then the language feature
isn't useful in that case, but not using it in other cases where it
actually is useful only to be consistant seems pretty foolish.
Especially if you ban things like fake deletion of members by making
them private, or make things public and add an x_ prefix that does the
same thing as private but in an uglier way with more manual work.

> > > Regstrapped on x86-64-linux, okay?
> > 
> > Obviously any ChangeLog, formatting and such can go in.  However, the 
> > trailing underscore should stay given it's already established practice 
> > and has several nice benefits.
> 
> What's the benefit of reading and writing such noisy lines? :
> 
>   *out_mode = mode_;
>   mode_ = GET_MODE_WIDER_MODE (mode_);
>   count_++;
> 
> The uglification merely makes code harder to write and read, it should be 
> used in cases where you _don't_ want developers to write such names.

I don't care for the _ thing too much, but I think it is useful for
seeing where a variable comes from, and I don't think you can seriously
argue it makes reading or writing much harder.

Trev


> 
> 
> Ciao,
> Michael.

[PATCH 3/5] Robustify check for IFUNC support

[Maxim Kuvyrkov]

This patch changes check in linux_has_ifunc_p() from TARGET_ANDROID to 
OPTION_BIONIC.  These two predicates are, currently, the same, but it is better 
to check for a specific C library rather than operational environment the 
library is commonly associated with.

The patch series was tested on various Linux and uClinux targets including arm, 
bfin, c6x, m68k, mips, powerpc, x86, x86_64.

OK to apply?

Thanks,

--
Maxim Kuvyrkov
www.kugelworks.com



0003-Robustify-check-for-IFUNC-support.patch
Description: Binary data

[PATCH 4/5] Cleanup definitions of libc-related target hooks

[Maxim Kuvyrkov]

This patch consolidates definitions of TARGET_LIBC_HAS_FUNCTION and 
TARGET_HAS_IFUNC_P hooks in linux.h from linux-android.h and uclinux.h files of 
various architectures.

One caveat to consolidating definitions in linux.h is that both *-linux-* and 
*-uclinux-* targets include config/linux.h, but *-uclinux-* targets then skip 
linux.opt, linux-protos.h and linux.c, which declare and define functions 
implementing target hooks.

Since we don't really want to add linux.opt and company to *-uclinux-* targets 
we check for "#if *-uclinux-*" in linux.h and define TARGET_LIBC_HAS_FUNCTION 
and TARGET_HAS_IFUNC_P separately for *-linux-* and for *-uclinux-*.

The patch series was tested on various Linux and uClinux targets including arm, 
bfin, c6x, m68k, mips, powerpc, x86, x86_64.

OK to apply?

Thanks,

--
Maxim Kuvyrkov
www.kugelworks.com




0004-Cleanup-definitions-of-libc-related-target-hooks.patch
Description: Binary data

[PATCH 5/5] Cleanup libc selection and Android support

[Maxim Kuvyrkov]

This patch splits Android handling from libc selection and removes Android 
handling from targets that don't support it.

The patch series was tested on various Linux and uClinux targets including arm, 
bfin, c6x, m68k, mips, powerpc, x86, x86_64.

OK to apply?

Thanks,

--
Maxim Kuvyrkov
www.kugelworks.com



0005-Cleanup-libc-selection-and-Android-support.patch
Description: Binary data

[Patch, Fortran, committed] Plug a memory leak in gfc_check_assign_symbol

[Tobias Burnus]

Committed as obvious, Rev. 202722.

Tobias
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog	(Revision 202713)
+++ gcc/fortran/ChangeLog	(Arbeitskopie)
@@ -1,5 +1,9 @@
 2013-09-18  Tobias Burnus  
 
+	* expr.c (gfc_check_assign_symbol): Free lvalue.ref.
+
+2013-09-18  Tobias Burnus  
+
 	PR fortran/43366
 	* primary.c (gfc_variable_attr): Also handle codimension.
 	* resolve.c (resolve_ordinary_assign): Add invalid-diagnostic for
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c	(Revision 202711)
+++ gcc/fortran/expr.c	(Arbeitskopie)
@@ -3824,6 +3824,7 @@ gfc_check_assign_symbol (gfc_symbol *sym, gfc_comp
 r = gfc_check_assign (&lvalue, rvalue, 1);
 
   free (lvalue.symtree);
+  free (lvalue.ref);
 
   if (!r)
 return r;

Re: Drop generic32 cost model

[H.J. Lu]

On Wed, Sep 18, 2013 at 1:39 PM, Jan Hubicka  wrote:
> Hi,
> when generic model was introduced, the 32bit only CPUs was still common on the
> market.  It would be stupid to tune 64bit code for CPUs that will never run 
> it.
> We thus introduced two models - generic32 that was considering needs
> of 32bit cpus (centrinos in particular) and generic64 that didn't.
>
>  /* Generic32 should produce code tuned for PPro, Pentium4, Nocona,
> Athlon and K8.  */
>  /* Generic64 should produce code tuned for Nocona and K8.  */
>
> Was original definitions that are still in the source.
>
> Today the 32bit only CPUs are no longer important.  This patch thus
> drops 32bit generic.  This has effect of droping the following flags
> for generic at -m32:
>  use_leave, avoid_vector_decode, slow_imul_imm32_mem, slow_imul_imm8
> that are currently enabled for generic64 only.  This was to accomodate
> earlier AMD chips that are no longer relevant too.
>
> I also updated comment:
> ! /* Generic64 should produce code tuned for Nocona and K8.  */
> to:
> ! /* Generic should produce code tuned for Core-i7 (and newer chips)
> !and btver1 (and newer chips).  */
> This is what I think generic represents today (it also fares swell on earlier
> cores and amdfam10, but we probably don't want to get too limited by these
> anymore).

This sounds good to me.

> I would like to proceed with modernization of generic64 - in particular
> to switch it to 4 issue scheduling model and revisit individual flags
> incrementally.
>
> Bootstrapped/regtested x86_64-linux, will commit it tomorrow if there
> are no complains.
>
> Honza
>
> * i386.h (TARGET_GENERIC32, TARGET_GENERIC64): Remove.
> (TARGET_GENERIC): Use PROCESOR_GENERIC
> (enum processor_type): Unify generic32 and 64.
> * i386.md (cpu): Likewise.
> * x86-tune.def (use_leave): Enable for generic32.
> (avoid_vector_decode, slow_imul_imm32_mem, slow_imul_imm8): Likewise.
> * athlon.md: Change generic64 to generic in all occurences.
> * i386-c.c (ix86_target_macros_internal): Unify generic64 and 32.
> (ix86_target_macros_internal): Likewise.
> * driver-i386.c (host_detect_local_cpu): Likewise.
> * i386.c (generic64_memcpy, generic64_memset, generic64_cost): Rename 
> to ..
> (generic_memcpy, generic_memset, generic_cost): This one.
> (generic32_memcpy, generic32_memset, generic32_cost): Remove.
> (m_GENERIC32, m_GENERIC64): Remove.
> (m_GENERIC): Turn into one flag.
> (processor_target): Unify generic tunnings.
> (ix86_option_override_internal): Replace generic32/64 by generic.
> (ix86_issue_rate): Likewise.
> (ix86_adjust_cost): Likewise.


> *** static const struct ptt processor_target
> *** 2384,2391 
> {&core_cost, 16, 10, 16, 10, 16},
> /* Core avx2  */
> {&core_cost, 16, 10, 16, 10, 16},
> !   {&generic32_cost, 16, 7, 16, 7, 16},
> !   {&generic64_cost, 16, 10, 16, 10, 16},
> {&amdfam10_cost, 32, 24, 32, 7, 32},
> {&bdver1_cost, 16, 10, 16, 7, 11},
> {&bdver2_cost, 16, 10, 16, 7, 11},
> --- 2303,2309 
> {&core_cost, 16, 10, 16, 10, 16},
> /* Core avx2  */
> {&core_cost, 16, 10, 16, 10, 16},
> !   {&generic_cost, 16, 10, 16, 10, 16},
> {&amdfam10_cost, 32, 24, 32, 7, 32},
> {&bdver1_cost, 16, 10, 16, 7, 11},
> {&bdver2_cost, 16, 10, 16, 7, 11},

I did some experiment with code alignment. I found
-fno-align-loops -fno-align-functions -fno-align-jumps
had no negative performance impacts on current
Intel processors while reducing code sizes by 1-2%.
Should we use

{&generic_cost, 0, 0, 0, 0, 0},

instead?

Thanks.

-- 
H.J.

Re: [gomp4] C UDR support

[Joseph S. Myers]

On Wed, 18 Sep 2013, Jakub Jelinek wrote:

> Hi!
> 
> This is the C FE counterpart of the C++ FE OpenMP 4.0 user defined
> reductions, as C has no templates, class inheritance, doesn't
> allow #pragma omp declare reduction in structs/unions, the implementation is
> significantly simpler.
> 
> Joseph, any comments on this?

No comments here.

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

Go patch committed: Fix identical unnamed structs with methods

[Ian Lance Taylor]

When gccgo saw multiple identical unnamed structs with methods assigned
to interfaces that used those methods, it would emit multiple copies of
the interface method table, causing a duplicate symbol error from the
assembler.  This patch fixes the bug.  I added a test case to the master
testsuite that will be copied in the gccgo testsuite in due course.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline and 4.8 branch.

Ian

diff -r 6791d7b7151c go/types.cc
--- a/go/types.cc	Wed Sep 18 11:34:51 2013 -0700
+++ b/go/types.cc	Wed Sep 18 14:50:19 2013 -0700
@@ -4229,6 +4229,11 @@
 
 Struct_type::Identical_structs Struct_type::identical_structs;
 
+// A hash table used to merge method sets for identical unnamed
+// structs.
+
+Struct_type::Struct_method_tables Struct_type::struct_method_tables;
+
 // Traversal.
 
 int
@@ -4693,9 +4698,24 @@
 const Interface_type* interface,
 bool is_pointer)
 {
+  std::pair
+val(this, NULL);
+  std::pair ins =
+Struct_type::struct_method_tables.insert(val);
+
+  Struct_method_table_pair* smtp;
+  if (!ins.second)
+smtp = ins.first->second;
+  else
+{
+  smtp = new Struct_method_table_pair();
+  smtp->first = NULL;
+  smtp->second = NULL;
+  ins.first->second = smtp;
+}
+
   return Type::interface_method_table(gogo, this, interface, is_pointer,
-  &this->interface_method_tables_,
-  &this->pointer_interface_method_tables_);
+  &smtp->first, &smtp->second);
 }
 
 // Convert struct fields to the backend representation.  This is not
diff -r 6791d7b7151c go/types.h
--- a/go/types.h	Wed Sep 18 11:34:51 2013 -0700
+++ b/go/types.h	Wed Sep 18 14:50:19 2013 -0700
@@ -2041,8 +2041,7 @@
  public:
   Struct_type(Struct_field_list* fields, Location location)
 : Type(TYPE_STRUCT),
-  fields_(fields), location_(location), all_methods_(NULL),
-  interface_method_tables_(NULL), pointer_interface_method_tables_(NULL)
+  fields_(fields), location_(location), all_methods_(NULL)
   { }
 
   // Return the field NAME.  This only looks at local fields, not at
@@ -2200,6 +2199,16 @@
 
   static Identical_structs identical_structs;
 
+  // Used to manage method tables for identical unnamed structs.
+  typedef std::pair
+Struct_method_table_pair;
+
+  typedef Unordered_map_hash(Struct_type*, Struct_method_table_pair*,
+			 Type_hash_identical, Type_identical)
+Struct_method_tables;
+
+  static Struct_method_tables struct_method_tables;
+
   // Used to avoid infinite loops in field_reference_depth.
   struct Saw_named_type
   {
@@ -2218,13 +2227,6 @@
   Location location_;
   // If this struct is unnamed, a list of methods.
   Methods* all_methods_;
-  // A mapping from interfaces to the associated interface method
-  // tables for this type.  Only used if this struct is unnamed.
-  Interface_method_tables* interface_method_tables_;
-  // A mapping from interfaces to the associated interface method
-  // tables for pointers to this type.  Only used if this struct is
-  // unnamed.
-  Interface_method_tables* pointer_interface_method_tables_;
 };
 
 // The type of an array.

Re: [PATCH] manage dom-walk_data initialization and finalization with constructors and destructors

[Ian Lance Taylor]

On Wed, Sep 18, 2013 at 10:17 AM, Michael Matz  wrote:
>
>> > I'd also like us to not use member privatization in our classes, but
>> > that's not in the patch, but if we could agree on that it would be nice.
>
>> Member privatization is quite natural.  What specifically do you not like
>> about the practice?
>
> http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00302.html
>
> That was conditional on "when we need to jump through hoops", but for
> constistency it'd make sense to avoid it everywhere.
> (I know that Ian agreed to that mail, but somehow the mailing list
> archives don't have that!?)

I accidentally sent the e-mail in HTML mode, and it bounced.  I didn't
think it was important enough to resend.

But I wouldn't go so far as to say that we should never use private
members, just that I think it's better to use public members than to
contort the code to force them to be private.

In any case I do think that any discussion of this area should be with
regard to suggested changes to the coding conventions at
http://gcc.gnu.org/codingconventions.html .  Those conventions do say
"Prefer to make data members private" and "When structs and/or classes
have member functions, prefer to name data members with a trailing
underscore."

Ian

Re: [patch] Make vector::at() assertion message more useful (try #2)

[Paolo Carlini]

Hi,

> Il giorno 18/set/2013, alle ore 21:38, Paul Pluzhnikov 
>  ha scritto:
> 
>> On Fri, Sep 13, 2013 at 3:02 AM, Paolo Carlini  
>> wrote:
>> 
>> - The game with the variadic and the non-variadic __throw_out_of_range makes
>> me a little nervous. Let's just name the new one differently, like
>> __throw_out_of_range_var.
> 
> Replaced with __throw_out_of_range_fmt.
> 
>> - Please consistently use __builtin_alloca everywhere, alloca isn't a
>> standard function.
> 
> Done.
> 
>> - I would rather call the file itself snprintf_lite.cc, in order not to fool
>> somebody that it actually implements the whole snprintf.
> 
> Done.
> 
>> - I'm a bit confused about __concat_size_t returning -1. Since it only
>> formats integers, I think we can be *sure* that the buffer is big enough.
> 
> How so? The caller could do this:
> 
>  __snprintf_lite("aaa: %zu, 8, 12345678);
> 
> By the time we get to __concat_size_t, we only have 3 characters left.

Ok, thanks, I think I misread the code. In general I meant that you can bound a 
priori the number of chars you need to format an integer - that isn't the case 
for floats, for example (the user may want a ridiculously large number of 
decimal digits). But you are in fact already exploiting that for the value of 
__ilen.

> 
>> Then, if it returns -1 something is going *very badly* wrong, shouldn't we
>> __builtin_abort() or something similar?
> 
> I've re-worked this part -- if this ever happens, throw a logic_error with
> a message to file a bug.
> 
>> - In terms of buffer sizes, this comment:
>> 
>>// enough for expanding up to 5 size_t's in the format.
>> 
>> and then the actual code in __snprintf_lite makes me a little nervous.
>> Agreed, we are not going to overflow the buffer, but truncating with no
>> diagnostic whatsoever seems rather gross. We can probably sort out this
>> later, new ideas welcome, anyway.
> 
> Re-worked.
> 
>> - While we are at it, shouldn't we use the new facility at least in array,
>> vector and deque too? For consistency over the containers.
> 
> Done.
> 
> I also expanded snprintf_lite to handle '%s', as that comes handy inside
> string _M_check.
> 
> Thanks,
> 
> P.S. In the process of updating callers of __throw_out_of_range, I've
> discovered that two of them had already used __builtin_sprintf.
> 
> P.P.S. Sorry this patch grew ... I can split it into parts if that's easier
> to review.

In general I like this version of the patch a lot. Thus assuming nobody else 
has further comments over the next day or so, please commit it at your ease. In 
the meanwhile, since you are also touching debug-mode and profile-mode, make 
sure to run check-debug and check-profile too.


Thanks,
Paolo

Re: [Patch, Fortran] PR57697 - Fix an issue with defined assignment

[Tobias Burnus]

I have now committed (Rev. 202725) a test case for that patch. (I 
confirmed that it fails before Rev. 202609 and works now.)

See attachment.

(While trying to create a test case, I found another bug with defined 
assignment; see PR fortran/58469.)


Tobias

PS: I still have to do the backporting to 4.8. By the way, the following 
patch is still pending to be reviewed: 
http://gcc.gnu.org/ml/fortran/2013-09/msg00031.html



Thomas Koenig wrote:

As testing showed, it didn't fix the real-world code: ForTrilinos's
ForTrilinos_ADT_3D_Burgers_6th_Pade did still fail as it has:

  *_F.DA65 = matrix_diff_x (&parm.621);
_F.DA66 = ax->epetra_rowmatrix.universal; // Deref of "ax"!
Build and regtested on x86-64-gnu-linux.
OK?

The patch is OK, also for 4.8.  Please add a test case which also
checks for the ForTrilinos failure.
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog	(Revision 202724)
+++ gcc/testsuite/ChangeLog	(Arbeitskopie)
@@ -1,3 +1,8 @@
+2013-09-18  Tobias Burnus  
+
+	PR fortran/57697
+	* gfortran.dg/defined_assignment_11.f90: New.
+
 2013-09-18  Vladimir Makarov  
 
 	PR rtl-optimization/58438
Index: gcc/testsuite/gfortran.dg/defined_assignment_11.f90
===
--- gcc/testsuite/gfortran.dg/defined_assignment_11.f90	(Revision 0)
+++ gcc/testsuite/gfortran.dg/defined_assignment_11.f90	(Arbeitskopie)
@@ -0,0 +1,43 @@
+! { dg-do run }
+!
+! PR fortran/57697
+!
+! Further test of typebound defined assignment
+!
+module m0
+  implicit none
+  type :: component
+integer :: i = 42
+integer, allocatable :: b
+  contains
+procedure :: assign0
+generic :: assignment(=) => assign0
+  end type
+  type, extends(component) :: comp2
+real :: aa
+  end type comp2
+  type parent
+type(component) :: foo
+real :: cc
+  end type
+  type p2
+type(parent) :: x
+  end type p2
+contains
+  elemental subroutine assign0(lhs,rhs)
+class(component), intent(INout) :: lhs
+class(component), intent(in) :: rhs
+lhs%i = 20
+  end subroutine
+end module
+
+program main
+  use m0
+  implicit none
+  type(p2), allocatable :: left
+  type(p2) :: right
+!  print *, right%x%foo%i
+  left = right
+!  print *, left%x%foo%i
+  if (left%x%foo%i /= 20) call abort()
+end

Re: [PATCH, committed] SH: Fix PR58314 (unsatisfied constraints)

[Kaz Kojima]

Christian Bruel  wrote:
> && (!can_create_pseudo_p () && REG_P (operands[0]) && REG_P (operands[1]))"
> 
> is necessary ?

It looks an another hack to allow the 2nd and 3rd alternatives only
when reloading.  If so, it might be a bit cleaner to use a special
predicate like

;; Returns 1 if OP can be a source of a mov*_reg_reg insn. Same as
;; general_movsrc_operand, but mem allowed only when reload in progress.
(define_predicate "movsrc_reg_reg_operand"
  (match_code "subreg,reg,mem")
{
  if (reload_in_progress && MEM_P (op))
return general_movsrc_operand (op, mode);

  return register_operand (op, mode);
})

and its dst version for that purpose.

>> BTW, in the test case (gcc.target/sh/torture/pr58314.c), this 
>>
>> /* { dg-options "-Os" } */
>>
>> defeats the purpose of the torture tests.
> 
> does it ? I though that the dg-option would be a force it in addition to
> the torture-option list (which should include -Os anyway, but it's just
> to make sure). In my log I have
> 
> PASS: gcc.target/sh/torture/pr58314.c  -O0  (test for excess errors)
> PASS: gcc.target/sh/torture/pr58314.c  -O1  (test for excess errors)
> PASS: gcc.target/sh/torture/pr58314.c  -O2  (test for excess errors)
> PASS: gcc.target/sh/torture/pr58314.c  -O3 -funroll-loops  (test for
> excess errors)
> PASS: gcc.target/sh/torture/pr58314.c  -O3 -funroll-all-loops
> -finline-functions  (test for excess errors)
> PASS: gcc.target/sh/torture/pr58314.c  -O3 -g  (test for excess errors)
> PASS: gcc.target/sh/torture/pr58314.c  -Os  (test for excess errors)

/* { dg-options "" } */

will work.

Regards,
kaz

Re: [patch] Make cxxfilt demangle internal-linkage templates

[Paolo Carlini]

Hi,

On 09/18/2013 09:23 PM, Paul Pluzhnikov wrote:

Ping x3?

2013/9/11 Paul Pluzhnikov :

Ping x2?

Original message:
http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00394.html



I'm adding Ian in CC.

Paolo.

Go patch committed: Fix unexported method of embedded imported type

[Ian Lance Taylor]

The Go frontend was using the wrong name for an method generated for an
embedded imported type with an unexported method.  This is a kind of
unlikely case, but it could lead to name collisions in the assembly
code.  I added a test case to the master Go repository, and it will come
into the gccgo testsuite in due course.  Bootstrapped and ran Go
testsuite on x86_64-unknown-linux-gnu.  Committed to mainline and 4.8
branch.

Ian

diff -r ef1b48bc00bf go/gogo-tree.cc
--- a/go/gogo-tree.cc	Wed Sep 18 14:51:20 2013 -0700
+++ b/go/gogo-tree.cc	Wed Sep 18 16:13:42 2013 -0700
@@ -1009,6 +1009,16 @@
   else
 	package_name = this->package_->package_name();
 
+  // Note that this will be misleading if this is an unexported
+  // method generated for an embedded imported type.  In that case
+  // the unexported method should have the package name of the
+  // package from which it is imported, but we are going to give
+  // it our package name.  Fixing this would require knowing the
+  // package name, but we only know the package path.  It might be
+  // better to use package paths here anyhow.  This doesn't affect
+  // the assembler code, because we always set that name in
+  // Function::get_or_make_decl anyhow.  FIXME.
+
   decl_name = package_name + '.' + Gogo::unpack_hidden_name(this->name_);
 
   Function_type* fntype;
@@ -1317,7 +1327,21 @@
 		   || this->type_->is_method())
 	{
 	  TREE_PUBLIC(decl) = 1;
-	  std::string asm_name = gogo->pkgpath_symbol();
+	  std::string pkgpath = gogo->pkgpath_symbol();
+	  if (this->type_->is_method()
+		  && Gogo::is_hidden_name(no->name())
+		  && Gogo::hidden_name_pkgpath(no->name()) != gogo->pkgpath())
+		{
+		  // This is a method we created for an unexported
+		  // method of an imported embedded type.  We need to
+		  // use the pkgpath of the imported package to avoid
+		  // a possible name collision.  See bug478 for a test
+		  // case.
+		  pkgpath = Gogo::hidden_name_pkgpath(no->name());
+		  pkgpath = Gogo::pkgpath_for_symbol(pkgpath);
+		}
+
+	  std::string asm_name = pkgpath;
 	  asm_name.append(1, '.');
 	  asm_name.append(Gogo::unpack_hidden_name(no->name()));
 	  if (this->type_->is_method())

[GOOGLE] Patch to fix AutoFDO LIPO performance regression

[Dehao Chen]

This patch fixup the call graph edge targets during AutoFDO pass, so
that when rebuilding call graph edges, it can find the correct callee.

Bootstrapped and passed regression test. Benchmark tests on-going.

Ok for google-4_8 branch?

Thanks,
Dehao

Index: gcc/Makefile.in
===
--- gcc/Makefile.in (revision 202725)
+++ gcc/Makefile.in (working copy)
@@ -2960,7 +2960,7 @@ coverage.o : coverage.c $(GCOV_IO_H) $(CONFIG_H) $
 auto-profile.o : auto-profile.c $(CONFIG_H) $(SYSTEM_H) $(FLAGS_H) \
$(BASIC_BLOCK_H) $(DIAGNOSTIC_CORE_H) $(GCOV_IO_H) $(INPUT_H) profile.h \
$(LANGHOOKS_H) $(OPTS_H) $(TREE_PASS_H) $(CGRAPH_H) $(GIMPLE_H)
value-prof.h \
-   $(COVERAGE_H) coretypes.h $(TREE_H) $(PARAMS_H) $(AUTO_PROFILE_H)
+   $(COVERAGE_H) coretypes.h $(TREE_H) $(PARAMS_H) l-ipo.h $(AUTO_PROFILE_H)
 cselib.o : cselib.c $(CONFIG_H) $(SYSTEM_H) coretypes.h dumpfile.h
$(TM_H) $(RTL_H) \
$(REGS_H) hard-reg-set.h $(FLAGS_H) insn-config.h $(RECOG_H) \
$(EMIT_RTL_H) $(DIAGNOSTIC_CORE_H) $(FUNCTION_H) \
Index: gcc/auto-profile.c
===
--- gcc/auto-profile.c (revision 202725)
+++ gcc/auto-profile.c (working copy)
@@ -46,6 +46,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "value-prof.h"
 #include "coverage.h"
 #include "params.h"
+#include "l-ipo.h"
 #include "auto-profile.h"

 /* The following routines implements AutoFDO optimization.
@@ -1290,6 +1291,13 @@ auto_profile (void)
   init_node_map ();
   profile_info = autofdo::afdo_profile_info;

+  cgraph_pre_profiling_inlining_done = true;
+  cgraph_process_module_scope_statics ();
+  /* Now perform link to allow cross module inlining.  */
+  cgraph_do_link ();
+  varpool_do_link ();
+  cgraph_unify_type_alias_sets ();
+
   FOR_EACH_FUNCTION (node)
 {
   if (!gimple_has_body_p (node->symbol.decl))
@@ -1301,6 +1309,21 @@ auto_profile (void)

   push_cfun (DECL_STRUCT_FUNCTION (node->symbol.decl));

+  if (L_IPO_COMP_MODE)
+{
+  basic_block bb;
+  FOR_EACH_BB (bb)
+{
+  gimple_stmt_iterator gsi;
+  for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (&gsi))
+ {
+  gimple stmt = gsi_stmt (gsi);
+  if (is_gimple_call (stmt))
+lipo_fixup_cgraph_edge_call_target (stmt);
+ }
+}
+ }
+
   autofdo::afdo_annotate_cfg ();
   compute_function_frequency ();
   update_ssa (TODO_update_ssa);
@@ -1309,13 +1332,6 @@ auto_profile (void)
   pop_cfun ();
 }

-  cgraph_pre_profiling_inlining_done = true;
-  cgraph_process_module_scope_statics ();
-  /* Now perform link to allow cross module inlining.  */
-  cgraph_do_link ();
-  varpool_do_link ();
-  cgraph_unify_type_alias_sets ();
-
   return TODO_rebuild_cgraph_edges;
 }

Re: libtool update for powerpc64le-linux

[Alan Modra]

On Wed, Sep 18, 2013 at 10:14:16AM -0400, David Edelsohn wrote:
> Please ensure that you use the correct version of autoconf to
> regenerate the files. I don't think that the same version of autoconf
> is used in all directories.

gcc is OK in this respect.  autoconf-2.64 is used throughout.  It's
src that is a hodge-podge of different versions.

-- 
Alan Modra
Australia Development Lab, IBM

Re: [GOOGLE] Patch to fix AutoFDO LIPO performance regression

[Xinliang David Li]

On Wed, Sep 18, 2013 at 4:51 PM, Dehao Chen  wrote:
> This patch fixup the call graph edge targets during AutoFDO pass, so
> that when rebuilding call graph edges, it can find the correct callee.
>
> Bootstrapped and passed regression test. Benchmark tests on-going.
>
> Ok for google-4_8 branch?
>
> Thanks,
> Dehao
>
> Index: gcc/Makefile.in
> ===
> --- gcc/Makefile.in (revision 202725)
> +++ gcc/Makefile.in (working copy)
> @@ -2960,7 +2960,7 @@ coverage.o : coverage.c $(GCOV_IO_H) $(CONFIG_H) $
>  auto-profile.o : auto-profile.c $(CONFIG_H) $(SYSTEM_H) $(FLAGS_H) \
> $(BASIC_BLOCK_H) $(DIAGNOSTIC_CORE_H) $(GCOV_IO_H) $(INPUT_H) profile.h \
> $(LANGHOOKS_H) $(OPTS_H) $(TREE_PASS_H) $(CGRAPH_H) $(GIMPLE_H)
> value-prof.h \
> -   $(COVERAGE_H) coretypes.h $(TREE_H) $(PARAMS_H) $(AUTO_PROFILE_H)
> +   $(COVERAGE_H) coretypes.h $(TREE_H) $(PARAMS_H) l-ipo.h $(AUTO_PROFILE_H)
>  cselib.o : cselib.c $(CONFIG_H) $(SYSTEM_H) coretypes.h dumpfile.h
> $(TM_H) $(RTL_H) \
> $(REGS_H) hard-reg-set.h $(FLAGS_H) insn-config.h $(RECOG_H) \
> $(EMIT_RTL_H) $(DIAGNOSTIC_CORE_H) $(FUNCTION_H) \
> Index: gcc/auto-profile.c
> ===
> --- gcc/auto-profile.c (revision 202725)
> +++ gcc/auto-profile.c (working copy)
> @@ -46,6 +46,7 @@ along with GCC; see the file COPYING3.  If not see
>  #include "value-prof.h"
>  #include "coverage.h"
>  #include "params.h"
> +#include "l-ipo.h"
>  #include "auto-profile.h"
>
>  /* The following routines implements AutoFDO optimization.
> @@ -1290,6 +1291,13 @@ auto_profile (void)
>init_node_map ();
>profile_info = autofdo::afdo_profile_info;
>
> +  cgraph_pre_profiling_inlining_done = true;
> +  cgraph_process_module_scope_statics ();
> +  /* Now perform link to allow cross module inlining.  */
> +  cgraph_do_link ();
> +  varpool_do_link ();
> +  cgraph_unify_type_alias_sets ();
> +
>FOR_EACH_FUNCTION (node)
>  {
>if (!gimple_has_body_p (node->symbol.decl))
> @@ -1301,6 +1309,21 @@ auto_profile (void)
>
>push_cfun (DECL_STRUCT_FUNCTION (node->symbol.decl));
>
> +  if (L_IPO_COMP_MODE)
> +{
> +  basic_block bb;
> +  FOR_EACH_BB (bb)
> +{
> +  gimple_stmt_iterator gsi;
> +  for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (&gsi))
> + {
> +  gimple stmt = gsi_stmt (gsi);
> +  if (is_gimple_call (stmt))
> +lipo_fixup_cgraph_edge_call_target (stmt);
> + }
> +}
> + }
> +

Need this:


  if (execute_fixup_cfg () & TODO_cleanup_cfg)
  cleanup_tree_cfg ();


as in tree-profiling. Changing call stmt targets can lead to CFG changes.



David

>autofdo::afdo_annotate_cfg ();
>compute_function_frequency ();
>update_ssa (TODO_update_ssa);
> @@ -1309,13 +1332,6 @@ auto_profile (void)
>pop_cfun ();
>  }
>
> -  cgraph_pre_profiling_inlining_done = true;
> -  cgraph_process_module_scope_statics ();
> -  /* Now perform link to allow cross module inlining.  */
> -  cgraph_do_link ();
> -  varpool_do_link ();
> -  cgraph_unify_type_alias_sets ();
> -
>return TODO_rebuild_cgraph_edges;
>  }

[v3] More noexcept -- 4th

[Marc Glisse]

Hello,

I did not touch the regular basic_string because Paulo usually says not to 
touch it, but I could do it as well if wanted. I didn't add noexcept to 
the debug string swap (and move assignments) because the regular 
basic_string swap can currently throw if the allocators are distinct.


bootstrap+testsuite ok.

2013-09-19  Marc Glisse  

PR libstdc++/58338
* include/bits/stl_tree.h (_Rb_tree_node_base) [_S_minimum, _S_maximum]:
Mark as noexcept.
(_Rb_tree_iterator) [_Rb_tree_iterator, operator*, operator->,
operator++, operator--, operator==, operator!=]: Likewise.
(_Rb_tree_const_iterator) [_Rb_tree_const_iterator, _M_const_cast,
operator*, operator->, operator++, operator--, operator==, operator!=]:
Likewise.
(operator==(const _Rb_tree_iterator&, const _Rb_tree_const_iterator&),
operator!=(const _Rb_tree_iterator&, const _Rb_tree_const_iterator&)):
Likewise.
(_Rb_tree) [_M_put_node, _M_destroy_node, _M_root, _M_leftmost,
_M_rightmost, _M_begin, _M_end, _S_left, _S_right, _S_minimum,
_S_maximum]: Likewise.
* include/debug/string (basic_string) [basic_string(const _Allocator&),
shrink_to_fit, operator[], pop_back]: Likewise.
* include/ext/vstring.h (__versa_string) [_M_limit, _M_disjunct,
_M_ibegin, _M_iend, __versa_string(const _Alloc&),
operator=(__versa_string&&), shrink_to_fit, operator[], front,
back, assign(__versa_string&&), swap]: Likewise.
(__versa_string) [__versa_string(), __versa_string(const _Alloc&)]:
Merge.

--
Marc GlisseIndex: include/bits/stl_tree.h
===
--- include/bits/stl_tree.h (revision 202722)
+++ include/bits/stl_tree.h (working copy)
@@ -92,42 +92,42 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   {
 typedef _Rb_tree_node_base* _Base_ptr;
 typedef const _Rb_tree_node_base* _Const_Base_ptr;
 
 _Rb_tree_color _M_color;
 _Base_ptr  _M_parent;
 _Base_ptr  _M_left;
 _Base_ptr  _M_right;
 
 static _Base_ptr
-_S_minimum(_Base_ptr __x)
+_S_minimum(_Base_ptr __x) _GLIBCXX_NOEXCEPT
 {
   while (__x->_M_left != 0) __x = __x->_M_left;
   return __x;
 }
 
 static _Const_Base_ptr
-_S_minimum(_Const_Base_ptr __x)
+_S_minimum(_Const_Base_ptr __x) _GLIBCXX_NOEXCEPT
 {
   while (__x->_M_left != 0) __x = __x->_M_left;
   return __x;
 }
 
 static _Base_ptr
-_S_maximum(_Base_ptr __x)
+_S_maximum(_Base_ptr __x) _GLIBCXX_NOEXCEPT
 {
   while (__x->_M_right != 0) __x = __x->_M_right;
   return __x;
 }
 
 static _Const_Base_ptr
-_S_maximum(_Const_Base_ptr __x)
+_S_maximum(_Const_Base_ptr __x) _GLIBCXX_NOEXCEPT
 {
   while (__x->_M_right != 0) __x = __x->_M_right;
   return __x;
 }
   };
 
   template
 struct _Rb_tree_node : public _Rb_tree_node_base
 {
   typedef _Rb_tree_node<_Val>* _Link_type;
@@ -160,72 +160,72 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   typedef _Tp& reference;
   typedef _Tp* pointer;
 
   typedef bidirectional_iterator_tag iterator_category;
   typedef ptrdiff_t  difference_type;
 
   typedef _Rb_tree_iterator<_Tp>_Self;
   typedef _Rb_tree_node_base::_Base_ptr _Base_ptr;
   typedef _Rb_tree_node<_Tp>*   _Link_type;
 
-  _Rb_tree_iterator()
+  _Rb_tree_iterator() _GLIBCXX_NOEXCEPT
   : _M_node() { }
 
   explicit
-  _Rb_tree_iterator(_Link_type __x)
+  _Rb_tree_iterator(_Link_type __x) _GLIBCXX_NOEXCEPT
   : _M_node(__x) { }
 
   reference
-  operator*() const
+  operator*() const _GLIBCXX_NOEXCEPT
   { return static_cast<_Link_type>(_M_node)->_M_value_field; }
 
   pointer
-  operator->() const
+  operator->() const _GLIBCXX_NOEXCEPT
   { return std::__addressof(static_cast<_Link_type>
(_M_node)->_M_value_field); }
 
   _Self&
-  operator++()
+  operator++() _GLIBCXX_NOEXCEPT
   {
_M_node = _Rb_tree_increment(_M_node);
return *this;
   }
 
   _Self
-  operator++(int)
+  operator++(int) _GLIBCXX_NOEXCEPT
   {
_Self __tmp = *this;
_M_node = _Rb_tree_increment(_M_node);
return __tmp;
   }
 
   _Self&
-  operator--()
+  operator--() _GLIBCXX_NOEXCEPT
   {
_M_node = _Rb_tree_decrement(_M_node);
return *this;
   }
 
   _Self
-  operator--(int)
+  operator--(int) _GLIBCXX_NOEXCEPT
   {
_Self __tmp = *this;
_M_node = _Rb_tree_decrement(_M_node);
return __tmp;
   }
 
   bool
-  operator==(const _Self& __x) const
+  operator==(const _Self& __x) const _GLIBCXX_NOEXCEPT
   { return _M_node == __x._M_node; }
 
   bool
-  operator!=(const _Self& __x) const
+

Re: [PATCH] manage dom-walk_data initialization and finalization with constructors and destructors

[Jeff Law]

On 09/18/2013 11:17 AM, Michael Matz wrote:

Hi,

On Wed, 18 Sep 2013, Jeff Law wrote:


On 09/18/2013 10:24 AM, Michael Matz wrote:


I'm irritated by the member name uglification (e.g. equiv_stack_ with
trailing underscore).  I know that's a certain style to mark private
members, but I think it's a bad style (like prefixing variable names with
their type), and before it sets a precedent in GCCs c++ coding style I'd
like this to be changed, like in the below.


We're already using the trailing underscore idiom for private objects
moving into classes (see the pass class).


I know, and I don't like it there either.
Well, as Ian pointed out, it is in our recommended style guidelines and 
you'll find uses in the vec class as well.  It's well established at 
this point and I see no compelling reason to go back unless you can 
convince the project as a whole to change the C++ guidelines.





I'd also like us to not use member privatization in our classes, but
that's not in the patch, but if we could agree on that it would be nice.

Member privatization is quite natural.  What specifically do you not like
about the practice?


http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00302.html

That was conditional on "when we need to jump through hoops", but for
constistency it'd make sense to avoid it everywhere.
(I know that Ian agreed to that mail, but somehow the mailing list
archives don't have that!?)
I don't see anything in Trevor's work that requires jumping through 
hoops.  It's pretty simple stuff.  And again, as Ian pointed out, our 
established guidelines for C++ usage encourage this behaviour.






Regstrapped on x86-64-linux, okay?


Obviously any ChangeLog, formatting and such can go in.  However, the
trailing underscore should stay given it's already established practice
and has several nice benefits.


What's the benefit of reading and writing such noisy lines? :

   *out_mode = mode_;
   mode_ = GET_MODE_WIDER_MODE (mode_);
   count_++;
It makes it very clear to the reader that we're dealing with objects 
that belong to a class instance rather than direct access to an auto or 
static.  That can be important.





The uglification merely makes code harder to write and read, it should be
used in cases where you _don't_ want developers to write such names.

I feel it makes it harder in some ways and easier in others.

Given it's recommended by our C++ guidelines which were discussed at 
length, I'm going to explicitly NAK your patch.  If you want to re-open 
the guidelines for C++ usage, then that's fine with me and if we as a 
project change the guidelines to disallow such things, then that will be 
the time to remove the trailing underscores, private members, etc.


FWIW, I have worked on large C++ codebases that were a free-for-all and 
found them *amazingly* painful.  The restricted set allowed for GCC is 
actually quite reasonable IMHO, particularly for projects where the main 
body of code is evolving from a pure C base.



Jeff