Re: [buildbot] r201508: Build failures after pass C++ conversion

[Andreas Schwab]

David Malcolm  writes:

> diff --git a/gcc/coretypes.h b/gcc/coretypes.h
> index edb9c8c..54bfe7f 100644
> --- a/gcc/coretypes.h
> +++ b/gcc/coretypes.h
> @@ -169,6 +169,12 @@ typedef const struct basic_block_def *const_basic_block;
> in target.h.  */
>  typedef int reg_class_t;
>  
> +class rtl_opt_pass;
> +
> +namespace gcc {
> +  class context;
> +}
> +

This break Ada.

../../xgcc -B../../ -c -DIN_GCC  -DUSE_LIBUNWIND_EXCEPTIONS -O2 -g -W -Wall  \
    -iquote /usr/local/gcc/gcc-20130807/gcc \
 -iquote . -iquote .. -iquote ../.. -iquote 
/usr/local/gcc/gcc-20130807/gcc/ada -iquote /usr/local/gcc/gcc-20130807/gcc 
-I/usr/local/gcc/gcc-20130807/gcc/../include 
-I/usr/local/gcc/gcc-20130807/Build/./gmp -I/usr/local/gcc/gcc-20130807/gmp 
-I/usr/local/gcc/gcc-20130807/Build/./mpfr -I/usr/local/gcc/gcc-20130807/mpfr 
-I/usr/local/gcc/gcc-20130807/mpc/src  \
../rts/targext.c -o targext.o
In file included from ../rts/targext.c:45:0:
/usr/local/gcc/gcc-20130807/gcc/coretypes.h:172:1: error: unknown type name 
'class'
 class rtl_opt_pass;
 ^
/usr/local/gcc/gcc-20130807/gcc/coretypes.h:174:1: error: unknown type name 
'namespace'
 namespace gcc {
 ^
/usr/local/gcc/gcc-20130807/gcc/coretypes.h:174:15: error: expected '=', ',', 
';', 'asm' or '__attribute__' before '{' token
 namespace gcc {
   ^
make[3]: *** [targext.o] Error 1

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] target/58065 ARM MALLOC_ABI_ALIGNMENT is wrong

[Bernd Edlinger]

Hello,

in the discussion about the PR middle-end/57748 it became obvious that the ARM 
target architecture should define a value for MALLOC_ABI_ALIGNMENT, because 
otherwise the default is simply word aligned, which causes sub-optimal code, at 
least for the neon fpu.

This simple patch fixes PR target/58065 by defining the MALLOC_ABI_ALIGNMENT as 
BIGGEST_ALIGNMNET.

As a proof that this has indeed some subtle influence on the generated code
I created a new test case: The function foo is called by bar, and bar uses
malloc to allocate the memory, with compiler options "-O3 -g0 -mfpu=neon
-mfloat-abi=softfp" the function foo is inlined into bar,
but the inlined version does not use vstr instructions any more, because
the front-end does assume that malloc returns 4 byte aligned memory.

Regards
Bernd Edlinger2013-08-07  Bernd Edlinger  

PR target/58065
Set MALLOC_ABI_ALIGNMENT to BIGGEST_ALIGNMENT for ARM.

* gcc/config/arm/arm.h: Define MALLOC_ABI_ALIGNMENT.
* gcc/testsuite/gcc.target/arm/pr58065.c: New testcase.



patch-arm-malloc-abi.diff
Description: Binary data

Re: New parameters to control stringop expansion libcall strategy

[Michael Zolotukhin]

> the option is designed for purpose like this.
That's great, thanks!

Michael
> David

On 6 August 2013 20:42, Xinliang David Li  wrote:
> Corrected two small problems reported by the style checker (The
> warnings about the EnumValue for options  in stringopt.opt are not
> valid).
>
> On Tue, Aug 6, 2013 at 1:46 AM, Michael Zolotukhin
>  wrote:
>> There are still some formatting issues (like 8 spaces instead of a
>> tab, wrong indentation of do-loop and some other places) - to reveal
>> some of them you could use contrib/check_GNU_style.sh script.
>> But that was a nitpicking again:) Actually I wanted to ask whether
>> you're going to use this option for some performance experiments
>> involving memmov/memset - if so, probably you could tune existing
>> cost-models as well? Is it possible?
>
> the option is designed for purpose like this.
>
> thanks,
>
> David
>
>>
>> Michael
>>
>> On 5 August 2013 20:44, Xinliang David Li  wrote:
>>> thanks. Updated patch attached.
>>>
>>> David
>>>
>>> On Mon, Aug 5, 2013 at 3:57 AM, Michael V. Zolotukhin
>>>  wrote:
 Hi,
 This is a really convenient option, thanks for working on it.
 I can't approve it as I'm not a maintainer, but it looks ok to me,
 except fot a small nitpicking: afair, comments should end with
 dot-space-space.

 Michael

 On 04 Aug 20:01, Xinliang David Li wrote:
> The attached is a new patch implementing the stringop inline strategy
> control using two new -m options:
>
> -mmemcpy-strategy=
> -mmemset-strategy=
>
> See changes in doc/invoke.texi for description of the new options. 
> Example:
>   
> -mmemcpy-strategy=rep_8byte:64:unaligned,unrolled_loop:2048:unaligned,libcall:-1:unaligned
>
> tells compiler to inline memcpy using rep_8byte when the size is no
> larger than 64 byte, using unrolled_loop when size is no larger than
> 2048, and for size > 2048, using library call. In all cases,
> destination alignment adjustment is not done.
>
> Tested on x86-64/linux. Ok for trunk?
>
> thanks,
>
> David
>
> 2013-08-02  Xinliang David Li  
>
> * config/i386/stringop.def: New file.
> * config/i386/stringop.opt: New file.
> * config/i386/i386-opts.h: Include stringopt.def.
> * config/i386/i386.opt: Include stringopt.opt.
> * config/i386/i386.c (ix86_option_override_internal):
> Override default size based stringop inline strategies
> with options.
> * config/i386/i386.c (ix86_parse_stringop_strategy_string):
> New function.
>
> 2013-08-04  Xinliang David Li  
>
> * testsuite/gcc.target/i386/memcpy-strategy-1.c: New test.
> * testsuite/gcc.target/i386/memcpy-strategy-2.c: Ditto.
> * testsuite/gcc.target/i386/memset-strategy-1.c: Ditto.
> * testsuite/gcc.target/i386/memcpy-strategy-3.c: Ditto.
>
>
>
>
> On Fri, Aug 2, 2013 at 9:21 PM, Xinliang David Li  
> wrote:
> > On x86_64, when the expected size of memcpy/memset is known (e.g, with
> > FDO), libcall strategy is used with the size is > 8192. This value is
> > hard coded, which makes it hard to do performance tuning. This patch
> > adds two new parameters to do that. Potential usage includes
> > per-application libcall strategy min-size tuning based on summary data
> > with FDO (e.g, instruction workset size).
> >
> > Bootstrap and tested on x86_64/linux. Ok for trunk?
> >
> > thanks,
> >
> > David
> >
> >
> > 2013-08-02  Xinliang David Li  
> >
> > * params.def: New parameters.
> > * config/i386/i386.c (ix86_option_override_internal):
> > Override default libcall size limit with parameters.

> Index: config/i386/stringop.def
> ===
> --- config/i386/stringop.def  (revision 0)
> +++ config/i386/stringop.def  (revision 0)
> @@ -0,0 +1,42 @@
> +/* Definitions for option handling for IA-32.
> +   Copyright (C) 2013 Free Software Foundation, Inc.
> +
> +This file is part of GCC.
> +
> +GCC is free software; you can redistribute it and/or modify
> +it under the terms of the GNU General Public License as published by
> +the Free Software Foundation; either version 3, or (at your option)
> +any later version.
> +
> +GCC is distributed in the hope that it will be useful,
> +but WITHOUT ANY WARRANTY; without even the implied warranty of
> +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +GNU General Public License for more details.
> +
> +Under Section 7 of GPL version 3, you are granted additional
> +permissions described in the GCC Runtime Library Exception, version
> +3.1, as published by the Free Software Foundation.
>>>

Re: [FIXED] Generic lambda symbol table bug

[Adam Butcher]

Hi Jason,

On Mon, 05 Aug 2013 17:26:12 -0400, Jason Merrill wrote:
> On 08/04/2013 07:45 PM, Adam Butcher wrote:
> > What should I do about the symtab nullptr issue?
> > (http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00043.html)  Should I
> > leave the workaround in my patch set as a standalone commit to be
> > remedied later or should I try to squash it?  Or is the hack appropriate
> > for some reason?
>
> Let's fix it.
>
> >0x810670 handle_alias_pairs
> >../../gcc/cgraphunit.c:1014
>
> This suggests that somehow the call operator template wound up in
> alias_pairs.  This is very mysterious; I really don't know why there
> would be any aliases in this testcase, much less one involving the
> operator().  The offending code should be pretty straightforward to find
> with a watchpoint on alias_pairs.
>
Turns out that it was the presence of any alias that was triggering the issue.
The call op itself was not in the 'alias_pairs' vector.  It happened because, if
aliases are present, 'handle_alias_pairs' causes an initialization of the
'assembler_name_hash' containing every known symbol.  And for some reason, which
I now understand, the uninstantiated call operator template result declaration
was being added to the symbol table (without an asmname).  The particular
aliases my original program encountered from  were the gthread ones.
The following program (no includes, no conversion ops, no implicit templates) is
sufficient and minimal to reproduce the issue.

   int dummy() {}
   static decltype(dummy) weak_dummy __attribute__ ((__weakref__("dummy")));

   int main()
   {
 int i;
 [i]  (T) {};
   }

The patch below fixes it.  But a cleaner way might be to extend the "processing
template declaration" state from lambda declarator all the way to the end of the
lambda body.  This would match with the scenario that occurs with a standard
in-class member function template definition.  To do that elegantly would
require a bit of refactoring of the lambda parser code.

The patch below does the job by avoiding the cause of the erroneous symbol table
entry, 'expand_or_defer_fn', explicitly.

Assuming you're okay with this fix, how do you want me to submit the final
patchset for this stuff?  There are two features here which I was intending to
submit in the following order as two patches:

  - Generic lambdas specified with explicit template parameter list.  This
teaches GCC how to deal with lambda call op templates (and their conversion
operators) but does not actually implement the 'generic lambda' spec in
N3690 5.1.2.5. 

  - Generalized implicit function template support via 'auto params'; a step
along the road to terse templates.  The necessary propagation into the
lambda code has a side-effect of supporting 'generic lambdas' as proposed by
the C++14 draft standard.

I'm not sure which dialect guards to put these features behind though.
Strictly:

  a) Generic lambdas created fully implicitly via 'auto params' should be
 accepted with -std=c++1y and -std=gnu++1y since it is actually spec'd by
 the draft.

  b) Generic lambdas created with an explicit template parameter list should be
 accepted with -std=gnu++1y only.

  c) Generalized implicit function templates should be accepted by -std=gnu++1y
 only.

Due to the generalized implementation of the feature guarded by (c), it may be
messy (or maybe costly) to implement (a).

Cheers,
Adam


- fix for symtab issue --

Don't add generic lambda call ops to the symbol table.

Typically, 'processing_template_decl' is high throughout an in-class member
function template definition, so 'expand_or_defer_fn' normally does nothing.
It is difficult, without considerable refactoring of the current lambda parser
implementation, to mimic the situation that arises with a conventional in-class
member template definition.  Hence, this patch prevents 'expand_or_defer_fn'
from being called for generic lambdas.

The bug was triggered by the presence of at least one alias (such as a weak ref)
causing the assembler name hash to be initialized with every known symbol.  The
call operator template should not be added to the symbol table; only
instantiations of it should.

---
 gcc/cp/lambda.c |  8 ++--
 gcc/cp/parser.c |  6 +-
 gcc/symtab.c| 18 --
 3 files changed, 11 insertions(+), 21 deletions(-)

diff --git a/gcc/cp/lambda.c b/gcc/cp/lambda.c
index c90a27c..5fdc551 100644
--- a/gcc/cp/lambda.c
+++ b/gcc/cp/lambda.c
@@ -915,7 +915,9 @@ maybe_add_lambda_conv_op (tree type)
   finish_compound_stmt (compound_stmt);
   finish_function_body (body);
 
-  expand_or_defer_fn (finish_function (2));
+  fn = finish_function (/*inline*/2);
+  if (!generic_lambda_p)
+expand_or_defer_fn (fn);
 
   /* Generate the body of the conversion op.  */
 
@@ -931,7 +933,9 @@ maybe_add_lambda_conv_op (tree type)
   finish_compound_stmt (compound_stmt);
   finish_function_body (body);
 
-  expand

Re: [C++ Patch / RFC] PR 46206

[Paolo Carlini]

Hi,

On 08/07/2013 01:08 AM, Jason Merrill wrote:

On 08/06/2013 06:14 PM, Paolo Carlini wrote:

Ah I see, thanks. We reject this before and after the patch. Shall I add
this variant to the new testcase?

Sure.

Thanks. Thus after a further round of testing I'm going to apply the below.

Thanks,
Paolo.


/cp
2013-08-07  Paolo Carlini  

PR c++/46206
* name-lookup.c (lookup_name_real_1): Handle iter->type before
iter->value.

/testsuite
2013-08-07  Paolo Carlini  

PR c++/46206
* g++.dg/lookup/typedef2.C: New.
Index: cp/name-lookup.c
===
--- cp/name-lookup.c(revision 201524)
+++ cp/name-lookup.c(working copy)
@@ -4740,11 +4740,11 @@ lookup_name_real_1 (tree name, int prefer_type, in
  continue;
 
/* If this is the kind of thing we're looking for, we're done.  */
-   if (qualify_lookup (iter->value, flags))
+   if ((flags & LOOKUP_PREFER_TYPES)
+   && qualify_lookup (iter->type, flags))
+ binding = iter->type;
+   else if (qualify_lookup (iter->value, flags))
  binding = iter->value;
-   else if ((flags & LOOKUP_PREFER_TYPES)
-&& qualify_lookup (iter->type, flags))
- binding = iter->type;
else
  binding = NULL_TREE;
 
Index: testsuite/g++.dg/lookup/typedef2.C
===
--- testsuite/g++.dg/lookup/typedef2.C  (revision 0)
+++ testsuite/g++.dg/lookup/typedef2.C  (working copy)
@@ -0,0 +1,30 @@
+// PR c++/46206
+
+class Foo1
+{
+  int u, v, w, x;
+  typedef struct Bar { } Bar;
+  virtual void foo(void) {
+struct Bar bar;
+  }
+};
+
+class Foo2
+{
+  int u, v, w;
+  typedef struct Bar { } Bar;
+  Bar bar;
+  virtual void foo(void) {
+struct Bar bar;
+  }
+};
+
+class Foo3
+{
+  int u, v, w;
+  typedef struct Bar { } Bar;
+  int Bar;   // { dg-error "conflicts" }
+  virtual void foo(void) {
+struct Bar bar;
+  }
+};

Re: Request to merge Undefined Behavior Sanitizer in (take 2)

[Marek Polacek]

On Tue, Aug 06, 2013 at 07:07:27PM -0400, Jason Merrill wrote:
> >I think, what we could do, is to tweak verify_constant like this:
> >
> >+  /* This is to handle e.g. the goofy 'case 0 * (1 / 0)' case.  */
> >+  if (flag_sanitize & SANITIZE_UNDEFINED
> >+  && TREE_CODE (t) == CALL_EXPR
> >+  && is_ubsan_builtin (t))
> >+{
> >+  error ("undefined behavior occured");
> >+  return *non_constant_p;
> >+}
> 
> I think I'd rather handle ubsan builtins specially in dump_expr.

I might've misunderstood what you mean.  If we drop the hunk above,
then we'll call 
error ("%q+E is not a constant expression", t);
so, we'll print "is not a constant expression" no matter what, we
surely can recognize the ubsan built-ins in dump_expr, but what would
we do then?

Marek

Re: Go patch committed: Always put immutable structs in unique section

[Uros Bizjak]

On Tue, Aug 6, 2013 at 6:42 PM, Ian Lance Taylor  wrote:

> I committed this patch that I think should fix this problem.
> Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
> Committed to mainline and 4.8 branch.
>
> 2013-08-06  Ian Lance Taylor  
>
> * go-gcc.cc (Gcc_backend::immutable_struct_set_init): Use
> compute_reloc_for_constant.

Yes, the gcc-go testsuite is now clean, but there remain a few
warnings in the libgo testsuite. I have attached the testsuite run log
to this message (there are also some new errors, but these are due to
unrelated recent compiler changes. I'll investigate these later).

Thanks,
Uros.


libgo.log
Description: Binary data

[c++-concepts] Merge from trunk

[Gabriel Dos Reis]

trunk was merged into c++-concepts branch at revision 201560.
I resolved some conflicts in cp caused by recent merges and ongoing work
on trunk.

-- Gaby

Re: RFC/A: PR 58079: CONST_INT mode assert in combine.c:do_SUBST

[Richard Biener]

Richard Sandiford  wrote:
>PR 58079 is about the do_SUBST assert:
>
>  /* Sanity check that we're replacing oldval with a CONST_INT
>that is a valid sign-extension for the original mode.  */
>  gcc_assert (INTVAL (newval)
> == trunc_int_for_mode (INTVAL (newval), GET_MODE (oldval)));
>
>triggering while trying to optimise the temporary result:
>
>  (eq (const_int -73 [0xffb7])
>  (reg:QI 234 [ MEM[(const u8 *)buf_7(D) + 4B] ])
>
>combine_simplify_rtx calls simplify_comparison, which first
>canonicalises
>the order so that the constant is second and then promotes the
>comparison
>to SImode (the first supported comparison mode on MIPS).  So we end up
>with:
>
>  (eq (zero_extend:SI (reg:QI 234 [ MEM[(const u8 *)buf_7(D) + 4B] ]))
>  (const_int 183 [0xb7]))
>
>So far so good.  But combine_simplify_rtx then tries to install the
>new operands in-place, with the second part of:
>
> /* If the code changed, return a whole new comparison.  */
> if (new_code != code)
>   return gen_rtx_fmt_ee (new_code, mode, op0, op1);
>
> /* Otherwise, keep this operation, but maybe change its operands.
>This also converts (ne (compare FOO BAR) 0) to (ne FOO BAR).  */
> SUBST (XEXP (x, 0), op0);
> SUBST (XEXP (x, 1), op1);
>
>And this triggers the assert because we're replacing a QImode register
>with the non-QImode constant 183.
>
>One fix would be to extend the new_code != code condition, as below.
>This should avoid the problem cases without generating too much
>garbage rtl.  But if the condition's getting this complicated,
>perhaps it'd be better just to avoid SUBST here?  I.e.
>
> if (new_code != code || op0 != XEXP (x, 0) || op1 != XEXP (x, 1))
>   return gen_rtx_fmt_ee (new_code, mode, op0, op1);
>
>Just asking though. :-)
>
>Tested on mipsisa64-elf.  OK to install?

Looks reasonable to me. Thus ok if nobody objects within 24h.

Thanks,
Richard.

>Thanks,
>Richard
>
>
>gcc/
>   PR rtl-optimization/58079
>   * combine.c (combine_simplify_rtx): Avoid using SUBST if
>   simplify_comparison has widened a comparison with an integer.
>
>gcc/testsuite/
>   * gcc.dg/torture/pr58079.c: New test.
>
>Index: gcc/combine.c
>===
>--- gcc/combine.c  2013-08-06 22:03:32.644642305 +0100
>+++ gcc/combine.c  2013-08-06 22:08:51.944653901 +0100
>@@ -5803,8 +5803,15 @@ combine_simplify_rtx (rtx x, enum machin
>   return x;
>   }
> 
>-/* If the code changed, return a whole new comparison.  */
>-if (new_code != code)
>+/* If the code changed, return a whole new comparison.
>+   We also need to avoid using SUBST in cases where
>+   simplify_comparison has widened a comparison with a CONST_INT,
>+   since in that case the wider CONST_INT may fail the sanity
>+   checks in do_SUBST.  */
>+if (new_code != code
>+|| (CONST_INT_P (op1)
>+&& GET_MODE (op0) != GET_MODE (XEXP (x, 0))
>+&& GET_MODE (op0) != GET_MODE (XEXP (x, 1
>   return gen_rtx_fmt_ee (new_code, mode, op0, op1);
> 
> /* Otherwise, keep this operation, but maybe change its operands.
>Index: gcc/testsuite/gcc.dg/torture/pr58079.c
>===
>--- /dev/null  2013-07-23 18:41:43.074412242 +0100
>+++ gcc/testsuite/gcc.dg/torture/pr58079.c 2013-08-06
>22:05:06.249523398 +0100
>@@ -0,0 +1,107 @@
>+/* { dg-options "-mlong-calls" { target mips*-*-* } } */
>+
>+typedef unsigned char u8;
>+typedef unsigned short u16;
>+typedef unsigned int __kernel_size_t;
>+typedef __kernel_size_t size_t;
>+struct list_head {
>+ struct list_head *next;
>+};
>+
>+struct dmx_ts_feed {
>+ int is_filtering;
>+};
>+struct dmx_section_feed {
>+ u16 secbufp;
>+ u16 seclen;
>+ u16 tsfeedp;
>+};
>+
>+typedef int (*dmx_ts_cb) (
>+  const u8 * buffer1,
>+  size_t buffer1_length,
>+  const u8 * buffer2,
>+  size_t buffer2_length
>+);
>+
>+struct dvb_demux_feed {
>+ union {
>+  struct dmx_ts_feed ts;
>+  struct dmx_section_feed sec;
>+ } feed;
>+ union {
>+  dmx_ts_cb ts;
>+ } cb;
>+ int type;
>+ u16 pid;
>+ int ts_type;
>+ struct list_head list_head;
>+};
>+
>+struct dvb_demux {
>+ int (*stop_feed)(struct dvb_demux_feed *feed);
>+ struct list_head feed_list;
>+};
>+
>+
>+static
>+inline
>+__attribute__((always_inline))
>+u8
>+payload(const u8 *tsp)
>+{
>+ if (tsp[3] & 0x20) {
>+   return 184 - 1 - tsp[4];
>+ }
>+ return 184;
>+}
>+
>+static
>+inline
>+__attribute__((always_inline))
>+int
>+dvb_dmx_swfilter_payload(struct dvb_demux_feed *feed, const u8 *buf)
>+{
>+ int count = payload(buf);
>+ int p;
>+ if (count == 0)
>+  return -1;
>+ return feed->cb.ts(&buf[p], count, ((void *)0), 0);
>+}
>+
>+static
>+inline
>+__attribute__((always_inline))
>+void
>+dvb_dmx_swfilter_packet_type(struct dvb_d

[v3] Fix libstdc++/58098

[Paolo Carlini]

Hi,

I'm applying this mainline and 4_8-branch. Tested x86_64-linux.

Thanks,
Paolo.

//
2013-08-07  Paolo Carlini  

PR libstdc++/58098
* include/bits/random.h (cauchy_distribution<>::min,
extreme_value_distribution<>::min, normal_distribution<>::min,
student_t_distribution<>::min): Fix.
* include/ext/random (normal_mv_distribution<>::min): Likewise.
* testsuite/26_numerics/random/cauchy_distribution/cons/parms.cc:
Adjust.
testsuite/26_numerics/random/cauchy_distribution/cons/default.cc:
Likewise.
* testsuite/26_numerics/random/extreme_value_distribution/cons/
parms.cc: Likewise.
testsuite/26_numerics/random/extreme_value_distribution/cons/
default.cc: Likewise.
* testsuite/26_numerics/random/normal_distribution/cons/parms.cc:
Likewise.
* testsuite/26_numerics/random/normal_distribution/cons/default.cc:
Likewise.
* testsuite/26_numerics/random/student_t_distribution/cons/parms.cc:
Likewise.
* testsuite/26_numerics/random/student_t_distribution/cons/default.cc:
Likewise.
* testsuite/ext/random/normal_mv_distribution/cons/parms.cc: Likewise.
* testsuite/ext/random/normal_mv_distribution/cons/default.cc: Likewise.

* testsuite/26_numerics/random/exponential_distribution/cons/parms.cc:
Minor tweak.
* testsuite/26_numerics/random/exponential_distribution/cons/default.cc:
Likewise.

* testsuite/ext/von_mises_distribution/*: Move to...
* testsuite/ext/random/von_mises_distribution/*: ... here.
* testsuite/ext/triangular_distribution/*: Move to...
* testsuite/ext/random/triangular_distribution/*: ... here.
Index: include/bits/random.h
===
--- include/bits/random.h   (revision 201558)
+++ include/bits/random.h   (working copy)
@@ -2178,7 +2178,7 @@
*/
   result_type
   min() const
-  { return std::numeric_limits::min(); }
+  { return std::numeric_limits::lowest(); }
 
   /**
* @brief Returns the least upper bound value of the distribution.
@@ -3011,7 +3011,7 @@
*/
   result_type
   min() const
-  { return std::numeric_limits::min(); }
+  { return std::numeric_limits::lowest(); }
 
   /**
* @brief Returns the least upper bound value of the distribution.
@@ -3428,7 +3428,7 @@
*/
   result_type
   min() const
-  { return std::numeric_limits::min(); }
+  { return std::numeric_limits::lowest(); }
 
   /**
* @brief Returns the least upper bound value of the distribution.
@@ -5136,7 +5136,7 @@
*/
   result_type
   min() const
-  { return std::numeric_limits::min(); }
+  { return std::numeric_limits::lowest(); }
 
   /**
* @brief Returns the least upper bound value of the distribution.
Index: include/ext/random
===
--- include/ext/random  (revision 201558)
+++ include/ext/random  (working copy)
@@ -791,7 +791,7 @@
   result_type
   min() const
   { result_type __res;
-   __res.fill(std::numeric_limits<_RealType>::min());
+   __res.fill(std::numeric_limits<_RealType>::lowest());
return __res; }
 
   /**
Index: testsuite/26_numerics/random/cauchy_distribution/cons/default.cc
===
--- testsuite/26_numerics/random/cauchy_distribution/cons/default.cc
(revision 201558)
+++ testsuite/26_numerics/random/cauchy_distribution/cons/default.cc
(working copy)
@@ -35,7 +35,7 @@
   VERIFY( u.a() == 0.0 );
   VERIFY( u.b() == 1.0 );
   typedef std::cauchy_distribution<>::result_type result_type;
-  VERIFY( u.min() == std::numeric_limits::min() );
+  VERIFY( u.min() == std::numeric_limits::lowest() );
   VERIFY( u.max() == std::numeric_limits::max() );
 }
 
Index: testsuite/26_numerics/random/cauchy_distribution/cons/parms.cc
===
--- testsuite/26_numerics/random/cauchy_distribution/cons/parms.cc  
(revision 201558)
+++ testsuite/26_numerics/random/cauchy_distribution/cons/parms.cc  
(working copy)
@@ -35,7 +35,7 @@
   VERIFY( u.a() == 5.0 );
   VERIFY( u.b() == 2.0 );
   typedef std::cauchy_distribution<>::result_type result_type;
-  VERIFY( u.min() == std::numeric_limits::min() );
+  VERIFY( u.min() == std::numeric_limits::lowest() );
   VERIFY( u.max() == std::numeric_limits::max() );
 }
 
Index: testsuite/26_numerics/random/exponential_distribution/cons/default.cc
===
--- testsuite/26_numerics/random/exponential_distribution/cons/default.cc   
(revision 201558)
+++ testsuite/26_numerics/random/exponential_distribution/cons/default.cc   
(working copy)
@@ -

Re: [PATCH/Merge Request] Vtable Verification feature.

[Dominique Dhumieres]

Revision 201555 breaks boostrap on x86_64-apple-darwin10:

...
Checking multilib configuration for libvtv...
make  all-recursive
Making all in testsuite
/bin/sh: line 0: cd: testsuite: No such file or directory
make[4]: *** [all-recursive] Error 1
make[3]: *** [all] Error 2
make[2]: *** [all-stage1-target-libvtv] Error 2
make[1]: *** [stage1-bubble] Error 2
make: *** [all] Error 2

According to

* configure.ac: Add target-libvtv to target_libraries; disable libvtv
on non-linux systems; add target-libvtv to noconfigdirs; add
libsupc++/.libs to C++ library search paths.

libvtv should not be built on darwin, but in config.log I see

...
configure:3222: checking for libvtv support
configure:3232: result: yes
...

TIA

Dominique

Re: Passes are now C++ classes (was Re: [PATCH 03/11] Handwritten part of conversion of passes to C++ classes)

[Eric Botcazou]

> The mips*-*-* targets are not building.  It looks like the mips reorg
> pass (pass_mips_machine_reorg2) in config/mips/mips.c was not converted
> and/or was not converted correctly.

Likewise for the SPARC targets, because of the same issue.  David, could you 
take a quick look?  Thanks in advance.

-- 
Eric Botcazou

[PATCH][tree-optimization] Fix PR58088

[Kyrylo Tkachov]

Hi all,

In PR58088 the constant folder goes into an infinite recursion and runs out of
stack space because of two conflicting optimisations:
(X * C1) & C2 plays dirty when nested inside an IOR expression like so: ((X *
C1) & C2) | C4. One can undo the other leading to an infinite recursion.

Thanks to Marek for finding the IOR case.

This patch fixes that by checking in the IOR case that the change to C2 will
not conflict with the AND case transformation. Example testcases in the PR on
bugzilla.

This issue is present in 4.8.1 as well as trunk. However, I think 4.8 uses a
different API for double_int, so this patch will need to be reworked for 4.8.

In the meantime,
Ok for trunk?

Bootstrapped on x86_64-linux-gnu and tested arm-none-eabi on qemu.


Thanks,
Kyrill

2013-08-07  Kyrylo Tkachov  

* gcc/fold-const.c (mask_with_trailing_zeros): New function.
(fold_binary_loc): Make sure we don't recurse infinitely
when the X in (X & C1) | C2 is a tree of the form (Y * K1) & K2.
Use mask_with_trailing_zeros where appropriate.


2013-08-07  Kyrylo Tkachov  

* gcc.c-torture/compile/pr58088.c: New test.

pr58088.patch
Description: Binary data

Re: PPC64 HTM support (was [buildbot] r201513: Invalid cast)

[Peter Bergner]

On Tue, 2013-08-06 at 22:01 -0500, Peter Bergner wrote:
> I'll bootstrap and regtest the change
> below and commit it as an obvious fix when that is done.

Everything looked as as expected.  Committed.

Peter

Re: [PATCH] Fix broken build on sparc (was Re: [buildbot] r201508: Build failures after pass C++ conversion)

[Eric Botcazou]

> I think it's r201508, but in any case, I'm attaching a patch which fixes
> this build error.  Only very lightly tested so far, with configure
> --target=sparc-linux with build&host x86_64.  Was able to build a cc1
> and step through the changed code in the debugger, though am getting
> "cc1: error: no include path in which to search for stdc-predef.h"

Looks good, please install if not already done.

-- 
Eric Botcazou

lm32 build error

[Joel Sherrill]

Hi

This has been around for a while as PR52466 which has
a patch. I have attached the patch.  Is it OK to apply to
the open branches?

2013-08-07  Joel Sherrill 

* configure.ac (lm32*-*-*): Use SJLJ exceptions.

--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

diff --git a/gcc/configure.ac b/gcc/configure.ac
index f629d15..d00c69b 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -1209,6 +1209,10 @@ force_sjlj_exceptions=yes],
 force_sjlj_exceptions=yes
 enableval=yes
 ;;
+  lm32*-*-*)
+force_sjlj_exceptions=yes
+enableval=yes
+;;
   *)
 force_sjlj_exceptions=no
 ;;

Re: [patch, ARM] require 64-bit hw-int for all arm targets

[Richard Earnshaw]

On 07/08/13 01:25, Joseph S. Myers wrote:
> On Tue, 30 Jul 2013, Richard Earnshaw wrote:
> 
>> Most arm target configs now require a 64-bit HW-int.  Unfortunately a few of
>> the older, less commonly used config targets do not.  The code in arm.c now
>> pretty much requires that a 64-bit HW-int is used, especially for
>> vectorization to work.
>>
>> This patch makes 64-bit HW-int the default for all arm configs and cleans up
>> the configure script accordingly.
>>
>>  * config.gcc (arm): Require 64-bit host-wide-int for all ARM
>>  target configs.
> 
> The configuration in libcpp/configure.ac of which targets need 64-bit 
> HOST_WIDE_INT always needs to be kept in sync with that in gcc/config.gcc.
> 


Oops.  Fixed thusly:

2013-08-07  Richard Earnshaw  

* configure.ac: Set need_64bit_hwint for all arm targets.
* configure: Regenerated.

--- configure   (revision 201547)
+++ configure   (local)
@@ -7152,9 +7152,7 @@ fi
 case $target in
aarch64*-*-* | \
alpha*-*-* | \
-   arm*-*-*eabi* | \
-   arm*-*-rtems* | \
-   arm*-*-symbianelf* | \
+   arm*-*-* | \
x86_64-*-* | \
ia64-*-* | \
hppa*64*-*-* | \
--- configure.ac(revision 201547)
+++ configure.ac(local)
@@ -184,9 +184,7 @@ m4_changequote(,)
 case $target in
aarch64*-*-* | \
alpha*-*-* | \
-   arm*-*-*eabi* | \
-   arm*-*-rtems* | \
-   arm*-*-symbianelf* | \
+   arm*-*-* | \
x86_64-*-* | \
ia64-*-* | \
hppa*64*-*-* | \

[Patch, Fortran] PR 58099: [4.8/4.9 Regression] [F03] over-zealous procedure-pointer error checking

[Janus Weil]

Hi all,

here is a small regression-fix patch for a problem with procedure
pointers and the PURE attribute, for details see the PR. In essence:
gfc_compare_interfaces is asymmetric in the two interfaces it compares
(e.g. regarding the PURE attribute), and we must not symmetrize it by
calling it twice with exchanged arguments.

Regtested on x86_64-unknown-linux-gnu. Ok for trunk?

Cheers,
Janus



2013-08-07  Janus Weil  

PR fortran/58099
* expr.c (gfc_check_pointer_assign): Remove second call to
'gfc_compare_interfaces' with swapped arguments.
* interface.c (gfc_compare_interfaces): Symmetrize the call to
'check_result_characteristics' by calling it with swapped arguments.

2013-08-07  Janus Weil  

PR fortran/58099
* gfortran.dg/proc_ptr_43.f90: New.


pr58099.diff
Description: Binary data


proc_ptr_43.f90
Description: Binary data

Re: Request to merge Undefined Behavior Sanitizer in (take 2)

[Jason Merrill]

On 08/07/2013 06:06 AM, Marek Polacek wrote:

I might've misunderstood what you mean.  If we drop the hunk above,
then we'll call
 error ("%q+E is not a constant expression", t);
so, we'll print "is not a constant expression" no matter what


Yes, that's fine; 1/0 is not a constant expression, because it has 
undefined behavior.



we surely can recognize the ubsan built-ins in dump_expr, but what would
we do then?


Print something more meaningful to the user.

Jason

RE: [PATCH][tree-optimization] Fix PR58088

[Kyrylo Tkachov]

> This issue is present in 4.8.1 as well as trunk. However, I think 4.8
> uses a different API for double_int, so this patch will need to be reworked
for
> 4.8.

Actually, I was confused. This patch applies to 4.8.1 as well and fixes the
issue. Passes bootstrap on x86_64-linux-gnu and testing arm-none-eabi.

Therefore, OK to backport to 4.8 as well?

Thanks,
Kyrill

Re: Request to merge Undefined Behavior Sanitizer in (take 2)

[Marek Polacek]

On Tue, Aug 06, 2013 at 05:24:08PM -0400, Jason Merrill wrote:
> On 08/05/2013 07:24 AM, Marek Polacek wrote:
> >On Sat, Aug 03, 2013 at 12:24:32PM -0400, Jason Merrill wrote:
> >>Where are the SAVE_EXPRs coming from?  It doesn't seem to me that x
> >>needs to be wrapped in a SAVE_EXPR at all in this case.  For cases
> >>where the SAVE_EXPR is needed and not used in the test, you could
> >>add the SAVE_EXPR before the condition with a COMPOUND_EXPR.
> >
> >Those SAVE_EXPRs are coming from c-typeck.c in this case:
> >
> >   if (flag_sanitize & SANITIZE_UNDEFINED
> >   && current_function_decl != 0
> >   && (doing_div_or_mod || doing_shift))
> > {
> >   /* OP0 and/or OP1 might have side-effects.  */
> >   op0 = c_save_expr (op0);
> >   op1 = c_save_expr (op1);
> 
> Yes, but why do we need to wrap op0 in a save_expr?  That's only
> necessary if we're going to be evaluating it twice on the same path,
> but here it's only evaluated once on each path.

True, in this particular case wrapping x in the SAVE_EXPR isn't
needed, thus the following should work equally:

--- a/gcc/c/c-typeck.c
+++ b/gcc/c/c-typeck.c
@@ -10493,9 +10493,12 @@ build_binary_op (location_t location, enum tree_code 
code,
   && (doing_div_or_mod || doing_shift))
 {
   /* OP0 and/or OP1 might have side-effects.  */
-  op0 = c_save_expr (op0);
+  if (!doing_shift || flag_isoc99)
+{
+  op0 = c_save_expr (op0);
+  op0 = c_fully_fold (op0, false, NULL);
+   }
   op1 = c_save_expr (op1);
-  op0 = c_fully_fold (op0, false, NULL);
   op1 = c_fully_fold (op1, false, NULL);
   if (doing_div_or_mod)
instrument_expr = ubsan_instrument_division (location, op0, op1);

(It would merit a comment, for sure.) 
I actually don't know what I prefer more, but if you like this version
more, I'll go with it.  Maybe this is better because we don't have to
create SAVE_EXPR and also we avoid one fold_build call.  Thanks,

Marek

Re: New option to do fine grain control [on|off] of micro-arch specific features : -mtune-ctrl=....

[Xinliang David Li]

Ping?

David

On Sat, Aug 3, 2013 at 12:36 PM, Xinliang David Li  wrote:
> Hi, GCC/i386 currently has about 73 boolean parameters/knobs (defined
> in ix86_tune_features[], indexed by ix86_tune_indices) to perform
> micro-arch specific performance tuning. However such settings are hard
> coded (fixed with a given -mtune setting) and is very hard to do
> performance experiment.
>
> The attached patch fixes the problem. The patch introduces a new
> option -mtune-ctrl=. Its parameter is a comma separated list of
> feature names to turn on associated features. Feature name can be
> prefixed by ^ to do the opposite. For instance,
>
>   -mtune-ctrl=prologue_using_move,epilogue_using_move,^pad_returns
>
> tells the compiler to use move instructions in prologue/epilogue
> (instead of push/pop), and *not* pad return instructions.
>
> To facilitate the change, the feature tuning enums defined in i386.h
> are moved to a new file x86-tune.def and this file can be used to
> generate both the enums and names of the features.
>
>
> Ok for trunk?
>
>
> thanks,
>
> David
>
> 2013-08-03  Xinliang David Li  
>
> * config/i386/i386.opt: New option -mtune-ctrl=.
> * config/i386/x86-tune.def: New file.
> * config/i386/i386.h: include x86-tune.def.
> * config/i386/i386.c (ix86_option_override_internal):
> Parsing -mtune-ctrl= option and set tune features.

Re: New option to do fine grain control [on|off] of micro-arch specific features : -mtune-ctrl=....

[Jan Hubicka]

> Ping?
> 
> David
> 
> On Sat, Aug 3, 2013 at 12:36 PM, Xinliang David Li  wrote:
> > Hi, GCC/i386 currently has about 73 boolean parameters/knobs (defined
> > in ix86_tune_features[], indexed by ix86_tune_indices) to perform
> > micro-arch specific performance tuning. However such settings are hard
> > coded (fixed with a given -mtune setting) and is very hard to do
> > performance experiment.
> >
> > The attached patch fixes the problem. The patch introduces a new
> > option -mtune-ctrl=. Its parameter is a comma separated list of
> > feature names to turn on associated features. Feature name can be
> > prefixed by ^ to do the opposite. For instance,
> >
> >   -mtune-ctrl=prologue_using_move,epilogue_using_move,^pad_returns
> >
> > tells the compiler to use move instructions in prologue/epilogue
> > (instead of push/pop), and *not* pad return instructions.
> >
> > To facilitate the change, the feature tuning enums defined in i386.h
> > are moved to a new file x86-tune.def and this file can be used to
> > generate both the enums and names of the features.
> >
> >
> > Ok for trunk?

Yes, this patch seems fine to me (as an undocumented option we should not
be obliged to fix any ices from non-sential combinations of flags and in
fact I do not really know of any).
I wonder if we can't feed initial_ix86_tune_features so we get rid of
two places that needs to be kept in sync when adding new knob?

Honza
> >
> >
> > thanks,
> >
> > David
> >
> > 2013-08-03  Xinliang David Li  
> >
> > * config/i386/i386.opt: New option -mtune-ctrl=.
> > * config/i386/x86-tune.def: New file.
> > * config/i386/i386.h: include x86-tune.def.
> > * config/i386/i386.c (ix86_option_override_internal):
> > Parsing -mtune-ctrl= option and set tune features.

Re: [PATCH] Fix broken build on sparc (was Re: [buildbot] r201508: Build failures after pass C++ conversion)

[David Malcolm]

On Wed, 2013-08-07 at 15:25 +0200, Eric Botcazou wrote:
> Looks good, please install if not already done.
Thanks; I've now committed this to trunk as r201569.

i686 pic & DCmode

[Nathan Sidwell]

In poking at another set of fails encountered with an i686-elf toolchain 
(http://gcc.gnu.org/ml/gcc/2013-08/msg00081.html), I find that complex double 
returns and PIC do not play together.


Libgcc's __muldc3 was attempting to return the value in registers, whereas every 
caller expected it to be returned via pointer-to-aggregate parm.  Turned out to 
be PIC at fault -- libgcc is built as PIC, the callers weren't.


To determine if the return value should go in memory, function.c contains 
aggregate_value_p, which really means 'can't return in registers'.  That calls 
the backend return_in_mem hook, which for i686-elf simply forces BLKmode things 
to memory (the bundle of fun I refer to in the link).  As this is DCmode, we 
fall through to the default behaviour, which after a few other checks, picks the 
return register and then looks to see if the span of registers needed for the 
object are all call clobbered.


On x86, the registers are numbered eax, edx, ecx, ebx.  The first 3 are call 
clobbered and ebx is call preserved.  Hence (in non PIC), DCmode objects can't 
be placed there and a pointer-to-result parm is added.  In PIC mode, ebx remains 
call preserved, but becomes a fixed regs.  A fixed reg must also set call_used, 
and hey presto, we suddenly think all 4 are call clobbered.


This causes the result to be placed in those 4 registers -- and then the 
epilogue code restores the incoming ebx value, for extra brokenness.


The usual x86 ports avoid this, because their must_return_in_mem hooks DTRT 
already and we never fall into the default case.


I am very surprised this hasn't bitten someone before -- I presume this never 
worked with i686-elf.  It is possible this'll change some other ABI where a 
fixed reg was permitted to be used in the manner that this now prohibits, but I 
have a hard time thinking that happens.  Shout if you know of one.


Anyhow, I've not run a full regression test with this patch, but it does 
indicate that the i686-elf config's ABI is a bunch of accidents, rather than a 
coherent design.


nathan
2013-08-07  Nathan Sidwell  

gcc/
* function.c (aggregate_value_p): Don't use a fixed reg either.

Index: gcc/function.c
===
--- gcc/function.c  (revision 417583)
+++ gcc/function.c  (working copy)
@@ -2031,7 +2031,7 @@ aggregate_value_p (const_tree exp, const
   regno = REGNO (reg);
   nregs = hard_regno_nregs[regno][TYPE_MODE (type)];
   for (i = 0; i < nregs; i++)
-if (! call_used_regs[regno + i])
+if (! call_used_regs[regno + i] || fixed_regs[regno + i])
   return 1;
 
   return 0;

Re: avx512 mask register spilling

[Vladimir Makarov]

On 13-08-06 3:11 PM, Richard Henderson wrote:

On 08/06/2013 03:57 AM, Kirill Yukhin wrote:

On 05 Aug 09:55, Richard Henderson wrote:

On 08/05/2013 08:07 AM, Kirill Yukhin wrote:

Hello Richard, Vlad,

On 31 Jul 06:26, Richard Henderson wrote:

On 07/31/2013 05:02 AM, Kirill Yukhin wrote:

There's ICE (max. number of generated reload insns per insn is achieved (90)),
when LRA tried to save mask register before call. This was caused by fact that  
split_reg function
in lra-constraints.c allocates memory for saved reg in 
SECONDARY_MEMORY_NEEDED_MODE which

I've told you before that it's not SECONDARY_MEMORY that you want, but
a secondary reload.  You should be patching ix86_secondary_reload, right
below where we handle QImode spills from non-Q registers for x86-32.

Trying to do that with no success so far.
Could you pls correct me if I am wrong.
What I am trying to do is to introduce 2 new `define_expand' for load and store.

Huh?  You shouldn't need this.

Give me a test case and I can have a look at it.

Hello,

I've squashed part 1 and 2 + rebased on recent trunk.
Testcase is attached.
To reproduce: build-x86_64-linux/gcc/xgcc -Bbuild-x86_64-linux/gcc -Ofast 
-mavx512f -march=core-avx2 repro.c  -S -o-  -ffixed-rsi  -ffixed-rdi  
-ffixed-rbx -ffixed-rbp -m32

Thanks a lot for help!

You've found what I believe to be a bug in LRA.

Specifically, lra-constraints.c split_reg uses SECONDARY_MEMORY_NEEDED_MODE to
choose what mode to spill a caller-save register.  Given the existing
definition in i386.h, this tries to spill a MASK_CLASS register in SImode.  But
MASK_CLASS does not support SImode, only QI/HImode.  Which leads to substantial
confusion in the allocator trying to satisfy the move.

I believe the use of SECONDARY_MEMORY_NEEDED_MODE in split_reg is wrong.
What's the history behind that, Vlad?  Surely we can spill the value in
its current mode?


As I remember I tried to decrease number of macros used for LRA.

Just using mode of reg might not work for general case.

Reload (caller-saves.c) uses HARD_REGNO_CALLER_SAVE_MODE.   I guess we 
should use it.


I'll try to implement this and after some testing and checking on a few 
platform I'll commit it.


I guess we will have a solution at the end of this week.

Certainly this patch fixes the crash from Kirill's reproducer...


Thanks for working on this, Richard.

Re: [FIXED] Generic lambda symbol table bug

[Jason Merrill]

On 08/07/2013 03:52 AM, Adam Butcher wrote:

But a cleaner way might be to extend the "processing
template declaration" state from lambda declarator all the way to the end of the
lambda body.  This would match with the scenario that occurs with a standard
in-class member function template definition.  To do that elegantly would
require a bit of refactoring of the lambda parser code.


It isn't already set through the whole lambda body?  That seems 
necessary to support non-trivial lambda bodies; otherwise we won't be 
able to handle dependence properly.



I'm not sure which dialect guards to put these features behind though.
Strictly:

  a) Generic lambdas created fully implicitly via 'auto params' should be
 accepted with -std=c++1y and -std=gnu++1y since it is actually spec'd by
 the draft.

  b) Generic lambdas created with an explicit template parameter list should be
 accepted with -std=gnu++1y only.

  c) Generalized implicit function templates should be accepted by -std=gnu++1y
 only.


This makes sense to me.  Or perhaps add (c) to the concepts lite flag, 
when there is one.


Jason

Re: Request to merge Undefined Behavior Sanitizer in (take 2)

[Marek Polacek]

On Wed, Aug 07, 2013 at 10:24:59AM -0400, Jason Merrill wrote:
> On 08/07/2013 06:06 AM, Marek Polacek wrote:
> >I might've misunderstood what you mean.  If we drop the hunk above,
> >then we'll call
> > error ("%q+E is not a constant expression", t);
> >so, we'll print "is not a constant expression" no matter what
> 
> Yes, that's fine; 1/0 is not a constant expression, because it has
> undefined behavior.

Indeed.

> Print something more meaningful to the user.

Something along these lines?  (Not including CL/testcase yet on purpose.)
In beforementioned situation it'd print:

w.C:7:22: error: ‘’ is not a constant expression
   case 0 * (1 / 0):
  ^
I'm not entirely happy about it, on the other hand, this situation
should be very rare...

diff --git a/gcc/cp/error.c b/gcc/cp/error.c
index 440169a..db50b5f 100644
--- a/gcc/cp/error.c
+++ b/gcc/cp/error.c
@@ -32,6 +32,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "tree-pretty-print.h"
 #include "pointer-set.h"
 #include "c-family/c-objc.h"
+#include "ubsan.h"
 
 #define pp_separate_with_comma(PP) pp_cxx_separate_with (PP, ',')
 #define pp_separate_with_semicolon(PP) pp_cxx_separate_with (PP, ';')
@@ -1972,6 +1973,12 @@ dump_expr (tree t, int flags)
  }
skipfirst = true;
  }
+   if (flag_sanitize & SANITIZE_UNDEFINED
+   && is_ubsan_builtin_p (fn))
+ {
+   pp_string (cxx_pp, M_(""));
+   break;
+ }
dump_expr (fn, flags | TFF_EXPR_IN_PARENS);
dump_call_expr_args (t, flags, skipfirst);
   }
diff --git a/gcc/ubsan.c b/gcc/ubsan.c
index 8135cc9..565758d 100644
--- a/gcc/ubsan.c
+++ b/gcc/ubsan.c
@@ -456,3 +456,13 @@ ubsan_instrument_unreachable (location_t loc)
   tree t = builtin_decl_explicit (BUILT_IN_UBSAN_HANDLE_BUILTIN_UNREACHABLE);
   return build_call_expr_loc (loc, t, 1, build_fold_addr_expr_loc (loc, data));
 }
+
+/* Return true if T is a call to a libubsan routine.  */
+
+bool
+is_ubsan_builtin_p (tree t)
+{
+  gcc_checking_assert (TREE_CODE (t) == FUNCTION_DECL);
+  return strncmp (IDENTIFIER_POINTER (DECL_NAME (t)),
+ "__builtin___ubsan_", 18) == 0;
+}
diff --git a/gcc/ubsan.h b/gcc/ubsan.h
index abf4f5d..3553a6c 100644
--- a/gcc/ubsan.h
+++ b/gcc/ubsan.h
@@ -25,6 +25,7 @@ extern tree ubsan_instrument_unreachable (location_t);
 extern tree ubsan_create_data (const char *, location_t, ...);
 extern tree ubsan_type_descriptor (tree);
 extern tree ubsan_encode_value (tree);
+extern bool is_ubsan_builtin_p (tree);
 
 #endif  /* GCC_UBSAN_H  */
 
Marek

Re: New option to do fine grain control [on|off] of micro-arch specific features : -mtune-ctrl=....

[Xinliang David Li]

On Wed, Aug 7, 2013 at 8:37 AM, Jan Hubicka  wrote:
>> Ping?
>>
>> David
>>
>> On Sat, Aug 3, 2013 at 12:36 PM, Xinliang David Li  
>> wrote:
>> > Hi, GCC/i386 currently has about 73 boolean parameters/knobs (defined
>> > in ix86_tune_features[], indexed by ix86_tune_indices) to perform
>> > micro-arch specific performance tuning. However such settings are hard
>> > coded (fixed with a given -mtune setting) and is very hard to do
>> > performance experiment.
>> >
>> > The attached patch fixes the problem. The patch introduces a new
>> > option -mtune-ctrl=. Its parameter is a comma separated list of
>> > feature names to turn on associated features. Feature name can be
>> > prefixed by ^ to do the opposite. For instance,
>> >
>> >   -mtune-ctrl=prologue_using_move,epilogue_using_move,^pad_returns
>> >
>> > tells the compiler to use move instructions in prologue/epilogue
>> > (instead of push/pop), and *not* pad return instructions.
>> >
>> > To facilitate the change, the feature tuning enums defined in i386.h
>> > are moved to a new file x86-tune.def and this file can be used to
>> > generate both the enums and names of the features.
>> >
>> >
>> > Ok for trunk?
>
> Yes, this patch seems fine to me (as an undocumented option we should not
> be obliged to fix any ices from non-sential combinations of flags and in
> fact I do not really know of any).
> I wonder if we can't feed initial_ix86_tune_features so we get rid of
> two places that needs to be kept in sync when adding new knob?

Good concern -- the initial setting can be put into the def file too
to make sure they are always synced. I will do this in a follow up
patch.

thanks,

David


>
> Honza
>> >
>> >
>> > thanks,
>> >
>> > David
>> >
>> > 2013-08-03  Xinliang David Li  
>> >
>> > * config/i386/i386.opt: New option -mtune-ctrl=.
>> > * config/i386/x86-tune.def: New file.
>> > * config/i386/i386.h: include x86-tune.def.
>> > * config/i386/i386.c (ix86_option_override_internal):
>> > Parsing -mtune-ctrl= option and set tune features.

Re: Fix PR middle-end/57370

[Easwaran Raman]

Ping.

On Wed, Jul 31, 2013 at 4:34 PM, Easwaran Raman  wrote:
> I have a new patch that supersedes this. The new patch also fixes PR
> tree-optimization/57393 and PR tree-optimization/58011. Bootstraps and
> no test regression on x86_64/linux. Ok for trunk?
>
> 2013-07-31  Easwaran Raman  
>
> PR middle-end/57370
> * tree-ssa-reassoc.c (build_and_add_sum): Fix UID assignment and reset
> of debug statements that cause inconsistent IR.
>
>
> testsuite/ChangeLog:
> 2013-07-31  Easwaran Raman  
>
> PR middle-end/57370
> PR tree-optimization/57393
> PR tree-optimization/58011
> * gfortran.dg/reassoc_12.f90: New testcase.
> * gcc.dg/tree-ssa/reassoc-31.c: New testcase.
> * gcc.dg/tree-ssa/reassoc-31.c: New testcase.
>
>
> On Fri, Jul 12, 2013 at 7:57 AM, Easwaran Raman  wrote:
>> Ping.
>>
>> On Thu, Jun 27, 2013 at 10:15 AM, Easwaran Raman  wrote:
>>> A newly generated statement in build_and_add_sum  function of
>>> tree-ssa-reassoc.c has to be assigned the UID of its adjacent
>>> statement. In one instance, it was assigned the wrong uid (of an
>>> earlier phi statement) which messed up the IR and caused the test
>>> program to hang. Bootstraps and no test regressions on x86_64/linux.
>>> Ok for trunk?
>>>
>>> Thanks,
>>> Easwaran
>>>
>>>
>>> 2013-06-27  Easwaran Raman  
>>>
>>> PR middle-end/57370
>>> * tree-ssa-reassoc.c (build_and_add_sum): Do not use the UID of a 
>>> phi
>>> node for a non-phi gimple statement.
>>>
>>> testsuite/ChangeLog:
>>> 2013-06-27  Easwaran Raman  
>>>
>>> PR middle-end/57370
>>> * gfortran.dg/reassoc_12.f90: New testcase.
>>>
>>>
>>> Index: gcc/testsuite/gfortran.dg/reassoc_12.f90
>>> ===
>>> --- gcc/testsuite/gfortran.dg/reassoc_12.f90 (revision 0)
>>> +++ gcc/testsuite/gfortran.dg/reassoc_12.f90 (revision 0)
>>> @@ -0,0 +1,74 @@
>>> +! { dg-do compile }
>>> +! { dg-options "-O2 -ffast-math" }
>>> +! PR middle-end/57370
>>> +
>>> + SUBROUTINE xb88_lr_adiabatic_lda_calc(e_ndrho_ndrho_ndrho, &
>>> +   grad_deriv,npoints, sx)
>>> +IMPLICIT REAL*8 (t)
>>> +INTEGER, PARAMETER :: dp=8
>>> +REAL(kind=dp), DIMENSION(1:npoints) :: e_ndrho_ndrho_ndrho, &
>>> +   e_ndrho_ndrho_rho
>>> +  DO ii=1,npoints
>>> +  IF( grad_deriv >= 2 .OR. grad_deriv == -2 ) THEN
>>> +t1425 = t233 * t557
>>> +t1429 = beta * t225
>>> +t1622 = t327 * t1621
>>> +t1626 = t327 * t1625
>>> +t1632 = t327 * t1631
>>> +t1685 = t105 * t1684
>>> +t2057 = t1636 + t8 * (t2635 + t3288)
>>> +  END IF
>>> +  IF( grad_deriv >= 3 .OR. grad_deriv == -3 ) THEN
>>> +t5469 = t5440 - t5443 - t5446 - t5449 - &
>>> +t5451 - t5454 - t5456 + t5459  - &
>>> +t5462 + t5466 - t5468
>>> +t5478 = 0.240e2_dp * t1616 * t973 * t645 * t1425
>>> +t5489 = 0.16e2_dp * t1429 * t1658
>>> +t5531 = 0.160e2_dp * t112 * t1626
>>> +t5533 = 0.160e2_dp * t112 * t1632
>>> +t5537 = 0.160e2_dp * t112 * t1622
>>> +t5541 = t5472 - t5478 - t5523 + t5525 + &
>>> +t5531 + t5533 + t5535 + t5537 + &
>>> +t5540
>>> +t5565 = t112 * t1685
>>> +t5575 = t5545 - t5548 + t5551 + t5553 - &
>>> +t5558 + t5560 - t5562 + t5564 - &
>>> +0.80e1_dp * t5565 + t5568 + t5572 + &
>>> +t5574
>>> +t5611 = t5579 - t5585 + t5590 - t5595 + &
>>> +t5597 - t5602 + t5604 + t5607 + &
>>> +t5610
>>> +t5613 = t5469 + t5541 + t5575 + t5611
>>> +t6223 = t6189 - &
>>> +0.36e0_dp  * t83 * t84 * t5613 + &
>>> +t6222
>>> +t6227 = - t8 * (t5305 + t6223)
>>> +e_ndrho_ndrho_rho(ii) = e_ndrho_ndrho_rho(ii) + &
>>> + t6227 * sx
>>> +t6352 = t5440 - t5443 - t5446 - t5449 - &
>>> +t5451 - t5454 + &
>>> +0.40e1_dp * t102  * t327 * t2057 * t557 - &
>>> +t5456 + t5459 - t5462 + t5466 - &
>>> +t5468
>>> +t6363 = t5480 - t5489 + &
>>> +0.96e2_dp  * t1054 * t640 * t3679
>>> +t6367 = t5472 - t5474 - t5478 - t5523 + &
>>> +t5525 + t5531 + t5533 + t5535 + &
>>> +t5537 - 0.20e1_dp * t102 * t105 * t6363 + &
>>> +t5540
>>> +t6370 = t5545 - t5548 + t5551 + t5553 - &
>>> +t5558 + t5560 - t5562 + t5564  - &
>>> +0.40e1_dp * t5565 + &
>>> +t5568 + t5572 + t5574
>>> +t6373 = t5579 - t5585 + t5590

Re: [PATCH/Merge Request] Vtable Verification feature.

[Caroline Tice]

libvtv was supposed to be automatically disabled for darwin; we are in
the process of trying to figure out why this did not work as it was
supposed to.

In the meantime, if you add "--disable-libvtv" explicitly to your
configure command, that should turn off the attempts to
configure/build it.

I'll get another patch out to fix the problem as soon as I can.

-- Caroline Tice
 cmt...@google.com

On Wed, Aug 7, 2013 at 5:29 AM, Dominique Dhumieres  wrote:
> Revision 201555 breaks boostrap on x86_64-apple-darwin10:
>
> ...
> Checking multilib configuration for libvtv...
> make  all-recursive
> Making all in testsuite
> /bin/sh: line 0: cd: testsuite: No such file or directory
> make[4]: *** [all-recursive] Error 1
> make[3]: *** [all] Error 2
> make[2]: *** [all-stage1-target-libvtv] Error 2
> make[1]: *** [stage1-bubble] Error 2
> make: *** [all] Error 2
>
> According to
>
> * configure.ac: Add target-libvtv to target_libraries; disable libvtv
> on non-linux systems; add target-libvtv to noconfigdirs; add
> libsupc++/.libs to C++ library search paths.
>
> libvtv should not be built on darwin, but in config.log I see
>
> ...
> configure:3222: checking for libvtv support
> configure:3232: result: yes
> ...
>
> TIA
>
> Dominique

Re: New parameters to control stringop expansion libcall strategy

[Xinliang David Li]

Fixed the do while formatting.  Ok for trunk with this version?

thanks,

David

On Tue, Aug 6, 2013 at 2:42 AM, Jan Hubicka  wrote:
>> >>> 2013-08-02  Xinliang David Li  
>> >>>
>> >>> * config/i386/stringop.def: New file.
>> >>> * config/i386/stringop.opt: New file.
>> >>> * config/i386/i386-opts.h: Include stringopt.def.
>> >>> * config/i386/i386.opt: Include stringopt.opt.
>> >>> * config/i386/i386.c (ix86_option_override_internal):
>> >>> Override default size based stringop inline strategies
>> >>> with options.
>> >>> * config/i386/i386.c (ix86_parse_stringop_strategy_string):
>> >>> New function.
>> >>>
>> >>> 2013-08-04  Xinliang David Li  
>> >>>
>> >>> * testsuite/gcc.target/i386/memcpy-strategy-1.c: New test.
>> >>> * testsuite/gcc.target/i386/memcpy-strategy-2.c: Ditto.
>> >>> * testsuite/gcc.target/i386/memset-strategy-1.c: Ditto.
>> >>> * testsuite/gcc.target/i386/memcpy-strategy-3.c: Ditto.
>
> The patch looks resonable to me in general.  I wonder why we need to bring
> all the cost tables non-const instead of just having writable storage for
> the "current strategy" like we do with other flags anyway.
>
> Your strings are definitely more readable than the in-memory representation
> I came up with. Perhaps we can even turn the cost tables into strings
> for easier maintenance?  I guess they are bit confusing for people
> not familiar with a code.
>
> Honza
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> On Fri, Aug 2, 2013 at 9:21 PM, Xinliang David Li  
>> >>> wrote:
>> >>> > On x86_64, when the expected size of memcpy/memset is known (e.g, with
>> >>> > FDO), libcall strategy is used with the size is > 8192. This value is
>> >>> > hard coded, which makes it hard to do performance tuning. This patch
>> >>> > adds two new parameters to do that. Potential usage includes
>> >>> > per-application libcall strategy min-size tuning based on summary data
>> >>> > with FDO (e.g, instruction workset size).
>> >>> >
>> >>> > Bootstrap and tested on x86_64/linux. Ok for trunk?
>> >>> >
>> >>> > thanks,
>> >>> >
>> >>> > David
>> >>> >
>> >>> >
>> >>> > 2013-08-02  Xinliang David Li  
>> >>> >
>> >>> > * params.def: New parameters.
>> >>> > * config/i386/i386.c (ix86_option_override_internal):
>> >>> > Override default libcall size limit with parameters.
>> >>
>> >>> Index: config/i386/stringop.def
>> >>> ===
>> >>> --- config/i386/stringop.def  (revision 0)
>> >>> +++ config/i386/stringop.def  (revision 0)
>> >>> @@ -0,0 +1,42 @@
>> >>> +/* Definitions for option handling for IA-32.
>> >>> +   Copyright (C) 2013 Free Software Foundation, Inc.
>> >>> +
>> >>> +This file is part of GCC.
>> >>> +
>> >>> +GCC is free software; you can redistribute it and/or modify
>> >>> +it under the terms of the GNU General Public License as published by
>> >>> +the Free Software Foundation; either version 3, or (at your option)
>> >>> +any later version.
>> >>> +
>> >>> +GCC is distributed in the hope that it will be useful,
>> >>> +but WITHOUT ANY WARRANTY; without even the implied warranty of
>> >>> +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> >>> +GNU General Public License for more details.
>> >>> +
>> >>> +Under Section 7 of GPL version 3, you are granted additional
>> >>> +permissions described in the GCC Runtime Library Exception, version
>> >>> +3.1, as published by the Free Software Foundation.
>> >>> +
>> >>> +You should have received a copy of the GNU General Public License and
>> >>> +a copy of the GCC Runtime Library Exception along with this program;
>> >>> +see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
>> >>> +.  */
>> >>> +
>> >>> +DEF_ENUM
>> >>> +DEF_ALG (no_stringop, no_stringop)
>> >>> +DEF_ENUM
>> >>> +DEF_ALG (libcall, libcall)
>> >>> +DEF_ENUM
>> >>> +DEF_ALG (rep_prefix_1_byte, rep_byte)
>> >>> +DEF_ENUM
>> >>> +DEF_ALG (rep_prefix_4_byte, rep_4byte)
>> >>> +DEF_ENUM
>> >>> +DEF_ALG (rep_prefix_8_byte, rep_8byte)
>> >>> +DEF_ENUM
>> >>> +DEF_ALG (loop_1_byte, byte_loop)
>> >>> +DEF_ENUM
>> >>> +DEF_ALG (loop, loop)
>> >>> +DEF_ENUM
>> >>> +DEF_ALG (unrolled_loop, unrolled_loop)
>> >>> +DEF_ENUM
>> >>> +DEF_ALG (vector_loop, vector_loop)
>> >>> Index: config/i386/i386.opt
>> >>> ===
>> >>> --- config/i386/i386.opt  (revision 201458)
>> >>> +++ config/i386/i386.opt  (working copy)
>> >>> @@ -316,6 +316,14 @@ mstack-arg-probe
>> >>>  Target Report Mask(STACK_PROBE) Save
>> >>>  Enable stack probing
>> >>>
>> >>> +mmemcpy-strategy=
>> >>> +Target RejectNegative Joined Var(ix86_tune_memcpy_strategy)
>> >>> +Specify memcpy expansion strategy when expected size is known
>> >>> +
>> >>> +mmemset-strategy=
>> >>> +Target RejectNegative Joined Var(ix86_tune_memset_strategy)
>> >>> +Spe

Re: i686 pic & DCmode

[Eric Botcazou]

> The usual x86 ports avoid this, because their must_return_in_mem hooks DTRT
> already and we never fall into the default case.

So why not do the same for i686-elf?

> I am very surprised this hasn't bitten someone before -- I presume this
> never worked with i686-elf.  It is possible this'll change some other ABI
> where a fixed reg was permitted to be used in the manner that this now
> prohibits, but I have a hard time thinking that happens.  Shout if you
> know of one.

IMO that's not sufficient, you ought to go through all the back-ends and check 
that you aren't breaking anything with such a bold change.  This code is more 
than 2 decades old and can affect every single port in a major way.

-- 
Eric Botcazou

[PATCH] Add vtable verification feature announcement to news on main page...

[Caroline Tice]

As requested, here is the patch to announce the vtable verification
feature on the main gcc.gnu.org web page.  Is this ok to commit?

-- Caroline Tice
cmt...@google.com


wwwdocs.patch
Description: Binary data

Re: [PATCH/Merge Request] Vtable Verification feature.

[Iain Sandoe]

hi Caroline, 

A (very) quick look suggests that only *) results in a return of UNSUPPORTED 
from libvtv/configure.tgt

Do you know if anyone is working on a Darwin port for this lib?

thanks,
Iain

On 7 Aug 2013, at 17:57, Caroline Tice wrote:

> libvtv was supposed to be automatically disabled for darwin; we are in
> the process of trying to figure out why this did not work as it was
> supposed to.
> 
> In the meantime, if you add "--disable-libvtv" explicitly to your
> configure command, that should turn off the attempts to
> configure/build it.
> 
> I'll get another patch out to fix the problem as soon as I can.
> 
> -- Caroline Tice
> cmt...@google.com
> 
> On Wed, Aug 7, 2013 at 5:29 AM, Dominique Dhumieres  
> wrote:
>> Revision 201555 breaks boostrap on x86_64-apple-darwin10:
>> 
>> ...
>> Checking multilib configuration for libvtv...
>> make  all-recursive
>> Making all in testsuite
>> /bin/sh: line 0: cd: testsuite: No such file or directory
>> make[4]: *** [all-recursive] Error 1
>> make[3]: *** [all] Error 2
>> make[2]: *** [all-stage1-target-libvtv] Error 2
>> make[1]: *** [stage1-bubble] Error 2
>> make: *** [all] Error 2
>> 
>> According to
>> 
>>* configure.ac: Add target-libvtv to target_libraries; disable libvtv
>>on non-linux systems; add target-libvtv to noconfigdirs; add
>>libsupc++/.libs to C++ library search paths.
>> 
>> libvtv should not be built on darwin, but in config.log I see
>> 
>> ...
>> configure:3222: checking for libvtv support
>> configure:3232: result: yes
>> ...
>> 
>> TIA
>> 
>> Dominique

Re: small patch to accept = inside plugin arguments

[David Malcolm]

On Wed, 2013-08-07 at 19:15 +0200, Basile Starynkevitch wrote:
> Hello All,
> 
> It should be perfectly possible for a plugin argument to contain the
> equal sign.
> 
> For plugin with scripting or DSL behavior (like MELT, see
> http://gcc-melt.org/ for more) it is useful to pass some commands 
> or expressions to the plugin. For MELT we might want to run
>  
>  gcc -fplugin=melt -fplugin-arg-melt-mode=eval \
>  -fplugin-arg-melt-arg='(== 1 2)' empty.c
> 
> for plugins accepting some shell command to be run by system or popen, 
> passing -fplugin-arg-foo-command='env FOO=bar doit arg' would be
> perfectly ok, but is not.

Thanks - fwiw I've also run into this issue a few times with the python
plugin.

(I'm not a reviewer)

small patch to accept = inside plugin arguments

[Basile Starynkevitch]

Hello All,

It should be perfectly possible for a plugin argument to contain the
equal sign.

For plugin with scripting or DSL behavior (like MELT, see
http://gcc-melt.org/ for more) it is useful to pass some commands 
or expressions to the plugin. For MELT we might want to run
 
 gcc -fplugin=melt -fplugin-arg-melt-mode=eval \
 -fplugin-arg-melt-arg='(== 1 2)' empty.c

for plugins accepting some shell command to be run by system or popen, 
passing -fplugin-arg-foo-command='env FOO=bar doit arg' would be
perfectly ok, but is not.

The small attached patch relative to trunk 201571 should solve the
issue.

# gcc/ChangeLog entry
2013-08-07  Basile Starynkevitch  

* plugin.c (parse_plugin_arg_opt): Accept equal sign inside 
  plugin argument.


Comments are welcome. Ok for trunk?

Cheers

-- 
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

Index: gcc/plugin.c
===
--- gcc/plugin.c	(revision 201571)
+++ gcc/plugin.c	(working copy)
@@ -241,16 +241,13 @@ parse_plugin_arg_opt (const char *arg)
 }
   else if (*ptr == '=')
 {
-  if (key_parsed)
-{
-  error ("malformed option -fplugin-arg-%s (multiple '=' signs)",
-		 arg);
-  return;
-}
-  key_len = len;
-  len = 0;
-  value_start = ptr + 1;
-  key_parsed = true;
+	  if (!key_parsed) 
+	{
+	  key_len = len;
+	  len = 0;
+	  value_start = ptr + 1;
+	  key_parsed = true;
+	}
   continue;
 }
   else

Re: i686 pic & DCmode

[Nathan Sidwell]

Having poked further, I find this in the testsuite:

pr11001-strlen-2.c
--begin
register int regvar asm("%eax");

char *
do_copy (char *str)
{
  return malloc (strlen (str) + 1);
}
--end

Is that even meaningful?  The doc's for a global reg var say:
'Choose a register that is normally saved and restored by function calls on your
machine, so that library routines will not clobber it.'

If one never made calls to a library unaware of the reg's global use, things 
would be ok.  Except if one chose a register that is used by the ABI to return 
things, or by the pro/epilogue code as a scratch register.


Should attempts to use a call_used reg as a global reg var generate an error? 
Should it stop it being marked as a fixed_reg?


nathan

Re: [PATCH/Merge Request] Vtable Verification feature.

[Caroline Tice]

Hi Iain,

Thanks for the pointer (I had noticed this but I appreciate the help!).

I do not know of anyone working on a Darwin port for this  at this time.

-- Caroline Tice
cmt...@google.com

On Wed, Aug 7, 2013 at 10:31 AM, Iain Sandoe  wrote:
> hi Caroline,
>
> A (very) quick look suggests that only *) results in a return of UNSUPPORTED 
> from libvtv/configure.tgt
>
> Do you know if anyone is working on a Darwin port for this lib?
>
> thanks,
> Iain
>
> On 7 Aug 2013, at 17:57, Caroline Tice wrote:
>
>> libvtv was supposed to be automatically disabled for darwin; we are in
>> the process of trying to figure out why this did not work as it was
>> supposed to.
>>
>> In the meantime, if you add "--disable-libvtv" explicitly to your
>> configure command, that should turn off the attempts to
>> configure/build it.
>>
>> I'll get another patch out to fix the problem as soon as I can.
>>
>> -- Caroline Tice
>> cmt...@google.com
>>
>> On Wed, Aug 7, 2013 at 5:29 AM, Dominique Dhumieres  
>> wrote:
>>> Revision 201555 breaks boostrap on x86_64-apple-darwin10:
>>>
>>> ...
>>> Checking multilib configuration for libvtv...
>>> make  all-recursive
>>> Making all in testsuite
>>> /bin/sh: line 0: cd: testsuite: No such file or directory
>>> make[4]: *** [all-recursive] Error 1
>>> make[3]: *** [all] Error 2
>>> make[2]: *** [all-stage1-target-libvtv] Error 2
>>> make[1]: *** [stage1-bubble] Error 2
>>> make: *** [all] Error 2
>>>
>>> According to
>>>
>>>* configure.ac: Add target-libvtv to target_libraries; disable libvtv
>>>on non-linux systems; add target-libvtv to noconfigdirs; add
>>>libsupc++/.libs to C++ library search paths.
>>>
>>> libvtv should not be built on darwin, but in config.log I see
>>>
>>> ...
>>> configure:3222: checking for libvtv support
>>> configure:3232: result: yes
>>> ...
>>>
>>> TIA
>>>
>>> Dominique
>

Re: [GOOGLE] Refactor AutoFDO

[Xinliang David Li]

ok for google branch.

David

On Tue, Aug 6, 2013 at 3:41 PM, Dehao Chen  wrote:
> Patch updated.
>
> http://codereview.appspot.com/12079043
>
> Thanks,
> Dehao
>
>
> On Fri, Aug 2, 2013 at 11:21 AM, Xinliang David Li  wrote:
>> More to follow.
>>
>> David
>>
static void
 read_profile (void)
 {
   if (gcov_open (auto_profile_file, 1) == 0)
 {
   inform (0, "Cannot open profile file %s.", auto_profile_file);
>>
>>
>>  Should be at least warning instead -- I think error is probably more
>> appropriate -- this is different from regular FDO, where one missing
>> gcda might be ok.
>>
   flag_auto_profile = 0;
   return;
 }

   if (gcov_read_unsigned () != GCOV_DATA_MAGIC)
 {
   inform (0, "Magic number does not mathch.");
>>
>> Should be an error.
>>
   flag_auto_profile = 0;
   return;
 }


   /* function_name_map.  */
   afdo_function_name_map = function_name_map::create ();
   if (afdo_function_name_map == NULL)
 {
   inform (0, "Cannot read string table.");
>>
>> Should be an error unless there is a way to recover. Falling back to
>> non-fdo is not the solution.
>>
   flag_auto_profile = 0;
   return;
 }

   /* autofdo_source_profile.  */
   afdo_source_profile = autofdo_source_profile::create ();
   if (afdo_source_profile == NULL)
 {
   inform (0, "Cannot read function profile.");
>>
>> An error.
>>
   flag_auto_profile = 0;
   return;
 }

   /* autofdo_module_profile.  */
   afdo_module_profile = autofdo_module_profile::create ();
   if (afdo_module_profile == NULL)
 {
   inform (0, "Cannot read module profile.");
>>
>> Should be an error.
>>
   flag_auto_profile = 0;
   return;
 }

   /* Read in the working set.  */
   if (gcov_read_unsigned () != GCOV_TAG_AFDO_WORKING_SET)
 {
   inform (0, "Not expected TAG.");
>>
>> Error.
>>
   unsigned curr_module = 1, max_group = PARAM_VALUE (PARAM_MAX_LIPO_GROUP);
   for (string_vector::const_iterator iter = aux_modules->begin();
iter != aux_modules->end(); ++iter)
 {
   gcov_module_info *aux_module = afdo_module_profile->get_module 
 (*iter);
   if (aux_module == module)
 continue;
   if (aux_module == NULL)
 {
  inform (0, "aux module %s cannot be found.", *iter);
  continue;
 }
   if ((aux_module->lang & GCOV_MODULE_LANG_MASK) !=
  (module->lang & GCOV_MODULE_LANG_MASK))
 {
  inform (0, "Not importing %s: source language"
  " different from primary module's source language", *iter);
>>
>>
>> Should be guarded with -fopt-info -- see similar code in coverage.c.
>>
  continue;
 }
   if ((aux_module->lang & GCOV_MODULE_ASM_STMTS)
   && flag_ripa_disallow_asm_modules)
 {
  if (flag_opt_info)
inform (0, "Not importing %s: contains "
"assembler statements", *iter);
>>
>> Use -fopt-info
>>
  continue;
 }
   if (max_group != 0 && curr_module == max_group)
 {
  if (flag_opt_info)
inform (0, "Not importing %s: maximum group size reached", *iter);
 }
   if (incompatible_cl_args (module, aux_module))
 {
  if (flag_opt_info)
inform (0, "Not importing %s: command-line"
" arguments not compatible with primary module", *iter);
  continue;
>>
>> Use -fopt-info.
>>
>>
 }
   module_infos[curr_module++] = aux_module;
   add_input_filename (*iter);
 }
 }

 /* From AutoFDO profiles, find values inside STMT for that we want to 
 measure
histograms for indirect-call optimization.  */

 {
   hist->hvalue.counters[3] = 0;
   hist->hvalue.counters[4] = 0;
 }
>>
>> It might be better to create a commmon API to create/update histogram
>> entry instead of peeking into the details of the data structure -- to
>> avoid future breaks. Such a change can be done as a follow up and
>> needs to be in trunk.
>
> Will update this in a follow-up patch.
>
>>
 }

 /* From AutoFDO profiles, find values inside STMT for that we want to 
 measure
histograms and adds them to list VALUES.  */

 static void
 afdo_vpt (gimple stmt, const icall_target_map &map)
 {
   afdo_indirect_call (stmt, map);
 }

 /* For a given BB, return its execution count, and annotate value profile
on statements.  */

 static gcov_type
 afdo_get_bb_count (basic_block bb)
 {
   gimple_stmt_iterator gsi;
   gcov_type max_count = 0;
   bool has_annotated = false;

   for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (&gsi))
 {
   count_info info;
   gimple stmt = gsi_stmt (gsi);
   if (afdo_source_profile-

Re: PATCH: PR debug/54568: --eh-frame-hdr should also be enabled for static executable

[H.J. Lu]

On Thu, Sep 13, 2012 at 7:46 PM, H.J. Lu  wrote:
> Hi,
>
> There is no reason why --eh-frame-hdr can't be used with static
> executable on Linux.  This patch enables --eh-frame-hdr for static
> executable on Linux and adds an exception test for static executable.
> Other platforms may also work correctly.  But I can't verify it.
>

It looks like we don't want to use  --eh-frame-hdr for -static for
backward compatibility.  Here is a patch to only use it for Android
where we have no compatibility issue.  OK to install?

Thanks.

H.J.
---
2013-08-07  H.J. Lu  

PR debug/54568
* config/gnu-user.h (LINK_EH_SPEC): Renamed to ...
(GNU_USER_TARGET_LINK_EH_SPEC): This.
(LINK_EH_SPEC): Defined as GNU_USER_TARGET_LINK_EH_SPEC.
* config/linux-android.h (ANDROID_LINK_EH_SPEC): New.
* config/i386/linux-common.h (LINK_EH_SPEC): Likewise.

diff --git a/gcc/config/gnu-user.h b/gcc/config/gnu-user.h
index 2c48c18..39e5608 100644
--- a/gcc/config/gnu-user.h
+++ b/gcc/config/gnu-user.h
@@ -90,7 +90,8 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If n
ot, see
 #define LIB_SPEC GNU_USER_TARGET_LIB_SPEC

 #if defined(HAVE_LD_EH_FRAME_HDR)
-#define LINK_EH_SPEC "%{!static:--eh-frame-hdr} "
+#define GNU_USER_TARGET_LINK_EH_SPEC "%{!static:--eh-frame-hdr} "
+#define LINK_EH_SPEC GNU_USER_TARGET_LINK_EH_SPEC
 #endif

 #undef LINK_GCC_C_SEQUENCE_SPEC
diff --git a/gcc/config/i386/linux-common.h b/gcc/config/i386/linux-common.h
index 1e8bf6b..157bf022 100644
--- a/gcc/config/i386/linux-common.h
+++ b/gcc/config/i386/linux-common.h
@@ -37,6 +37,13 @@ along with GCC; see the file COPYING3.  If not see
   LINUX_OR_ANDROID_LD (GNU_USER_TARGET_LINK_SPEC, \
GNU_USER_TARGET_LINK_SPEC " " ANDROID_LINK_SPEC)

+#ifdef GNU_USER_TARGET_LINK_EH_SPEC
+#undefLINK_EH_SPEC
+#define LINK_EH_SPEC \
+  LINUX_OR_ANDROID_LD (GNU_USER_TARGET_LINK_EH_SPEC, \
+   ANDROID_LINK_EH_SPEC) " "
+#endif
+
 #undef  LIB_SPEC
 #define LIB_SPEC \
   LINUX_OR_ANDROID_LD (GNU_USER_TARGET_LIB_SPEC, \
diff --git a/gcc/config/linux-android.h b/gcc/config/linux-android.h
index 831a19c..6c172ab 100644
--- a/gcc/config/linux-android.h
+++ b/gcc/config/linux-android.h
@@ -40,6 +40,9 @@
 #define ANDROID_LINK_SPEC \
   "%{shared: -Bsymbolic}"

+#define ANDROID_LINK_EH_SPEC \
+  "--eh-frame-hdr "
+
 #define ANDROID_CC1_SPEC\
   "%{!mglibc:%{!muclibc:%{!mbionic: -mbionic}}} "\
   "%{!fno-pic:%{!fno-PIC:%{!fpic:%{!fPIC: -fPIC"

[patch][google] Update libtool.m4 in google/gcc-4_8 branch.

[Brooks Moses]

A not-yet-reviewed libtool patch is needed for powerpc64le
shared-library support:
http://lists.gnu.org/archive/html/libtool-patches/2013-06/msg1.html
(See also 
http://lists.gnu.org/archive/html/libtool-patches/2013-07/msg1.html)

This patch merges that change into the google/gcc-4_8 branch and
regenerates the configure files.

Committed after off-list review by Diego.

- Brooks


Update to support powerpc*le:
* libtool.m4
* libgo/config/libtool.m4

Regenerate:
* boehm-gc/configure
* gcc/configure
* libatomic/configure
* libbacktrace/configure
* libffi/configure
* libgfortran/configure
* libgo/configure
* libgomp/configure
* libitm/configure
* libjava/classpath/configure
* libjava/configure
* libjava/libltdl/acinclude.m4
* libjava/libltdl/configure
* libmudflap/configure
* libobjc/configure
* libquadmath/configure
* libsanitizer/configure
* libssp/configure
* libstdc++-v3/configure
* lto-plugin/configure
* zlib/configure


2013-08-06_libtool-update.diff
Description: Binary data

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

[Andrew Pinski]

On Wed, Aug 7, 2013 at 11:31 AM, Paul Pluzhnikov  wrote:
> On Wed, Aug 7, 2013 at 11:09 AM, Jan Kratochvil
>  wrote:
>
>> there should be a new case in:
>> libiberty/testsuite/demangle-expected
>
> Thanks. I updated the patch.
> --
> Paul Pluzhnikov


I think this should also be send to the GCC List as libiberty is
officially maintained by GCC.

Thanks,
Andrew

>
>
> 2013-08-07  Paul Pluzhnikov  
>
> * cp-demangle.c (d_name): Handle internal-linkage templates.
> * testsuite/demangle-expected: New case.

Re: i686 pic & DCmode

[Ian Lance Taylor]

On Wed, Aug 7, 2013 at 10:34 AM, Nathan Sidwell  wrote:
> Having poked further, I find this in the testsuite:
>
> pr11001-strlen-2.c
> --begin
> register int regvar asm("%eax");
>
> char *
> do_copy (char *str)
> {
>   return malloc (strlen (str) + 1);
> }
> --end
>
> Is that even meaningful?  The doc's for a global reg var say:
> 'Choose a register that is normally saved and restored by function calls on
> your
> machine, so that library routines will not clobber it.'

This is risky but meaningful, and potentially useful with asm
instructions.

> If one never made calls to a library unaware of the reg's global use, things
> would be ok.  Except if one chose a register that is used by the ABI to
> return things, or by the pro/epilogue code as a scratch register.
>
> Should attempts to use a call_used reg as a global reg var generate an
> error?

No.  Perhaps a warning.

> Should it stop it being marked as a fixed_reg?

Definitely not.

Ian

[patch] Make cxxfilt demangle internal-linkage templates

[Paul Pluzhnikov]

Greetings,

I've been redirected here from binutils:
http://sourceware.org/ml/binutils/2013-08/msg00052.html
http://sourceware.org/ml/binutils/2013-08/msg00056.html

The following source:

  template static void f();
  void g() { f(); }

results in "_Z1fIiEvv" under g++, but in "_ZL1fIiEvv" under clang.

Richard Smith says:

  The ABI doesn't cover manglings for local symbols ...
  ... and c++filt is not able to cope with the L prefix here.

  I'm having a hard time seeing how this isn't a g++ bug and a matching
  c++filt bug.

It's hard for me to argue that this is a 'g++' bug (since there is no
ABI violation here), but c++filt should be able to handle this, and does
with attached patch.

Ok for trunk?

Thanks,

Google ref: b/10137049
---
Paul Pluzhnikov


2013-08-07  Paul Pluzhnikov  

* cp-demangle.c (d_name): Handle internal-linkage templates.
* testsuite/demangle-expected: New case.


Index: libiberty/testsuite/demangle-expected
===
--- libiberty/testsuite/demangle-expected   (revision 201577)
+++ libiberty/testsuite/demangle-expected   (working copy)
@@ -4291,3 +4291,6 @@
 --format=gnu-v3
 _Z1nIM1AKFvvREEvT_
 void n(void (A::*)() const &)
+--format=gnu-v3
+_ZL1fIiEvv
+void f()
Index: libiberty/cp-demangle.c
===
--- libiberty/cp-demangle.c (revision 201577)
+++ libiberty/cp-demangle.c (working copy)
@@ -1276,7 +1276,6 @@
 case 'Z':
   return d_local_name (di);
 
-case 'L':
 case 'U':
   return d_unqualified_name (di);
 
@@ -1323,6 +1322,7 @@
return dc;
   }
 
+case 'L':
 default:
   dc = d_unqualified_name (di);
   if (d_peek_char (di) == 'I')

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

[Paul Pluzhnikov]

On Wed, Aug 7, 2013 at 11:34 AM, Andrew Pinski  wrote:

> I think this should also be send to the GCC List as libiberty is
> officially maintained by GCC.

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

Thanks,
-- 
Paul Pluzhnikov

Go patch committed: Fix missing return error for type switches

[Ian Lance Taylor]

The Go frontend gave an incorrect "missing return" error message for a
type switch with a case with multiple types, as in "case T1, T2:".  This
patch fixes that problem.  This patch also changes the "missing return"
error message to use the same text as the gc compiler, and reports it at
the end of the function rather than the start of the function, again to
match the gc compiler.  Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu.  Committed to mainline and 4.8 branch.

Ian

Index: gcc/go/gofrontend/gogo.cc
===
--- gcc/go/gofrontend/gogo.cc	(revision 201536)
+++ gcc/go/gofrontend/gogo.cc	(working copy)
@@ -3133,7 +3133,8 @@ Check_return_statements_traverse::functi
 return TRAVERSE_CONTINUE;
 
   if (func->block()->may_fall_through())
-error_at(func->location(), "control reaches end of non-void function");
+error_at(func->block()->end_location(),
+	 "missing return at end of function");
 
   return TRAVERSE_CONTINUE;
 }
Index: gcc/go/gofrontend/statements.cc
===
--- gcc/go/gofrontend/statements.cc	(revision 201536)
+++ gcc/go/gofrontend/statements.cc	(working copy)
@@ -4093,6 +4093,16 @@ Type_case_clauses::Type_case_clause::low
 bool
 Type_case_clauses::Type_case_clause::may_fall_through() const
 {
+  if (this->is_fallthrough_)
+{
+  // This case means that we automatically fall through to the
+  // next case (it's used for T1 in case T1, T2:).  It does not
+  // mean that we fall through to the end of the type switch as a
+  // whole.  There is sure to be a next case and that next case
+  // will determine whether we fall through to the statements
+  // after the type switch.
+  return false;
+}
   if (this->statements_ == NULL)
 return true;
   return this->statements_->may_fall_through();
Index: gcc/testsuite/go.test/test/fixedbugs/bug086.go
===
--- gcc/testsuite/go.test/test/fixedbugs/bug086.go	(revision 200210)
+++ gcc/testsuite/go.test/test/fixedbugs/bug086.go	(working copy)
@@ -6,12 +6,12 @@
 
 package main
 
-func f() int {	// ERROR "return|control"
+func f() int {
 	if false {
 		return 0;
 	}
 	// we should not be able to return successfully w/o a return statement
-}
+} // ERROR "return"
 
 func main() {
 	print(f(), "\n");

Re: [PATCH] Fix illegal cast to rtx (*insn_gen_fn) (rtx, ...)

[Michael Meissner]

On Tue, Aug 06, 2013 at 11:45:40PM +0200, Oleg Endo wrote:
> On Mon, 2013-08-05 at 13:25 -1000, Richard Henderson wrote:
> > On 08/05/2013 12:32 PM, Oleg Endo wrote:
> > > Thanks, committed as rev 201513.
> > > 4.8 also has the same problem.  The patch applies on 4.8 branch without
> > > problems and make all-gcc works.
> > > OK for 4.8, too?
> > 
> > Hum.  I suppose so, since it's relatively self-contained.  I suppose the
> > out-of-tree openrisc port will thank us...
> 
> Maybe it's better to wait for a while and collect follow up patches such
> as the rs6000 one.

The tree right now is broken for the powerpc.  I would prefer to get patches
installed ASAP rather than waiting for additional ports.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797

[C++ Patch / RFC] PR 54864

[Paolo Carlini]

Hi,

the issue here is that... I'm not sure the bug report is valid ;) 
Seriously, *if* we think it is, must be fixable with a moderate effort. 
Here Jason fixed the closely related c++/53721:


http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01445.html

and tweaking a bit more the check would allow this variant too, with 
outer pointing to the enclosing S:


struct S
{
int foo();

struct nested
{
S* outer;

auto bar() -> decltype(outer->foo());
};
};


but I'm not sure it's valid code: for example clang accepts it, icc 
doesn't. If it is, something along the lines of the attached (with at 
least an improved comment: we want to say something like pointer to this 
*or* to enclosing class) works for the testcase (and a few positive and 
negative variants) and lightly tested on x86_64-linux.


Thanks!
Paolo.

/



Index: parser.c
===
--- parser.c(revision 201558)
+++ parser.c(working copy)
@@ -6294,8 +6294,10 @@ cp_parser_postfix_dot_deref_expression (cp_parser
   /* Unlike the object expression in other contexts, *this is not
 required to be of complete type for purposes of class member
 access (5.2.5) outside the member function body.  */
-  else if (postfix_expression != current_class_ref
-  && !(processing_template_decl && scope == current_class_type))
+  else if (!(processing_template_decl && scope == current_class_type)
+  && (!current_class_type || !CLASS_TYPE_P (scope)
+  || (common_enclosing_class (scope, current_class_type)
+  != scope)))
scope = complete_type_or_else (scope, NULL_TREE);
   /* Let the name lookup machinery know that we are processing a
 class member access expression.  */

Re: [PATCH] Fix illegal cast to rtx (*insn_gen_fn) (rtx, ...)

[Oleg Endo]

On Wed, 2013-08-07 at 15:08 -0400, Michael Meissner wrote:
> On Tue, Aug 06, 2013 at 11:45:40PM +0200, Oleg Endo wrote:
> > On Mon, 2013-08-05 at 13:25 -1000, Richard Henderson wrote:
> > > On 08/05/2013 12:32 PM, Oleg Endo wrote:
> > > > Thanks, committed as rev 201513.
> > > > 4.8 also has the same problem.  The patch applies on 4.8 branch without
> > > > problems and make all-gcc works.
> > > > OK for 4.8, too?
> > > 
> > > Hum.  I suppose so, since it's relatively self-contained.  I suppose the
> > > out-of-tree openrisc port will thank us...
> > 
> > Maybe it's better to wait for a while and collect follow up patches such
> > as the rs6000 one.
> 
> The tree right now is broken for the powerpc.  I would prefer to get patches
> installed ASAP rather than waiting for additional ports.

I've just committed the PPC fix for trunk.  Sorry for the delay.
I haven't committed anything related to this issue on the 4.8 branch
yet.  I'll do that next week if nothing else comes up.

Cheers,
Oleg

Re: PPC64 HTM support (was [buildbot] r201513: Invalid cast)

[Oleg Endo]

On Tue, 2013-08-06 at 22:01 -0500, Peter Bergner wrote:
> Oleg Endo wrote:
> > Speaking of GEN_FCN usage in rs6000.c.  The recently added HTM builtin
> > code has one interesting piece:
> > 
> > static rtx
> > htm_expand_builtin (tree exp, rtx target, bool * expandedp)
> > {
> > ...
> > switch (nopnds)
> >  {
> >  case 0:
> >pat = GEN_FCN (icode) (NULL_RTX);
> >break;
> >  case 1:
> >pat = GEN_FCN (icode) (op[0]);
> >break;
> > 
> > The 'case 0' looks suspicious.
> 
> Yes, the "case 0:" is not needed.  It was needed at one point
> when I originally modeled this code after Andreas's s390 changes.
> The code then passed in the target rtx as a separate parameter
> from the operands, so nopnds was actually zero in some cases.
> I realized I could simplify the code a lot by placing the
> target rtx into the op[] array along with the source operands
> and at that point, the "case 0:" statements became dead code
> as you discovered.  I'll bootstrap and regtest the change
> below and commit it as an obvious fix when that is done.
> 
> Thanks for spotting this.

No problem.  Thanks for the explanation.
BTW please don't forget to add documentation of the builtins.
Being a non-PPC person, I had to dig and hack in the backend to get the
HTM builtins to work for the test.  I think the binutils version that I
used (2.23.1) is too old or something.  Even though I specified the
"-mhtm" option it would complain about that I need to specify the
"-mhtm" option to use the builtins...

Cheers,
Oleg

Re: [C++ Patch / RFC] PR 54864

[Jason Merrill]

On 08/07/2013 03:17 PM, Paolo Carlini wrote:

the issue here is that... I'm not sure the bug report is valid ;)
Seriously, *if* we think it is, must be fixable with a moderate effort.
Here Jason fixed the closely related c++/53721:

 http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01445.html

and tweaking a bit more the check would allow this variant too, with
outer pointing to the enclosing S:

struct S
{
 int foo();

 struct nested
 {
 S* outer;

 auto bar() -> decltype(outer->foo());
 };
};


but I'm not sure it's valid code: for example clang accepts it, icc
doesn't.


The rule that allows use of *this is pretty specific:

Unlike the object expression in other contexts, *this is not required to 
be of complete type for purposes of class member access (5.2.5) outside 
the member function body.


That doesn't seem to allow the use of *outer.

Jason

Re: [FIXED] Generic lambda symbol table bug

[Adam Butcher]

On 07.08.2013 16:59, Jason Merrill wrote:

On 08/07/2013 03:52 AM, Adam Butcher wrote:

But a cleaner way might be to extend the "processing
template declaration" state from lambda declarator all the way to 
the end of the
lambda body.  This would match with the scenario that occurs with a 
standard
in-class member function template definition.  To do that elegantly 
would

require a bit of refactoring of the lambda parser code.


It isn't already set through the whole lambda body?


No.  It is within cp_parser_lambda_declarator_opt.


That seems
necessary to support non-trivial lambda bodies; otherwise we won't be
able to handle dependence properly.


Agreed.  Okay, I will produce three patches:

  1) Refactor existing monomorphic implementation to give a cleaner
 parser separation of concerns; extract the fco creation and
 provide begin and end for the lambda function operator.

  2) Add explicit lambda template support.

  3) Add implicit function template support.

I'm not sure which dialect guards to put these features behind 
though.

Strictly:

  a) Generic lambdas created fully implicitly via 'auto params' 
should be
 accepted with -std=c++1y and -std=gnu++1y since it is actually 
spec'd by

 the draft.

  b) Generic lambdas created with an explicit template parameter 
list should be

 accepted with -std=gnu++1y only.

  c) Generalized implicit function templates should be accepted by 
-std=gnu++1y

 only.


This makes sense to me.  Or perhaps add (c) to the concepts lite
flag, when there is one.


Okay.  Will do as originally suggested.  I am intending to try out
constrained implicit function templates on the c++-concepts branch
at some point also (which might already have such a flag).

Cheers,
Adam

Re: [PATCH i386 2/8] [AVX512] Add mask registers.

[Kirill Yukhin]

Hello!
 
> You can't read from memory into a mask register in QImode.
> This will fail if the memory was the last byte of a page,
> and the following page is not mapped.
> 
> I expected you to need the following patch, to help spill
> and fill QImode values, but I havn't found a test case that
> actually needs it.  Perhaps LRA is better than old reload
> about guessing things like this?

Thanks a lot for inputs and patch. We fixed them and applied your changes.

Updated patch is attached. Testcase I provided is working
when your patch to LRA is applied.

It is applicable on top of [1/8] (which was rebased on new trunk today).

Testing:
 - It passes bootstrap.
 - It introduces no regressions.
 - Spec2006 build pass both with and wothout -mavx512f.

Is it ok?

---
 gcc/config/i386/constraints.md |   8 +-
 gcc/config/i386/i386.c |  32 +--
 gcc/config/i386/i386.h |  38 ++--
 gcc/config/i386/i386.md| 204 +
 4 files changed, 245 insertions(+), 37 deletions(-)

diff --git a/gcc/config/i386/constraints.md b/gcc/config/i386/constraints.md
index 28e626f..92e0c05 100644
--- a/gcc/config/i386/constraints.md
+++ b/gcc/config/i386/constraints.md
@@ -19,7 +19,7 @@
 
 ;;; Unused letters:
 ;;; B H   T
-;;;   h jk
+;;;   h j
 
 ;; Integer register constraints.
 ;; It is not necessary to define 'r' here.
@@ -78,6 +78,12 @@
  "TARGET_80387 || TARGET_FLOAT_RETURNS_IN_80387 ? FP_SECOND_REG : NO_REGS"
  "Second from top of 80387 floating-point stack (@code{%st(1)}).")
 
+(define_register_constraint "k" "TARGET_AVX512F ? MASK_EVEX_REGS : NO_REGS"
+"@internal Any mask register that can be used as predicate, i.e. k1-k7.")
+
+(define_register_constraint "Yk" "TARGET_AVX512F ? MASK_REGS : NO_REGS"
+"@internal Any mask register.")
+
 ;; Vector registers (also used for plain floating point nowadays).
 (define_register_constraint "y" "TARGET_MMX ? MMX_REGS : NO_REGS"
  "Any MMX register.")
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index cb86e3b..97ec224 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -2195,6 +2195,9 @@ enum reg_class const regclass_map[FIRST_PSEUDO_REGISTER] =
   EVEX_SSE_REGS, EVEX_SSE_REGS, EVEX_SSE_REGS, EVEX_SSE_REGS,
   EVEX_SSE_REGS, EVEX_SSE_REGS, EVEX_SSE_REGS, EVEX_SSE_REGS,
   EVEX_SSE_REGS, EVEX_SSE_REGS, EVEX_SSE_REGS, EVEX_SSE_REGS,
+  /* Mask registers.  */
+  MASK_REGS, MASK_EVEX_REGS, MASK_EVEX_REGS, MASK_EVEX_REGS,
+  MASK_EVEX_REGS, MASK_EVEX_REGS, MASK_EVEX_REGS, MASK_EVEX_REGS,
 };
 
 /* The "default" register map used in 32bit mode.  */
@@ -2210,6 +2213,7 @@ int const dbx_register_map[FIRST_PSEUDO_REGISTER] =
   -1, -1, -1, -1, -1, -1, -1, -1,  /* extended SSE registers */
   -1, -1, -1, -1, -1, -1, -1, -1,   /* new SSE registers 16-23*/
   -1, -1, -1, -1, -1, -1, -1, -1,   /* new SSE registers 24-31*/
+  93, 94, 95, 96, 97, 98, 99, 100,  /* Mask registers */
 };
 
 /* The "default" register map used in 64bit mode.  */
@@ -2225,6 +2229,7 @@ int const dbx64_register_map[FIRST_PSEUDO_REGISTER] =
   25, 26, 27, 28, 29, 30, 31, 32,  /* extended SSE registers */
   67, 68, 69, 70, 71, 72, 73, 74,   /* new SSE registers 16-23 */
   75, 76, 77, 78, 79, 80, 81, 82,   /* new SSE registers 24-31 */
+  118, 119, 120, 121, 122, 123, 124, 125, /* Mask registers */
 };
 
 /* Define the register numbers to be used in Dwarf debugging information.
@@ -2292,6 +2297,7 @@ int const svr4_dbx_register_map[FIRST_PSEUDO_REGISTER] =
   -1, -1, -1, -1, -1, -1, -1, -1,  /* extended SSE registers */
   -1, -1, -1, -1, -1, -1, -1, -1,   /* new SSE registers 16-23*/
   -1, -1, -1, -1, -1, -1, -1, -1,   /* new SSE registers 24-31*/
+  93, 94, 95, 96, 97, 98, 99, 100,  /* Mask registers */
 };
 
 /* Define parameter passing and return registers.  */
@@ -4157,7 +4163,8 @@ ix86_conditional_register_usage (void)
   /* If AVX512F is disabled, squash the registers.  */
   if (! TARGET_AVX512F)
 for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)
-  if (TEST_HARD_REG_BIT (reg_class_contents[(int)EVEX_SSE_REGS], i))
+  if (TEST_HARD_REG_BIT (reg_class_contents[(int)MASK_REGS], i)
+ || TEST_HARD_REG_BIT (reg_class_contents[(int)EVEX_SSE_REGS], i))
fixed_regs[i] = call_used_regs[i] = 1, reg_names[i] = "";
 }
 
@@ -33810,10 +33817,12 @@ ix86_preferred_reload_class (rtx x, reg_class_t 
regclass)
 return regclass;
 
   /* Force constants into memory if we are loading a (nonzero) constant into
- an MMX or SSE register.  This is because there are no MMX/SSE instructions
- to load from a constant.  */
+ an MMX, SSE or MASK register.  This is because there are no MMX/SSE/MASK
+ instructions to load from a constant.  */
   if (CONSTANT_P (x)
-  && (MAYBE_MMX_CLASS_P (regclass) || MAYBE_SSE_CLASS_P (regclass)))
+  && (MAYBE_MMX_CLASS_P (regclass)
+ || MAYBE_SSE_CLASS_P (regclass)
+ || MAYBE_MASK_CLASS_

Re: [PATCH] MIPS/libgcc: Avoid the PLT in MIPS16 stub calls

[Richard Sandiford]

"Maciej W. Rozycki"  writes:
>  BTW, what's the "Check for MicroMIPS support." note seen in the 
> config.host piece of the patch referring to?

No idea, please remove it.

>  /* Define a function NAME that moves a return value of mode MODE from
> FPRs to GPRs.  */
>  
> -#define RET_FUNCTION(NAME, MODE) \
> +#define _RET_FUNCTION(NAME, MODE)\
>  STARTFN (NAME);  \
>   MOVE_##MODE##_RET (t, $31); \
>   ENDFN (NAME)
>  
> +#ifdef SHARED
> +#define RET_FUNCTION(NAME, MODE) \
> + _RET_FUNCTION (NAME##_compat, MODE);\
> + .symver NAME##_compat, NAME##@GCC_4.4.0
> +#else
> +#define RET_FUNCTION(NAME, MODE) \
> + _RET_FUNCTION (NAME, MODE); \
> + .hidden NAME
> +#endif

Rather than repeat this, I think we should have:

#ifdef SHARED
#define CE_STARTFN(NAME) \
  STARTFN (NAME##_compat); \
  .symver NAME##_compat, NAME@GCC_4.4.0
#define CE_ENDFN(NAME) ENDFN (NAME##_compat)
#else
#define CE_STARTFN(NAME) STARTFN (NAME); .hidden NAME
#define CE_ENDFN(NAME) ENDFN (NAME)
#endif

below your new comment, with CE arbitrarily standing for "compat export".
Feel free to use different names if you can think of something better.
Note no "##" before "@".

Please also delete the corresponding entries in libgcc.ver, which should
no longer be needed.

OK with those changes, thanks.  No need for a full retest; checking
that libgcc_s.so.1 and libgcc.a are unchanged from your posted version
should be fine.

Richard

Re: MIPS tests (nan-legacy.c and nans-legacy.c) failing

[Richard Sandiford]

"Steve Ellcey "  writes:
> Maciej,
>
> When I run two of your new tests in gcc.target/mips (nan-legacy.c and
> nans-legacy.c), they are failing because my GCC is putting out
>
>   .word   4294967295
>
> instead of 
>
>   .word   -1
>
> like the test is expecting.
>
> I believe they are equivalent (0x) but I am not sure what it
> is about my targets (mips-mti-elf and mips-mti-linux-gnu) that would
> make this different from yours.  Should the tests be modified to allow
> either output?

Maciej, have you had chance to look at this yet?

Thanks,
Richard

Re: [C++ Patch / RFC] PR 54864

[Paolo Carlini]

Hi,

On 08/07/2013 09:52 PM, Jason Merrill wrote:

The rule that allows use of *this is pretty specific:

Unlike the object expression in other contexts, *this is not required 
to be of complete type for purposes of class member access (5.2.5) 
outside the member function body.


That doesn't seem to allow the use of *outer.

Ok. I'm closing the report as invalid.

Thanks!
Paolo.

Re: [buildbot] r201508: Build failures after pass C++ conversion

[David Malcolm]

On Wed, 2013-08-07 at 09:01 +0200, Andreas Schwab wrote:
> David Malcolm  writes:
> 
> > diff --git a/gcc/coretypes.h b/gcc/coretypes.h
> > index edb9c8c..54bfe7f 100644
> > --- a/gcc/coretypes.h
> > +++ b/gcc/coretypes.h
> > @@ -169,6 +169,12 @@ typedef const struct basic_block_def 
> > *const_basic_block;
> > in target.h.  */
> >  typedef int reg_class_t;
> >  
> > +class rtl_opt_pass;
> > +
> > +namespace gcc {
> > +  class context;
> > +}
> > +
> 
> This break Ada.
> 
> ../../xgcc -B../../ -c -DIN_GCC  -DUSE_LIBUNWIND_EXCEPTIONS -O2 -g -W -Wall  \
>   -iquote /usr/local/gcc/gcc-20130807/gcc \
>    -iquote . -iquote .. -iquote ../.. -iquote 
> /usr/local/gcc/gcc-20130807/gcc/ada -iquote /usr/local/gcc/gcc-20130807/gcc 
> -I/usr/local/gcc/gcc-20130807/gcc/../include 
> -I/usr/local/gcc/gcc-20130807/Build/./gmp -I/usr/local/gcc/gcc-20130807/gmp 
> -I/usr/local/gcc/gcc-20130807/Build/./mpfr -I/usr/local/gcc/gcc-20130807/mpfr 
> -I/usr/local/gcc/gcc-20130807/mpc/src  \
>   ../rts/targext.c -o targext.o
> In file included from ../rts/targext.c:45:0:
> /usr/local/gcc/gcc-20130807/gcc/coretypes.h:172:1: error: unknown type name 
> 'class'
>  class rtl_opt_pass;
>  ^
> /usr/local/gcc/gcc-20130807/gcc/coretypes.h:174:1: error: unknown type name 
> 'namespace'
>  namespace gcc {
>  ^
> /usr/local/gcc/gcc-20130807/gcc/coretypes.h:174:15: error: expected '=', ',', 
> ';', 'asm' or '__attribute__' before '{' token
>  namespace gcc {
>^
> make[3]: *** [targext.o] Error 1

Sorry.  How does the attached look?  (am bootstrapping now)

commit 7af885276832d17e56cbb8e09787b2d4d95dc5ea
Author: David Malcolm 
Date:   Wed Aug 7 15:54:26 2013 -0400

Fix C++ usage in coretypes.h

gcc/
	* coretypes.h: Wrap decls using C++ syntax in a #ifdef __cplusplus
	for the sake of source files still built as pure C.

diff --git a/gcc/coretypes.h b/gcc/coretypes.h
index 54bfe7f..b28040a 100644
--- a/gcc/coretypes.h
+++ b/gcc/coretypes.h
@@ -169,11 +169,13 @@ typedef const struct basic_block_def *const_basic_block;
in target.h.  */
 typedef int reg_class_t;
 
+#ifdef __cplusplus
 class rtl_opt_pass;
 
 namespace gcc {
   class context;
 }
+#endif /* __cplusplus */
 
 #else
 

[ping] 3 pending patches

[Eric Botcazou]

Fix error recovery issue with alias:
  http://gcc.gnu.org/ml/gcc-patches/2013-06/msg01417.html

Improve debug info for small structures passed by reference:
  http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00895.html

Implement static stack checking for the ARM:
  http://gcc.gnu.org/ml/gcc-patches/2013-06/msg01421.html

Thanks in advance.

-- 
Eric Botcazou

[PATCH, libstdc++]: Avoid -Wcast-qual warnings in src/c++98/compatibility.cc

[Uros Bizjak]

Hello!

Attached patch avoids a bunch of -Wcast-qual warnings when building
libstdc++ on alpha-linux-gnu, a _GLIBCXX_LONG_DOUBLE_COMPAT target:

../../../../gcc-svn/trunk/libstdc++-v3/src/c++98/compatibility.cc:521:16:
warning: cast from type ‘const char*’ to type ‘void*’ casts away
qualifiers [-Wcast-qual]
   (void *) _ZTSe };
^
../../../../gcc-svn/trunk/libstdc++-v3/src/c++98/compatibility.cc:524:16:
warning: cast from type ‘const char*’ to type ‘void*’ casts away
qualifiers [-Wcast-qual]
   (void *) _ZTSPe, (void *) 0L, (void *) _ZTIe };
^
../../../../gcc-svn/trunk/libstdc++-v3/src/c++98/compatibility.cc:524:46:
warning: cast from type ‘const void* const*’ to type ‘void*’ casts
away qualifiers [-Wcast-qual]
   (void *) _ZTSPe, (void *) 0L, (void *) _ZTIe };
  ^
../../../../gcc-svn/trunk/libstdc++-v3/src/c++98/compatibility.cc:527:16:
warning: cast from type ‘const char*’ to type ‘void*’ casts away
qualifiers [-Wcast-qual]
   (void *) _ZTSPKe, (void *) 1L, (void *) _ZTIe };
^
../../../../gcc-svn/trunk/libstdc++-v3/src/c++98/compatibility.cc:527:47:
warning: cast from type ‘const void* const*’ to type ‘void*’ casts
away qualifiers [-Wcast-qual]
   (void *) _ZTSPKe, (void *) 1L, (void *) _ZTIe };

2013-08-07  Uros Bizjak  

* src/c++98/compatibility.cc (_ZTIe): Use const_cast to avoid warning.
(_ZTIPe): Ditto.
(ZTIPKe): Ditto.

The patch was bootstrapped on alpha-linux-gnu, regression test is still running.

OK for mainline if regtest shows no problems? Also for 4.8?

Uros.
Index: src/c++98/compatibility.cc
===
--- src/c++98/compatibility.cc  (revision 201568)
+++ src/c++98/compatibility.cc  (working copy)
@@ -518,13 +518,15 @@
 extern __attribute__((used, weak)) const char _ZTSPKe[4] = "PKe";
 extern __attribute__((used, weak)) const void * const _ZTIe[2]
   = { (void *) &_ZTVN10__cxxabiv123__fundamental_type_infoE[2],
-  (void *) _ZTSe };
+  const_cast(_ZTSe) };
 extern __attribute__((used, weak)) const void * const _ZTIPe[4]
   = { (void *) &_ZTVN10__cxxabiv119__pointer_type_infoE[2],
-  (void *) _ZTSPe, (void *) 0L, (void *) _ZTIe };
+  const_cast(_ZTSPe), (void *) 0L,
+  const_cast(_ZTIe) };
 extern __attribute__((used, weak)) const void * const _ZTIPKe[4]
   = { (void *) &_ZTVN10__cxxabiv119__pointer_type_infoE[2],
-  (void *) _ZTSPKe, (void *) 1L, (void *) _ZTIe };
+  const_cast(_ZTSPKe), (void *) 1L,
+  const_cast(_ZTIe) };
 #endif // _GLIBCXX_LONG_DOUBLE_COMPAT
 
 #ifdef _GLIBCXX_SYMVER_DARWIN

Aw: RFC/A: PR 58079: CONST_INT mode assert in combine.c:do_SUBST

[Jürgen Urban]

> PR 58079 is about the do_SUBST assert:
> 
>   /* Sanity check that we're replacing oldval with a CONST_INT
>that is a valid sign-extension for the original mode.  */
>   gcc_assert (INTVAL (newval)
> == trunc_int_for_mode (INTVAL (newval), GET_MODE (oldval)));
> 
> triggering while trying to optimise the temporary result:
> 
>   (eq (const_int -73 [0xffb7])
>   (reg:QI 234 [ MEM[(const u8 *)buf_7(D) + 4B] ])
> 
> combine_simplify_rtx calls simplify_comparison, which first canonicalises
> the order so that the constant is second and then promotes the comparison
> to SImode (the first supported comparison mode on MIPS).  So we end up with:
> 
>   (eq (zero_extend:SI (reg:QI 234 [ MEM[(const u8 *)buf_7(D) + 4B] ]))
>   (const_int 183 [0xb7]))
> 
> So far so good.  But combine_simplify_rtx then tries to install the
> new operands in-place, with the second part of:
> 
> /* If the code changed, return a whole new comparison.  */
> if (new_code != code)
>   return gen_rtx_fmt_ee (new_code, mode, op0, op1);
> 
> /* Otherwise, keep this operation, but maybe change its operands.
>This also converts (ne (compare FOO BAR) 0) to (ne FOO BAR).  */
> SUBST (XEXP (x, 0), op0);
> SUBST (XEXP (x, 1), op1);
> 
> And this triggers the assert because we're replacing a QImode register
> with the non-QImode constant 183.
> 
> One fix would be to extend the new_code != code condition, as below.
> This should avoid the problem cases without generating too much
> garbage rtl.  But if the condition's getting this complicated,
> perhaps it'd be better just to avoid SUBST here?  I.e.
> 
> if (new_code != code || op0 != XEXP (x, 0) || op1 != XEXP (x, 1))
>   return gen_rtx_fmt_ee (new_code, mode, op0, op1);
> 
> Just asking though. :-)
> 
> Tested on mipsisa64-elf.  OK to install?

Yes, this fixes the error.

Thanks
Jürgen

Re: [PATCH, libstdc++]: Avoid -Wcast-qual warnings in src/c++98/compatibility.cc

[Paolo Carlini]

Hi,

On 08/07/2013 10:48 PM, Uros Bizjak wrote:

2013-08-07  Uros Bizjak  

 * src/c++98/compatibility.cc (_ZTIe): Use const_cast to avoid warning.
 (_ZTIPe): Ditto.
 (ZTIPKe): Ditto.

The patch was bootstrapped on alpha-linux-gnu, regression test is still running.

OK for mainline if regtest shows no problems? Also for 4.8?

I think you want in any case Jakub to have a look.

Paolo.

Re: [PATCH/Merge Request] Vtable Verification feature.

[David Edelsohn]

Caroline,

When libvtv was checked in, libvtv/autom4te.cache subdirectory was
committed as well. I don't think that this was intended.

- David

Re: [PATCH/Merge Request] Vtable Verification feature.

[Caroline Tice]

+ gcc_patches list

On Wed, Aug 7, 2013 at 2:56 PM, Caroline Tice  wrote:
> No, it was not intended.   How do I undo that?
>
> -- Caroline
> cmt...@google.com
>
> On Wed, Aug 7, 2013 at 2:54 PM, David Edelsohn  wrote:
>> Caroline,
>>
>> When libvtv was checked in, libvtv/autom4te.cache subdirectory was
>> committed as well. I don't think that this was intended.
>>
>> - David

Re: [PATCH/Merge Request] Vtable Verification feature.

[Paolo Carlini]

.. I removed it.

Thanks,
Paolo.

Re: [PATCH, i386, MPX 1/X] Support of Intel MPX ISA

[Joseph S. Myers]

On Fri, 2 Aug 2013, Ilya Enkovich wrote:

> Hi All,
> 
> I've updated MPX Wiki page
> (http://gcc.gnu.org/wiki/Intel%20MPX%20support%20in%20the%20GCC%20compiler).
> I added instrumentation description, programming model description,
> differences with other checkers, implementation details.

Thanks.  As noted, there should be a clean separation between what's 
generic and what's architecture-specific - the generic command-line 
options, hooks etc. shouldn't mention "MPX" in their names.

I'm unclear on the references to *_nobnd and *_nochk functions - are there 
corresponding library (glibc etc.) changes to add additional function 
variants?  Are all built-in functions that use pointers modified so that 
GCC will insert the required checks when expanding inline?

I'm also unclear on how much --enable-mpx does - in general, it's 
desirable for a single compiler to be able to generate binaries both with 
and without the checks, and so quite possibly to build libgcc, libstdc++ 
etc. as multilibs both with and without MPX, rather than needing to make a 
static decision when GCC is built (so, any configure option should 
preferably be about building *extra* library variants, for example, rather 
than changing the options with which existing variants are built).

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

Re: [PATCH/Merge Request] Vtable Verification feature.

[Caroline Tice]

Thank you!

-- Caroline

On Wed, Aug 7, 2013 at 3:09 PM, Paolo Carlini  wrote:
> .. I removed it.
>
> Thanks,
> Paolo.

[patch, mips] Add nan2008 multilibs to mips-mti-* targets.

[Steve Ellcey]

I would like to add new variations to the mips-mti-elf and mips-mti-linux
targets to support the new NaN format on MIPS (mnan=2008 for IEEE 754-2008).
While I was doing this I noticed that I was handling mips16 and micromips
in a dumb manner.  I had them in MULTILIB_OPTIONS as non-exclusive flags
and then used MULTILIB_EXCEPTIONS to not allow them to both be used.
So I also changed MULTILIB_OPTIONS to make mips16 and micromips exclusive and
then I could get rid of one of the MULTILIB_EXCEPTIONS entries.  I also
make the new mnan=2008 flag exclusive of msoft-float since it is only
useful for hard-float.

OK to checkin?

Steve Ellcey
sell...@mips.com

2013-08-07  Steve Ellcey  

* config/mips/mti-linux.h (SYSROOT_SUFFIX_SPEC): Add nan2008.
* config/mips/t-mti-elf (MULTILIB_OPTIONS): Make mips16 and
micromips incompatible.  Add nan2008.
(MULTILIB_DIRNAMES): Add nan2008.
(MULTILIB_EXCEPTIONS): Remove mips16/micromips entry.
* config/mips/t-mti-linux (MULTILIB_OPTIONS): Make mips16
and micromips incompatible.  Add nan2008.
(MULTILIB_DIRNAMES): Add nan2008.
(MULTILIB_EXCEPTIONS): Remove mips16/micromips entry.


diff --git a/gcc/config/mips/mti-linux.h b/gcc/config/mips/mti-linux.h
index 45bc0b8..96dcac4 100644
--- a/gcc/config/mips/mti-linux.h
+++ b/gcc/config/mips/mti-linux.h
@@ -20,7 +20,7 @@ along with GCC; see the file COPYING3.  If not see
 /* This target is a multilib target, specify the sysroot paths.  */
 #undef SYSROOT_SUFFIX_SPEC
 #define SYSROOT_SUFFIX_SPEC \
-
"%{mips32:/mips32}%{mips64:/mips64}%{mips64r2:/mips64r2}%{mips16:/mips16}%{mmicromips:/micromips}%{mabi=64:/64}%{mel|EL:/el}%{msoft-float:/sof}"
+
"%{mips32:/mips32}%{mips64:/mips64}%{mips64r2:/mips64r2}%{mips16:/mips16}%{mmicromips:/micromips}%{mabi=64:/64}%{mel|EL:/el}%{msoft-float:/sof}%{mnan=2008:/nan2008}"
 
 #undef DRIVER_SELF_SPECS
 #define DRIVER_SELF_SPECS  \
diff --git a/gcc/config/mips/t-mti-elf b/gcc/config/mips/t-mti-elf
index bce8f06..4aec70c 100644
--- a/gcc/config/mips/t-mti-elf
+++ b/gcc/config/mips/t-mti-elf
@@ -19,8 +19,8 @@
 # The default build is mips32r2, hard-float big-endian.  Add mips32,
 # soft-float, and little-endian variations.
 
-MULTILIB_OPTIONS = mips32/mips64/mips64r2 mips16 mmicromips mabi=64 EL 
msoft-float
-MULTILIB_DIRNAMES = mips32 mips64 mips64r2 mips16 micromips 64 el sof
+MULTILIB_OPTIONS = mips32/mips64/mips64r2 mips16/mmicromips mabi=64 EL 
msoft-float/mnan=2008
+MULTILIB_DIRNAMES = mips32 mips64 mips64r2 mips16 micromips 64 el sof nan2008
 MULTILIB_MATCHES = EL=mel EB=meb
 
 # The 64 bit ABI is not supported on the mips32 architecture.
@@ -36,9 +36,7 @@ MULTILIB_EXCEPTIONS += mabi=64*
 MULTILIB_EXCEPTIONS += *mips64*/*mips16*
 MULTILIB_EXCEPTIONS += *mips16/mabi=64*
 
-# We only want micromips for mips32r2 architecture and we do not want
-# it used in conjunction with -mips16.
-MULTILIB_EXCEPTIONS += *mips16/mmicromips*
+# We only want micromips for mips32r2 architecture.
 MULTILIB_EXCEPTIONS += *mips64*/mmicromips*
 MULTILIB_EXCEPTIONS += *mips32/mmicromips*
 MULTILIB_EXCEPTIONS += *mmicromips/mabi=64*
diff --git a/gcc/config/mips/t-mti-linux b/gcc/config/mips/t-mti-linux
index bce8f06..4aec70c 100644
--- a/gcc/config/mips/t-mti-linux
+++ b/gcc/config/mips/t-mti-linux
@@ -19,8 +19,8 @@
 # The default build is mips32r2, hard-float big-endian.  Add mips32,
 # soft-float, and little-endian variations.
 
-MULTILIB_OPTIONS = mips32/mips64/mips64r2 mips16 mmicromips mabi=64 EL 
msoft-float
-MULTILIB_DIRNAMES = mips32 mips64 mips64r2 mips16 micromips 64 el sof
+MULTILIB_OPTIONS = mips32/mips64/mips64r2 mips16/mmicromips mabi=64 EL 
msoft-float/mnan=2008
+MULTILIB_DIRNAMES = mips32 mips64 mips64r2 mips16 micromips 64 el sof nan2008
 MULTILIB_MATCHES = EL=mel EB=meb
 
 # The 64 bit ABI is not supported on the mips32 architecture.
@@ -36,9 +36,7 @@ MULTILIB_EXCEPTIONS += mabi=64*
 MULTILIB_EXCEPTIONS += *mips64*/*mips16*
 MULTILIB_EXCEPTIONS += *mips16/mabi=64*
 
-# We only want micromips for mips32r2 architecture and we do not want
-# it used in conjunction with -mips16.
-MULTILIB_EXCEPTIONS += *mips16/mmicromips*
+# We only want micromips for mips32r2 architecture.
 MULTILIB_EXCEPTIONS += *mips64*/mmicromips*
 MULTILIB_EXCEPTIONS += *mips32/mmicromips*
 MULTILIB_EXCEPTIONS += *mmicromips/mabi=64*

Re: [PATCH/Merge Request] Vtable Verification feature.

[Michael Meissner]

On Wed, Aug 07, 2013 at 02:29:35PM +0200, Dominique Dhumieres wrote:
> Revision 201555 breaks boostrap on x86_64-apple-darwin10:
> 
> ...
> Checking multilib configuration for libvtv...
> make  all-recursive
> Making all in testsuite
> /bin/sh: line 0: cd: testsuite: No such file or directory
> make[4]: *** [all-recursive] Error 1
> make[3]: *** [all] Error 2
> make[2]: *** [all-stage1-target-libvtv] Error 2
> make[1]: *** [stage1-bubble] Error 2
> make: *** [all] Error 2
> 
> According to
> 
> * configure.ac: Add target-libvtv to target_libraries; disable libvtv
> on non-linux systems; add target-libvtv to noconfigdirs; add
> libsupc++/.libs to C++ library search paths.
> 
> libvtv should not be built on darwin, but in config.log I see
> 
> ...
> configure:3222: checking for libvtv support
> configure:3232: result: yes
> ...

Same on powerpc*-linux.

In looking at it briefly, I see several things wrong with the way libvtv is
configured.  Here is the guts of libvtv/configure.tgt:

case "${target}" in
  x86_64-*-linux* | i?86-*-linux*)
VTV_SUPPORTED=yes
;;
  powerpc*-*-linux*)
;;
  sparc*-*-linux*)
;;
  arm*-*-linux*)
;;
  x86_64-*-darwin[1]* | i?86-*-darwin[1]*)
VTV_SUPPORTED=no
;;
  *)
UNSUPPORTED=1
;;
esac

In the two places that use this script (top level configure, and configure
within libvtv), they both run the .tgt script with . ./,.  However, they
do no explicitly clear the UNSUPPORTED variable.  So perhaps you might have
some other script within the configure process use UNSUPPORTED, and it would
not get built for the system that supports it.

Then there is the problem that the two callers use different shell variables to
check whether the library is supported or not.  I tend to think the top level
configure should be changed to look at VTV_SUPPORTED and not UNSUPPORTED, and
that only the systems that it is know to work on should set the variable to
yes.

I.e.

case "${target}" in
  x86_64-*-linux* | i?86-*-linux*)
VTV_SUPPORTED=yes
unset UNSUPPORTED
;;
  *)
VTV_SUPPORTED=no
UNSUPPORTED=1
;;
esac

(remove the UNSUPPORTED lines if we change the top level configure).

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797

Re: [PATCH] - C11 expressions and stdatomic.h - Just for current state

[Joseph S. Myers]

On Fri, 2 Aug 2013, Andrew MacLeod wrote:

> The atomic expression patch works on many cases, but falls short with any kind
> of complexity on the RHS of an expression which needs to be mapped to an
> atomic_load.  Whilst parsing, we cant tell, and the rhs tends to become an
> expression before we really know. so In the comments I have my proposed
> solution which I will look at when I return in 2 weeks.
> Basically, rather than have the ATOMIC_TYPE attribute ripple all the way
> through an expression, as soon as we see an ATOMIC_TYPE, we wrap it in a new
> node ATOMIC_EXPR, which holds the atomic expression, and sets it own
> expression type to the non-atomic variant.  This means the only expressions
> which will have the TYPE_ATOMIC flag set will be ones which are wrapped in
> ATOMIC_EXPR, and those are the ones where we need to go and replace with an
> __atomic_load or whatever.

My understanding is that the issue here about loads applies exactly when 
an atomic lvalue is converted to an rvalue.

Thus, this should be handled not when the expression is parsed (it might 
after all be used as an operand of sizeof, unary &, increment, decrement 
or assignment operators, on the LHS of ".", or in some other GNU C cases 
such as __real__ and __imag__) but when the lvalue is converted to an 
rvalue.

Unfortunately there isn't a single well-defined place in the C front end 
at present that does such a conversion (and for non-atomics, it's not 
clear that e.g. inserting conversions to remove type qualifiers would be 
particularly useful).  There are calls to mark_exp_read in many relevant 
places, but that's not exactly the same (and, similarly, calls to 
default_function_array_conversion or 
default_function_array_read_conversion in some such places).  So I think 
you simply need to go through everywhere an expression appears in the 
syntax and make sure that if the context indicates lvalue-to-rvalue 
conversion happens, then a function that carries out such conversion (for 
the case of atomics) gets called.

Certainly it doesn't seem right to set the type of a containing expression 
to the non-atomic type immediately, given that lvalue conversion does not 
occur for operands of sizeof, and an atomic type may have a different type 
from the non-atomic variant.  So sizeof applied to an atomic lvalue needs 
to have the size of the atomic type.

A more ambiguous case is what happens with a cast to atomic type, or 
function returning atomic type, if the result is immediately passed to 
sizeof (and the atomic type has a different size from the non-atomic 
type).  This is related to DR#423; I'll raise it with WG14.

> Ive included an additional 2 line patch which should  change the meaning of
> __typeof__  (again untested, the joys of imminently leaving for 2 weeks  :-).
> Im not sure the normal practical uses of
> __typeof__ have much meaning for an atomic type, it seems far more useful to
> have __typeof__ for an atomic qualified type to return the non-atomic variant.

What typeof should do in general for qualified types is unclear 
(especially in the case of rvalues, where the movement in ISO C seems to 
be to say that rvalues can't have qualified types at all) - returning the 
non-atomic type seems reasonable to me.

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

[vtv] fix default configure

[Benjamin De Kosnik]

Here's a patch for the build failure on darwin.

tested x86/linux

-benjamindiff --git a/libvtv/Makefile.am b/libvtv/Makefile.am
index ab3233f..73acfb4 100644
--- a/libvtv/Makefile.am
+++ b/libvtv/Makefile.am
@@ -19,7 +19,11 @@
 ## along with this library; see the file COPYING3.  If not see
 ## .
 
+if ENABLE_VTABLE_VERIFY
 SUBDIRS = testsuite
+else
+SUBDIRS = 
+endif
 
 ACLOCAL_AMFLAGS = -I .. -I ../config
 
diff --git a/libvtv/acinclude.m4 b/libvtv/acinclude.m4
index 6faca98..53e62d2 100644
--- a/libvtv/acinclude.m4
+++ b/libvtv/acinclude.m4
@@ -30,17 +30,6 @@ dnl  - lots of tools, like CC and CXX
 dnl
 AC_DEFUN([LIBVTV_CONFIGURE], [
 
-  # Use same top-level configure hooks in libgcc/libstdc++/libvtv.
-  AC_ARG_ENABLE(vtable-verify,
-  [  --enable-vtable-verifyEnable vtable verification feature ],
-  [case "$enableval" in
-   yes) enable_vtable_verify=yes ;;
-   no)  enable_vtable_verify=no ;;
-   *)   enable_vtable_verify=no;;
-   esac],
-  [enable_vtable_verify=no])
-  AM_CONDITIONAL(ENABLE_VTABLE_VERIFY, test $enable_vtable_verify = yes)
-
   # These need to be absolute paths, yet at the same time need to
   # canonicalize only relative paths, because then amd will not unmount
   # drives. Thus the use of PWDCMD: set it to 'pawd' or 'amq -w' if using amd.
diff --git a/libvtv/configure.ac b/libvtv/configure.ac
index cc8e280..4724312 100644
--- a/libvtv/configure.ac
+++ b/libvtv/configure.ac
@@ -20,6 +20,34 @@ AC_ARG_ENABLE(version-specific-runtime-libs,
 [version_specific_libs=no])
 AC_MSG_RESULT($version_specific_libs)
 
+# Use same top-level configure hooks in libgcc/libstdc++/libvtv.
+AC_MSG_CHECKING([for --enable-vtable-verify])
+AC_ARG_ENABLE(vtable-verify,
+[  --enable-vtable-verifyEnable vtable verification feature ],
+[case "$enableval" in
+ yes) enable_vtable_verify=yes ;;
+ no)  enable_vtable_verify=no ;;
+ *)   enable_vtable_verify=no;;
+ esac],
+[enable_vtable_verify=no])
+AC_MSG_RESULT($enable_vtable_verify)
+
+# See if supported.
+unset VTV_SUPPORTED
+AC_MSG_CHECKING([for host support for vtable verification])
+. ${srcdir}/configure.tgt
+AC_MSG_RESULT($VTV_SUPPORTED)
+
+# Decide if it's usable.
+use_vtable_verify=no
+if test "x$VTV_SUPPORTED" = "xyes"; then
+  if test "x$enable_vtable_verify" = "xyes"; then
+use_vtable_verify=yes
+AC_MSG_NOTICE(using vtable verification)
+  fi
+fi 
+AM_CONDITIONAL(ENABLE_VTABLE_VERIFY, test $use_vtable_verify = yes)
+
 # Do not delete or change the following two lines.  For why, see
 # http://gcc.gnu.org/ml/libstdc++/2003-07/msg00451.html
 AC_CANONICAL_SYSTEM
@@ -31,6 +59,8 @@ AM_INIT_AUTOMAKE(foreign no-dist)
 AM_ENABLE_MULTILIB(, ..)
 AM_MAINTAINER_MODE
 
+LIBVTV_CONFIGURE
+
 # Calculate toolexeclibdir
 # Also toolexecdir, though it's only used in toolexeclibdir
 case ${version_specific_libs} in
@@ -102,13 +132,6 @@ else
   multilib_arg=
 fi
 
-LIBVTV_CONFIGURE
-
-# Get target configury.
-unset VTV_SUPPORTED
-. ${srcdir}/configure.tgt
-AM_CONDITIONAL(VTV_SUPPORTED, [test "x$VTV_SUPPORTED" = "xyes"])
-
 AC_CONFIG_FILES([Makefile])
 
 if test "x$VTV_SUPPORTED" = "xyes"; then

Re: New option to do fine grain control [on|off] of micro-arch specific features : -mtune-ctrl=....

[Joseph S. Myers]

On Sun, 4 Aug 2013, Andi Kleen wrote:

> Richard Biener  writes:
> >
> > The patch fails to add documentation.
> 
> That seems like a feature, it's likely not useful for the general
> public. More for specialized tools that automatically search
> for the best tuning.

If such a tool is not part of GCC itself, then it is a user of GCC and 
documentation should be provided for those writing such a tool.

Options should be undocumented in very limited cases such as multiple 
variant spellings where only one should be used but others are accepted 
because they were historically, or whether the user interface to an option 
is separate from the internal option passed to cc1 (the documentation is 
of options as passed to the driver, but the .opt file may describe options 
passed to cc1 as a result of other options being passed to the driver), or 
the option really is only for use within the build of GCC itself.  
Otherwise, the strong presumption is that all options should be 
documented, with appropriate caveats as applicable about the cases where 
an option is useful.

> > And I am nervous about testing
> > coverage - is this considered a development option only or are random
> > combinations expected to work in all situations? I expect not, thus
> > this looks like a dangerous option?
> 
> When it's undocumented it doesn't need to work in every situation?

No input files and command-line arguments whatsoever to the driver should 
result in ICEs, including undocumented options.

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

Re: [Patch] Whole regex refactoring and current status

[Tim Shen]

On Wed, Aug 7, 2013 at 12:04 AM, Paolo Carlini  wrote:
> By the way, your last patch is fine with me, I like the new *.tcc a lot.
> Just allow a day or so for further comments..

Committed.


-- 
Tim Shen

Re: New option to do fine grain control [on|off] of micro-arch specific features : -mtune-ctrl=....

[Xinliang David Li]

On Wed, Aug 7, 2013 at 4:54 PM, Joseph S. Myers  wrote:
> On Sun, 4 Aug 2013, Andi Kleen wrote:
>
>> Richard Biener  writes:
>> >
>> > The patch fails to add documentation.
>>
>> That seems like a feature, it's likely not useful for the general
>> public. More for specialized tools that automatically search
>> for the best tuning.
>
> If such a tool is not part of GCC itself, then it is a user of GCC and
> documentation should be provided for those writing such a tool.
>
> Options should be undocumented in very limited cases such as multiple
> variant spellings where only one should be used but others are accepted
> because they were historically, or whether the user interface to an option
> is separate from the internal option passed to cc1 (the documentation is
> of options as passed to the driver, but the .opt file may describe options
> passed to cc1 as a result of other options being passed to the driver), or
> the option really is only for use within the build of GCC itself.
> Otherwise, the strong presumption is that all options should be
> documented, with appropriate caveats as applicable about the cases where
> an option is useful.
>

Fair enough. I will add the documentation in a followup patch which
also implements H.J's proposal -mno-default and cleans up the initial
tuning array to be always in sync with new enums.


>> > And I am nervous about testing
>> > coverage - is this considered a development option only or are random
>> > combinations expected to work in all situations? I expect not, thus
>> > this looks like a dangerous option?
>>
>> When it's undocumented it doesn't need to work in every situation?
>
> No input files and command-line arguments whatsoever to the driver should
> result in ICEs, including undocumented options.

True -- if ICEs are found, we should fix them.

thanks,

David

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

Re: New parameters to control stringop expansion libcall strategy

[Joseph S. Myers]

On Wed, 7 Aug 2013, Xinliang David Li wrote:

> Index: config/i386/stringop.def
> ===
> --- config/i386/stringop.def  (revision 0)
> +++ config/i386/stringop.def  (revision 0)
> @@ -0,0 +1,42 @@
> +/* Definitions for option handling for IA-32.
> +   Copyright (C) 2013 Free Software Foundation, Inc.
> +
> +This file is part of GCC.
> +
> +GCC is free software; you can redistribute it and/or modify
> +it under the terms of the GNU General Public License as published by
> +the Free Software Foundation; either version 3, or (at your option)
> +any later version.
> +
> +GCC is distributed in the hope that it will be useful,
> +but WITHOUT ANY WARRANTY; without even the implied warranty of
> +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +GNU General Public License for more details.
> +
> +Under Section 7 of GPL version 3, you are granted additional
> +permissions described in the GCC Runtime Library Exception, version
> +3.1, as published by the Free Software Foundation.

Why the exception?  This should only be used on the host, not the target.

> +  do
> +{
> +  int mins, maxs;
> +  stringop_alg alg;
> +  char alg_name[128];
> +  char align[16];
> +
> +  next_range_str = strchr (curr_range_str, ',');
> +  if (next_range_str)
> +*next_range_str++ = '\0';
> +
> +  if (3 != sscanf (curr_range_str, "%[^:]:%d:%s", alg_name, &maxs, 
> align))

This appears to introduce buffer overruns, which is never OK - whatever 
the length of strings in the command-line arguments, you must not overflow 
fixed-width buffers, so you must specify maximum field widths for the %[] 
and %s.

> +{
> +  warning (0, "Wrong arg %s to option %s", curr_range_str,
> +   is_memset ? "-mmemset_strategy=" : "-mmemcpy_strategy=");
> +  return;

Invalid option arguments should be errors, not warnings, and diagnostics 
should not start with a capital letter.  Same applies to other diagnostics 
here.

> Index: config/i386/stringop.opt
> ===
> --- config/i386/stringop.opt  (revision 0)
> +++ config/i386/stringop.opt  (revision 0)
> @@ -0,0 +1,36 @@
> +/* Definitions for option handling for IA-32.
> +   Copyright (C) 2013 Free Software Foundation, Inc.
> +
> +This file is part of GCC.
> +
> +GCC is free software; you can redistribute it and/or modify
> +it under the terms of the GNU General Public License as published by
> +the Free Software Foundation; either version 3, or (at your option)
> +any later version.
> +
> +GCC is distributed in the hope that it will be useful,
> +but WITHOUT ANY WARRANTY; without even the implied warranty of
> +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +GNU General Public License for more details.
> +
> +Under Section 7 of GPL version 3, you are granted additional
> +permissions described in the GCC Runtime Library Exception, version
> +3.1, as published by the Free Software Foundation.

Again, why the exception?

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

Re: New parameters to control stringop expansion libcall strategy

[Xinliang David Li]

On Wed, Aug 7, 2013 at 5:23 PM, Joseph S. Myers  wrote:
> On Wed, 7 Aug 2013, Xinliang David Li wrote:
>
>> Index: config/i386/stringop.def
>> ===
>> --- config/i386/stringop.def  (revision 0)
>> +++ config/i386/stringop.def  (revision 0)
>> @@ -0,0 +1,42 @@
>> +/* Definitions for option handling for IA-32.
>> +   Copyright (C) 2013 Free Software Foundation, Inc.
>> +
>> +This file is part of GCC.
>> +
>> +GCC is free software; you can redistribute it and/or modify
>> +it under the terms of the GNU General Public License as published by
>> +the Free Software Foundation; either version 3, or (at your option)
>> +any later version.
>> +
>> +GCC is distributed in the hope that it will be useful,
>> +but WITHOUT ANY WARRANTY; without even the implied warranty of
>> +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> +GNU General Public License for more details.
>> +
>> +Under Section 7 of GPL version 3, you are granted additional
>> +permissions described in the GCC Runtime Library Exception, version
>> +3.1, as published by the Free Software Foundation.
>
> Why the exception?  This should only be used on the host, not the target.


Sorry, I copied the boiler-plate header from i386.h -- is it wrong there too?


>
>> +  do
>> +{
>> +  int mins, maxs;
>> +  stringop_alg alg;
>> +  char alg_name[128];
>> +  char align[16];
>> +
>> +  next_range_str = strchr (curr_range_str, ',');
>> +  if (next_range_str)
>> +*next_range_str++ = '\0';
>> +
>> +  if (3 != sscanf (curr_range_str, "%[^:]:%d:%s", alg_name, &maxs, 
>> align))
>
> This appears to introduce buffer overruns, which is never OK - whatever
> the length of strings in the command-line arguments, you must not overflow
> fixed-width buffers, so you must specify maximum field widths for the %[]
> and %s.
>

Ok will fix.


>> +{
>> +  warning (0, "Wrong arg %s to option %s", curr_range_str,
>> +   is_memset ? "-mmemset_strategy=" : "-mmemcpy_strategy=");
>> +  return;
>
> Invalid option arguments should be errors, not warnings, and diagnostics
> should not start with a capital letter.  Same applies to other diagnostics
> here.
>

Ok will fix.


>> Index: config/i386/stringop.opt
>> ===
>> --- config/i386/stringop.opt  (revision 0)
>> +++ config/i386/stringop.opt  (revision 0)
>> @@ -0,0 +1,36 @@
>> +/* Definitions for option handling for IA-32.
>> +   Copyright (C) 2013 Free Software Foundation, Inc.
>> +
>> +This file is part of GCC.
>> +
>> +GCC is free software; you can redistribute it and/or modify
>> +it under the terms of the GNU General Public License as published by
>> +the Free Software Foundation; either version 3, or (at your option)
>> +any later version.
>> +
>> +GCC is distributed in the hope that it will be useful,
>> +but WITHOUT ANY WARRANTY; without even the implied warranty of
>> +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> +GNU General Public License for more details.
>> +
>> +Under Section 7 of GPL version 3, you are granted additional
>> +permissions described in the GCC Runtime Library Exception, version
>> +3.1, as published by the Free Software Foundation.
>
> Again, why the exception?

Wrong template used.

thanks,

David

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

Re: [PATCH/Merge Request] Vtable Verification feature.

[Joseph S. Myers]

Looking at the patch as committed, there seems to be some confusion about 
the nature of the --enable-vtable-verify configure option.

It's documented only for libstdc++.  Now, I still consider the existence 
of separate documentation for libstdc++ configure options to be 
unfortunate - I think all configure options for GCC should be documented 
in one place - but that's a separate matter.  Although only documented for 
libstdc++, it actually appears to be used in the libgcc and libvtv 
configure scripts.

Given that it has effects on more than just libstdc++, it needs 
documenting in gcc/doc/install.texi, the main documentation of configure 
options for GCC.  Then there's the question of what the semantics should 
be.  My presumption is that the feature should be available for all GCC 
builds, at least by default on platforms where it can work, and the only 
thing needing a configure option should be whether the checks are enabled 
for libstdc++ itself (and ideally that would work by multilibbing 
libstdc++ rather than needing separate GCC builds to get libstdc++ with 
and without the checks).  Thus if the platform supports the feature, all 
relevant libgcc files should be built, and anything for libstdc++ needed 
for user code to use the feature should be built - the only thing not 
enabled by default would be checks for libstdc++'s classes' own vtables.  
(And unless there are difficulties in building the libgcc files on some 
systems, they could be built unconditionally, whether or not any other 
support needed for libvtv is present.  Actually, it looks like they may 
depend on an ELF target, but not on anything more.)

Could you confirm that the libstdc++ ABI is not affected by the configure 
option - that the same symbols, at the same symbol versions, with the same 
semantics, are exported from libstdc++.so for builds with and without the 
feature enabled?

The file cp/vtable-class-hierarchy.c includes "tm.h".  Includes of tm.h 
from front ends are discouraged, and should have comments on them listing 
what target macros are used by the file in question (and so need to be 
converted to hooks before the include can be removed).  Could you add such 
a comment to the #include (or if it's redundant, remove all redundant 
#includes from that file)?

You have a

+#define MAX_SET_SIZE 5000

which superficially looks like an arbitrary limit.  Could you add a 
comment explaining why no input files, not matter how extreme, could ever 
exceed the limit of 5000?  You have a couple of gcc_asserts regarding this 
limit, and an on-stack array for which it's at least not immediately 
obvious that all accesses are checked to ensure that a buffer overrun is 
impossible.

If you have an arbitrary limit, and some input *can* exceed it (so 
triggering the gcc_asserts or buffer overrun), the right fix is of course 
to remove it, probably using vec.h to produce a dynamically growing array 
instead of hardcoding a size at all.  But failing that, exceeding the 
limit must result in a sorry () call, not an assertion failure or buffer 
overrun, neither of which is acceptable behavior for any compiler input 
whatever.

Other people have previously commented about the logs *generated by the 
compiler*.  The issue raised regarding the directories for those logs has 
been fixed so my only comment there is that the diagnostics for failure to 
open those files have several problems:

* Diagnostics should not start with a capital letter.

* Use %< and %> as quotes in diagnostics.

* Use %m in the diagnostic to print the error text corresponding to the 
errno value from the failure to open.

* I doubt input_location is particularly meaningful as a location for 
these diagnostics; warning_at with UNKNOWN_LOCATION may be better.

But there's a much more serious issue with logs generated *by libvtv*.  
These appear to use fixed filenames in a fixed directory /tmp/vtv_logs.  
That's always a mistake (I've encountered such trouble with QEMU using 
such a fixed log name in the past).  Not only that, neither O_EXCL nor 
O_NOFOLLOW is used so you have an obvious security hole.  Using such 
global locations is simply never OK; you need to arrange for such failures 
to go somewhere that will never conflict with other users.  You can't 
create a directory in /tmp (because proper ownership and permissions for 
such a shared directory would be the same as for /tmp itself, rather than 
leaving it owned by the first user to create it, and an unprivileged 
process can't ensure that).  I suggest:

* Prefer the current working directory (as used for core dumps) over /tmp 
(but if /tmp is used as a fallback, it needs to be /tmp not a subdirectory 
thereof).

* Name the generated file with a name that includes the program name, its 
pid, and a random string, to reduce the chance of conflicts.

* In any case, always open with O_NOFOLLOW (if defined) and O_EXCL to 
avoid symlink attacks.

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

Re: New parameters to control stringop expansion libcall strategy

[Joseph S. Myers]

On Wed, 7 Aug 2013, Xinliang David Li wrote:

> > Why the exception?  This should only be used on the host, not the target.
> 
> Sorry, I copied the boiler-plate header from i386.h -- is it wrong there too?

tm.h gets included in target code because we haven't finished separating 
target macros used on the target from those used on the host.

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

-mtune-ctrl=.... support, round-2

[Xinliang David Li]

Hi, the attached is a follow up patch. The patch includes the following changes:

1. new option -mno-default -- suggested by H.J. It can be combined
with -mtune-ctrl= to clear the default settings.
2. new option -mdump-tune-features -- this option can be used to dump
all feature names and their default settings.
3. Added documentation to the 3 new options

4. Move the contents of inital_x86_tune_features into x86-tune.def to
make sure they are always in sync
5. Some refactoring and handle the the tune features properly during
target option restore.

2013-08-07  Xinliang David Li  

* config/i386/i386.h: Adjust macro definition.
* config/i386/i386.opt: Define two new options.
* config/i386/x86-tune.def: Add arch selector field in macros.
* config/i386/i386.h: include x86-tune.def.
* config/i386/i386.c (ix86_option_override_internal):
Refactor the code.
(parse_mtune_ctrl_str): New function.
(set_ix86_tune_features): New function.
(ix86_function_specific_restore): Call the new helper function.

Ok for trunk after testing?

thanks,

David


On Wed, Aug 7, 2013 at 5:22 PM, Xinliang David Li  wrote:
> On Wed, Aug 7, 2013 at 4:54 PM, Joseph S. Myers  
> wrote:
>> On Sun, 4 Aug 2013, Andi Kleen wrote:
>>
>>> Richard Biener  writes:
>>> >
>>> > The patch fails to add documentation.
>>>
>>> That seems like a feature, it's likely not useful for the general
>>> public. More for specialized tools that automatically search
>>> for the best tuning.
>>
>> If such a tool is not part of GCC itself, then it is a user of GCC and
>> documentation should be provided for those writing such a tool.
>>
>> Options should be undocumented in very limited cases such as multiple
>> variant spellings where only one should be used but others are accepted
>> because they were historically, or whether the user interface to an option
>> is separate from the internal option passed to cc1 (the documentation is
>> of options as passed to the driver, but the .opt file may describe options
>> passed to cc1 as a result of other options being passed to the driver), or
>> the option really is only for use within the build of GCC itself.
>> Otherwise, the strong presumption is that all options should be
>> documented, with appropriate caveats as applicable about the cases where
>> an option is useful.
>>
>
> Fair enough. I will add the documentation in a followup patch which
> also implements H.J's proposal -mno-default and cleans up the initial
> tuning array to be always in sync with new enums.
>
>
>>> > And I am nervous about testing
>>> > coverage - is this considered a development option only or are random
>>> > combinations expected to work in all situations? I expect not, thus
>>> > this looks like a dangerous option?
>>>
>>> When it's undocumented it doesn't need to work in every situation?
>>
>> No input files and command-line arguments whatsoever to the driver should
>> result in ICEs, including undocumented options.
>
> True -- if ICEs are found, we should fix them.
>
> thanks,
>
> David
>
>>
>> --
>> Joseph S. Myers
>> jos...@codesourcery.com
Index: doc/invoke.texi
===
--- doc/invoke.texi (revision 201581)
+++ doc/invoke.texi (working copy)
@@ -637,6 +637,7 @@ Objective-C and Objective-C++ Dialects}.
 
 @emph{i386 and x86-64 Options}
 @gccoptlist{-mtune=@var{cpu-type}  -march=@var{cpu-type} @gol
+-mtune-ctrl=@var{feature-list} -mdump-tune-features -mno-default @gol
 -mfpmath=@var{unit} @gol
 -masm=@var{dialect}  -mno-fancy-math-387 @gol
 -mno-fp-ret-in-387  -msoft-float @gol
@@ -14428,6 +14429,24 @@ supported architecture, using the approp
 the file containing the CPU detection code should be compiled without
 these options.
 
+@item -mdump-tune-features
+@opindex mdump-tune-features
+This option instructs GCC to dump the names of the x86 performance 
+tuning features and default settings. The names can be used in 
+@option{-mtune-ctrl=@var{feature-list}}.
+
+@item -mtune-ctrl=@var{feature-list}
+@opindex mtune-ctrl=@var{feature-list}
+This option is used to do fine grain control of x86 code generation features.
+@var{feature-list} is a comma separated list of @var{feature} names. See also
+@option{-mdump-tune-features}. When specified, the @var{feature} will be turned
+on if it is not preceded with @code{^}, otherwise, it will be turned off.
+
+@item -mno-default
+@opindex mno-default
+This option instructs GCC to turn off all tunable features. See also 
+@option{-mtune-ctrl=@var{feature-list}} and @option{-mdump-tune-features}.
+
 @item -mcld
 @opindex mcld
 This option instructs GCC to emit a @code{cld} instruction in the prologue
Index: config/i386/i386.opt
===
--- config/i386/i386.opt(revision 201582)
+++ config/i386/i386.opt(working copy)
@@ -374,6 +374,13 @@ mtune-ctrl=
 Target RejectNegative Joined Var(ix86_tu

Re: New parameters to control stringop expansion libcall strategy

[Xinliang David Li]

Updated patch attached (fixed header, buffer overflow, and warning -->
error problems).

Ok for trunk?

thanks,

David

On Wed, Aug 7, 2013 at 6:04 PM, Joseph S. Myers  wrote:
> On Wed, 7 Aug 2013, Xinliang David Li wrote:
>
>> > Why the exception?  This should only be used on the host, not the target.
>>
>> Sorry, I copied the boiler-plate header from i386.h -- is it wrong there too?
>
> tm.h gets included in target code because we haven't finished separating
> target macros used on the target from those used on the host.
>
> --
> Joseph S. Myers
> jos...@codesourcery.com
Index: config/i386/stringop.def
===
--- config/i386/stringop.def(revision 0)
+++ config/i386/stringop.def(revision 0)
@@ -0,0 +1,37 @@
+/* Definitions for stringop strategy for IA-32.
+   Copyright (C) 2013 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GCC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License 
+along with GCC; see the files COPYING3.  If not,
+see .  */
+
+DEF_ENUM
+DEF_ALG (no_stringop, no_stringop)
+DEF_ENUM
+DEF_ALG (libcall, libcall)
+DEF_ENUM
+DEF_ALG (rep_prefix_1_byte, rep_byte)
+DEF_ENUM
+DEF_ALG (rep_prefix_4_byte, rep_4byte)
+DEF_ENUM
+DEF_ALG (rep_prefix_8_byte, rep_8byte)
+DEF_ENUM
+DEF_ALG (loop_1_byte, byte_loop)
+DEF_ENUM
+DEF_ALG (loop, loop)
+DEF_ENUM
+DEF_ALG (unrolled_loop, unrolled_loop)
+DEF_ENUM
+DEF_ALG (vector_loop, vector_loop)
Index: config/i386/stringop.opt
===
--- config/i386/stringop.opt(revision 0)
+++ config/i386/stringop.opt(revision 0)
@@ -0,0 +1,31 @@
+/* Definitions for stringop option handling for IA-32.
+   Copyright (C) 2013 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GCC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the files COPYING3.  If not,
+see .  */
+
+Enum(stringop_alg) String(rep_byte) Value(rep_prefix_1_byte)
+
+#undef DEF_ENUM
+#define DEF_ENUM EnumValue
+
+#undef DEF_ALG
+#define DEF_ALG(alg, name) Enum(stringop_alg) String(name) Value(alg)
+
+#include "stringop.def"
+
+#undef DEF_ENUM
+#undef DEF_ALG
Index: config/i386/i386-opts.h
===
--- config/i386/i386-opts.h (revision 201581)
+++ config/i386/i386-opts.h (working copy)
@@ -28,15 +28,17 @@ see the files COPYING3 and COPYING.RUNTI
 /* Algorithm to expand string function with.  */
 enum stringop_alg
 {
-   no_stringop,
-   libcall,
-   rep_prefix_1_byte,
-   rep_prefix_4_byte,
-   rep_prefix_8_byte,
-   loop_1_byte,
-   loop,
-   unrolled_loop,
-   vector_loop
+#undef DEF_ENUM
+#define DEF_ENUM
+
+#undef DEF_ALG
+#define DEF_ALG(alg, name) alg, 
+
+#include "stringop.def"
+last_alg
+
+#undef DEF_ENUM
+#undef DEF_ALG
 };
 
 /* Available call abi.  */
Index: config/i386/i386.c
===
--- config/i386/i386.c  (revision 201582)
+++ config/i386/i386.c  (working copy)
@@ -158,7 +158,7 @@ struct processor_costs ix86_size_cost =
 };
 
 /* Processor costs (relative to an add) */
-static const
+static
 struct processor_costs i386_cost = {   /* 386 specific costs */
   COSTS_N_INSNS (1),   /* cost of an add instruction */
   COSTS_N_INSNS (1),   /* cost of a lea instruction */
@@ -228,7 +228,7 @@ struct processor_costs i386_cost = {/*
   1,   /* cond_not_taken_branch_cost.  */
 };
 
-static const
+static
 struct processor_costs i486_cost = {   /* 486 specific costs */
   COSTS_N_INSNS (1),   /* cost of an add instruction */
   COSTS_N_INSNS (1),   /* cost of a lea instruction */
@@ -300,7 +300,7 @@ struct processor_costs i486_cost = {/*
   1,   /* cond_not_taken_branch_cost.  */
 };
 
-static const
+static
 struct processor_costs pentium_cost = {
   COSTS_N_INSNS (1),   /* cost