Re: C++ PATCH for c++/54575 (ICE with alias template)

[Gabriel Dos Reis]

On Mon, Sep 17, 2012 at 10:39 PM, Jason Merrill  wrote:
> The change to make SCOPE_REFs value-dependent revealed a bug in our handling
> of alias-template instantiations; we weren't pushing into the context of the
> alias before substituting the type, and then we were remembering the
> previously instantiated one when instantiating in a different context.  If
> the difference in context makes a difference, for instance in access
> control, this is broken.
>
> There are two possible ways to fix this: either push into the context of the
> alias or don't remember instantiations.  EDG takes the former approach,
> clang the latter.  I've raised the issue with the committee, but for the
> moment I'm following the EDG approach.
>
> Tested x86_64-pc-linux-gnu, applying to trunk.

I endorse the EDG interpretation.

-- Gaby

C++ PATCH for c++/54575 (ICE with alias template)

[Jason Merrill]

The change to make SCOPE_REFs value-dependent revealed a bug in our 
handling of alias-template instantiations; we weren't pushing into the 
context of the alias before substituting the type, and then we were 
remembering the previously instantiated one when instantiating in a 
different context.  If the difference in context makes a difference, for 
instance in access control, this is broken.


There are two possible ways to fix this: either push into the context of 
the alias or don't remember instantiations.  EDG takes the former 
approach, clang the latter.  I've raised the issue with the committee, 
but for the moment I'm following the EDG approach.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit 64de00d68f48f64700df3db37ed52ae2d2f8a1b0
Author: Jason Merrill 
Date:   Mon Sep 17 17:29:56 2012 -0400

	PR c++/54575
	* pt.c (instantiate_alias_template): New.
	(tsubst): Use it.
	(push_access_scope): Allow TYPE_DECL.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 7924dff..16952bf 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -205,16 +205,18 @@ static tree template_parm_to_arg (tree t);
 static bool arg_from_parm_pack_p (tree, tree);
 static tree current_template_args (void);
 static tree tsubst_template_parm (tree, tree, tsubst_flags_t);
+static tree instantiate_alias_template (tree, tree, tsubst_flags_t);
 
 /* Make the current scope suitable for access checking when we are
processing T.  T can be FUNCTION_DECL for instantiated function
-   template, or VAR_DECL for static member variable (need by
-   instantiate_decl).  */
+   template, VAR_DECL for static member variable, or TYPE_DECL for
+   alias template (needed by instantiate_decl).  */
 
 static void
 push_access_scope (tree t)
 {
   gcc_assert (TREE_CODE (t) == FUNCTION_DECL
+	  || TREE_CODE (t) == TYPE_DECL
 	  || TREE_CODE (t) == VAR_DECL);
 
   if (DECL_FRIEND_CONTEXT (t))
@@ -10949,10 +10951,10 @@ tsubst (tree t, tree args, tsubst_flags_t complain, tree in_decl)
 	  && PRIMARY_TEMPLATE_P (DECL_TI_TEMPLATE (decl)))
 	{
 	  /* DECL represents an alias template and we want to
-	 instantiate it.  Let's substitute our arguments for the
-	 template parameters into the declaration and get the
-	 resulting type.  */
-	  r = tsubst (decl, args, complain, decl);
+	 instantiate it.  */
+	  tree tmpl = most_general_template (DECL_TI_TEMPLATE (decl));
+	  tree gen_args = tsubst (DECL_TI_ARGS (decl), args, complain, in_decl);
+	  r = instantiate_alias_template (tmpl, gen_args, complain);
 	}
   else if (DECL_CLASS_SCOPE_P (decl)
 	   && CLASSTYPE_TEMPLATE_INFO (DECL_CONTEXT (decl))
@@ -14377,7 +14379,7 @@ recheck_decl_substitution (tree d, tree tmpl, tree args)
   pop_access_scope (d);
 }
 
-/* Instantiate the indicated variable or function template TMPL with
+/* Instantiate the indicated variable, function, or alias template TMPL with
the template arguments in TARG_PTR.  */
 
 static tree
@@ -14526,6 +14528,35 @@ instantiate_template (tree tmpl, tree orig_args, tsubst_flags_t complain)
   return ret;
 }
 
+/* Instantiate the alias template TMPL with ARGS.  Also push a template
+   instantiation level, which instantiate_template doesn't do because
+   functions and variables have sufficient context established by the
+   callers.  */
+
+static tree
+instantiate_alias_template (tree tmpl, tree args, tsubst_flags_t complain)
+{
+  struct pending_template *old_last_pend = last_pending_template;
+  struct tinst_level *old_error_tinst = last_error_tinst_level;
+  if (tmpl == error_mark_node || args == error_mark_node)
+return error_mark_node;
+  tree tinst = build_tree_list (tmpl, args);
+  if (!push_tinst_level (tinst))
+{
+  ggc_free (tinst);
+  return error_mark_node;
+}
+  tree r = instantiate_template (tmpl, args, complain);
+  pop_tinst_level ();
+  /* We can't free this if a pending_template entry or last_error_tinst_level
+ is pointing at it.  */
+  if (last_pending_template == old_last_pend
+  && last_error_tinst_level == old_error_tinst)
+ggc_free (tinst);
+
+  return r;
+}
+
 /* PARM is a template parameter pack for FN.  Returns true iff
PARM is used in a deducible way in the argument list of FN.  */
 
diff --git a/gcc/testsuite/g++.dg/cpp0x/alias-decl-21.C b/gcc/testsuite/g++.dg/cpp0x/alias-decl-21.C
new file mode 100644
index 000..463f539
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/alias-decl-21.C
@@ -0,0 +1,23 @@
+// PR c++/54575
+// { dg-do compile { target c++11 } }
+
+template
+struct is_convertible { static const bool value = true; };
+
+template struct enable_if   { };
+template<> struct enable_if { typedef int type; };
+
+template
+using _RequireInputIter
+= typename enable_if::value>::type;
+
+template struct X {
+template>
+  void insert(_InputIterator) {}
+};
+
+template void foo() {
+  X subdomain_indices;
+  subdomain_indices.insert(0);
+}
diff --git a/gcc/testsuite/g++.dg/cpp0x/alias-decl-22.C b/gcc/testsuite/g++.dg/c

Re: [patch, mips] Patch for new mips triplet - mips-mti-elf

[Steve Ellcey]

On Mon, 2012-09-17 at 21:36 +0100, Richard Sandiford wrote:

> It's a hosted vs. embedded thing.  Hosted targets like *-linux-gnu have
> dynamic ABI requirements and so are keyed off an ABI rather than an
> architecture.  The only effect of -march= and --with-arch= should be to
> extend the choice of available instructions.
> 
> That was actually very useful in pre MIPS(isa)32 and MIPS(isa)64 days,
> because MIPS IV had ISA extensions that could be used in 32-bit as well
> as 64-bit code.  You could therefore use the MIPS IV extensions with an
> existing 32-bit MIPS I or MIPS II sysroot.  The same sort of thing applied
> to processor-specific extensions in 64-bit processors (of which there were
> many :-)).  It's less useful with the stock MIPS32 and MIPS64 ISAs because
> the 32-bit subset of MIPS64 is (by design) essentially MIPS32.

If this is less useful now and since the multilib mips-mti-linux-gnu
target I created earlier is only supporting the mips32(r2) and
mips64(r2) ISAs (and not MIPS IV, etc) what do you think about me
changing that target to default to n32 when specifying the mips64 or
mips64r2 architectures and not specifying an explicit ABI?  That way
both the mips-mti-linux-gnu and mips-mti-elf targets will behave in the
same way with regards to the default ABI.

Steve Ellcey
sell...@mips.com

[patch] pr/54508: fix incomplete debug information for class

[Paul_Koning]

If the only reference in a source file is to a static method of a class, then 
GCC would output debug information for the class name but not any of its 
members or base classes.  The attached patch fixes this by having 
"prune_unused_types_mark" mark all of the parent's children if the parent DIE 
type is for a class.

The associated new testcase verifies this, and also verifies this that 
references to a function in a namespace do *not* cause other parts of that 
namespace to be emitted as debug information, but that references to a method 
in a class (or struct or union) do emit the other information for that class.

Ok to commit?  This would close PR/54508.

paul

ChangeLog:

2012-09-17  Paul Koning  

* dwarf2out.c (prune_unused_types_mark): Mark all of parent's
children if parent is a class.

testsuite/ChangeLog:

2012-09-17  Paul Koning  

* g++.dg/debug/dwarf2/pr54508.C: New.

Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 191408)
+++ gcc/dwarf2out.c (working copy)
@@ -21033,9 +21033,13 @@
   prune_unused_types_mark_generic_parms_dies (die);
 
   /* We also have to mark its parents as used.
-(But we don't want to mark our parents' kids due to this.)  */
+(But we don't want to mark our parent's kids due to this,
+unless it is a class.)  */
   if (die->die_parent)
-   prune_unused_types_mark (die->die_parent, 0);
+   prune_unused_types_mark (die->die_parent, 
+(die->die_parent->die_tag == DW_TAG_class_type 
||
+ die->die_parent->die_tag == 
DW_TAG_structure_type ||
+ die->die_parent->die_tag == 
DW_TAG_union_type));
 
   /* Mark any referenced nodes.  */
   prune_unused_types_walk_attribs (die);
Index: gcc/testsuite/g++.dg/debug/dwarf2/pr54508.C
===
--- gcc/testsuite/g++.dg/debug/dwarf2/pr54508.C (revision 0)
+++ gcc/testsuite/g++.dg/debug/dwarf2/pr54508.C (revision 0)
@@ -0,0 +1,67 @@
+// PR debug/54508
+// { dg-do compile }
+// { dg-options "-g2 -dA" }
+
+// { dg-final { scan-assembler "\"cbase0\"\[ \t\]+\# 
DW_AT_name\|DW_AT_name: \"cbase\"" } }
+// { dg-final { scan-assembler "\"OPCODE0\"\[ \t\]+\# 
DW_AT_name\|DW_AT_name: \"OPCODE\"" } }
+// { dg-final { scan-assembler "\"bi0\"\[ \t\]+\# DW_AT_name" } }
+// { dg-final { scan-assembler "\"si0\"\[ \t\]+\# DW_AT_name" } }
+// { dg-final { scan-assembler "\"f10\"\[ \t\]+\# DW_AT_name" } }
+// { dg-final { scan-assembler "\"f20\"\[ \t\]+\# DW_AT_name" } }
+// { dg-final { scan-assembler-not "\"nc0\"\[ \t\]+\# 
DW_AT_name\|DW_AT_name: \"nc\"" } }
+
+class cbase
+
+{
+public:
+ static int si;
+int bi;
+};
+
+class c : public cbase
+
+{
+public:
+ enum
+ {
+  OPCODE = 251
+ };
+ int i ;
+ static const char *testc (void) { return "foo"; }
+};
+
+struct s
+{
+int f1;
+static const char *tests (void) { return "test"; }
+};
+
+union u
+{
+int f2;
+double d;
+static const char *testu (void) { return "test union"; }
+};
+
+namespace n 
+{
+const char *ntest (void) { return "test n"; }
+
+class nc
+{
+public:
+int i;
+static int sj;
+};
+}
+
+extern void send (int, int, const void *, int);
+
+void test (int src)
+{
+  int cookie = 1;
+  send(src, c::OPCODE, c::testc (), cookie);
+  send(src, c::OPCODE, s::tests (), cookie);
+  send(src, c::OPCODE, u::testu (), cookie);
+  send(src, c::OPCODE, n::ntest (), cookie);
+}

Re: Backtrace library [1/3]

[Ian Lance Taylor]

On Mon, Sep 17, 2012 at 2:00 PM, Gerald Pfeifer  wrote:
> On Mon, 17 Sep 2012, Ian Lance Taylor wrote:
>> Please let me know about any build problems.
>
> i386-unknown-freebsd10.0 now fails as follows.  Others presumably
> have not run into this since "This source file is compiled if the
> unwind library is not available".

While this should be fixed now, note that it should only arise if
i386-unknown-freebsd10.0 does not use ELF.  If this is an ELF based
system, then we need to discover why it was not recognized as such.
What is the output of

awk -f SRCDIR/libbacktrace/filetype.awk foo.o

for some ELF foo.o file?

Ian

Re: Backtrace library [1/3]

[Ian Lance Taylor]

On Mon, Sep 17, 2012 at 2:00 PM, Gerald Pfeifer  wrote:
> On Mon, 17 Sep 2012, Ian Lance Taylor wrote:
>> Please let me know about any build problems.
>
> i386-unknown-freebsd10.0 now fails as follows.  Others presumably
> have not run into this since "This source file is compiled if the
> unwind library is not available".
>
> /scratch2/tmp/gerald/gcc-HEAD/libbacktrace/nounwind.c:48: warning: no 
> previous prototype for 'backtrace'
> /scratch2/tmp/gerald/gcc-HEAD/libbacktrace/nounwind.c:59: error: conflicting 
> types for 'backtrace_simple'
> /scratch2/tmp/gerald/gcc-HEAD/libbacktrace/backtrace.h:130: error: previous 
> declaration of 'backtrace_simple' was here
> gmake[4]: *** [nounwind.lo] Error 1
> gmake[4]: Leaving directory
> `/scratch2/tmp/gerald/OBJ-0917-1906/libbacktrace'
> gmake[3]: *** [all] Error 2
> gmake[3]: Leaving directory
> `/scratch2/tmp/gerald/OBJ-0917-1906/libbacktrace'
> gmake[2]: *** [all-stage1-libbacktrace] Error 2
> gmake[2]: Leaving directory `/scratch2/tmp/gerald/OBJ-0917-1906'
> gmake[1]: *** [stage1-bubble] Error 2
> gmake[1]: Leaving directory `/scratch2/tmp/gerald/OBJ-0917-1906'
> gmake: *** [bootstrap-lean] Error 2
>
>
> Tracked as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54611 .
>
>
> There are two different issues breaking the build here.
>
> The following patch, which I committed as obvious, addresses the second.
> Tested by ensuring the bootstrap on this platform is now only breaking
> due to the first item.

Sorry about that.  Fixed like so.  Committed to mainline.

Ian

2012-09-17  Ian Lance Taylor  

PR bootstrap/54611
* nounwind.c (backtrace_full): Rename from backtrace.  Add state
parameter.


foo.patch
Description: Binary data

Re: Backtrace library [1/3]

[Gerald Pfeifer]

On Mon, 17 Sep 2012, Ian Lance Taylor wrote:
> Please let me know about any build problems.

i386-unknown-freebsd10.0 now fails as follows.  Others presumably
have not run into this since "This source file is compiled if the
unwind library is not available".

/scratch2/tmp/gerald/gcc-HEAD/libbacktrace/nounwind.c:48: warning: no previous 
prototype for 'backtrace'
/scratch2/tmp/gerald/gcc-HEAD/libbacktrace/nounwind.c:59: error: conflicting 
types for 'backtrace_simple'
/scratch2/tmp/gerald/gcc-HEAD/libbacktrace/backtrace.h:130: error: previous 
declaration of 'backtrace_simple' was here
gmake[4]: *** [nounwind.lo] Error 1
gmake[4]: Leaving directory 
`/scratch2/tmp/gerald/OBJ-0917-1906/libbacktrace'
gmake[3]: *** [all] Error 2
gmake[3]: Leaving directory 
`/scratch2/tmp/gerald/OBJ-0917-1906/libbacktrace'
gmake[2]: *** [all-stage1-libbacktrace] Error 2 
gmake[2]: Leaving directory `/scratch2/tmp/gerald/OBJ-0917-1906' 
gmake[1]: *** [stage1-bubble] Error 2 
gmake[1]: Leaving directory `/scratch2/tmp/gerald/OBJ-0917-1906'
gmake: *** [bootstrap-lean] Error 2


Tracked as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54611 .


There are two different issues breaking the build here.

The following patch, which I committed as obvious, addresses the second.
Tested by ensuring the bootstrap on this platform is now only breaking
due to the first item.

2012-09-17  Gerald Pfeifer  

PR bootstrap/54611
* nounwind.c (backtrace_simple): Add state parameter.

Index: nounwind.c
===
--- nounwind.c  (revision 191404)
+++ nounwind.c  (working copy)
@@ -53,7 +53,8 @@
 }
 
 int
-backtrace_simple (int skip ATTRIBUTE_UNUSED,
+backtrace_simple (struct backtrace_state *state ATTRIBUTE_UNUSED,
+ int skip ATTRIBUTE_UNUSED,
  backtrace_simple_callback callback ATTRIBUTE_UNUSED,
  backtrace_error_callback error_callback, void *data)
 {


I'm running out of time now, but will check again later today or
tomorrow for the other item (hoping it'll been magically gone ;-).

Gerald

Re: [patch, mips] Patch for new mips triplet - mips-mti-elf

[Richard Sandiford]

Steve Ellcey  writes:
> On Sun, 2012-09-16 at 09:22 +0100, Richard Sandiford wrote:
>
>> > +/* This is idential to sde.h except for the ABI setting which defaults
>> > +   to 32 instead of n32 on 32 bit architectures and the addition of
>> > +   MIPS_ISA_SYNCI_SPEC.  */
>> 
>> SDE defaults to o32 (-mabi=32) for 32-bit targets and n32 for 64-bit targets.
>> I think that's what you'd want here too, otherwise the mips64 multilibs
>> are really no different from the mips32 ones.
>
> I am a bit confused about this.  It looks like the current
> mips-*-linux-gnu targets default to o32 when compiled for 64-bit targets
> but the mips-sde-elf target defaults to n32 when compiled for 64-bit
> targets.  I am not sure which default makes more sense but it seems odd
> that the two targets have different defaults for the same architecture.
> Do you know how the current state of affairs came to be with respect to
> this difference in defaults?

It's a hosted vs. embedded thing.  Hosted targets like *-linux-gnu have
dynamic ABI requirements and so are keyed off an ABI rather than an
architecture.  The only effect of -march= and --with-arch= should be to
extend the choice of available instructions.

That was actually very useful in pre MIPS(isa)32 and MIPS(isa)64 days,
because MIPS IV had ISA extensions that could be used in 32-bit as well
as 64-bit code.  You could therefore use the MIPS IV extensions with an
existing 32-bit MIPS I or MIPS II sysroot.  The same sort of thing applied
to processor-specific extensions in 64-bit processors (of which there were
many :-)).  It's less useful with the stock MIPS32 and MIPS64 ISAs because
the 32-bit subset of MIPS64 is (by design) essentially MIPS32.

In a hosted environment, if you want a 64-bit toolchain, you need
to use a 64-bit target like mips64-linux-gnu or mipsisa64-linux-gnu.
(Or configure mips-*-linux-gnu with --enable-targets=all and be
prepared to use -mabi=n32.)

In contrast, embedded *-elf targets have only static ABI requirements,
and the runtime libraries are usually built as part of the toolchain.
It's therefore convenient for -march= to select the "best" ABI for
the architecture.

Richard

Re: [PATCHv3] rs6000: Add 2 built-ins to read the Time Base Register on PowerPC

[David Edelsohn]

On Mon, Sep 17, 2012 at 8:53 AM, Tulio Magno Quites Machado Filho
 wrote:
> Add __builtin_ppc_get_timebase and __builtin_ppc_mftb to read the Time
> Base Register on PowerPC.
> They are required by applications that measure time at high frequencies
> with high precision that can't afford a syscall.
> __builtin_ppc_get_timebase returns the 64 bits of the Time Base Register
> while __builtin_ppc_mftb generates only 1 instruction and returns the
> least significant word on 32-bit environments and the whole Time Base value
> on 64-bit.
VSX Built-in Functions):
> Move some built-ins unrelated to Altivec/VSX to the new section.

This is a lot better and a lot closer.

> +(define_insn "rs6000_get_timebase_ppc32"
> +  [(set (match_operand:DI 0 "gpc_reg_operand" "=r")
> +(unspec_volatile:DI [(const_int 0)] UNSPECV_GETTB))
> +   (clobber (match_scratch:SI 1 "=r"))
> +   (clobber (match_scratch:CC 2 "=y"))]
> +  "!TARGET_POWERPC64"
> +{
> +  if (WORDS_BIG_ENDIAN)
> +if (TARGET_MFCRF)
> +  {
> +return "mfspr %0, 269\;"
> +  "mfspr %L0, 268\;"
> +  "mfspr %1, 269\;"
> +  "cmpw %0,%1\;"
> +  "bne- $-16";
> +  }
> +else
> +  {
> +return "mftbu %0\;"
> +  "mftb %L0\;"
> +  "mftbu %1\;"
> +  "cmpw %0,%1\;"
> +  "bne- $-16";
> +  }
> +  else
> +if (TARGET_MFCRF)
> +  {
> +return "mfspr %L0, 269\;"
> +  "mfspr %0, 268\;"
> +  "mfspr %1, 269\;"
> +  "cmpw %L0,%1\;"
> +  "bne- $-16";
> +  }
> +else
> +  {
> +return "mftbu %L0\;"
> +  "mftb %0\;"
> +  "mftbu %1\;"
> +  "cmpw %L0,%1\;"
> +  "bne- $-16";
> +  }
> +})

When Segher said to use "=y" for the condition register to generalize
the code so that it does not always allocate CR0, it also needs
reference the specific condition register field in the emitted
assembly.  You need to tell the processor which CR field the compiler
think is assigned and clobbered.

Thanks, David

Re: [DOC] Update -feliminate-unused-debug-types description

[Paul_Koning]

On Sep 17, 2012, at 1:20 PM, Ian Lance Taylor wrote:

> On Mon, Sep 17, 2012 at 8:59 AM,   wrote:
>> 
>> 2012-09-17  Paul Koning  
>> 
>>* doc/invoke.text (-feliminate-unused-debug-types): Update to
>>reflect that this is enabled by default.
> 
> This is OK.
> 
> Thanks.
> 
> Ian

Thanks.  Committed.

paul

Re: [Patch ARM] big-endian support for Neon vext tests

[Christophe Lyon]

On 17 September 2012 20:04, Richard Earnshaw  wrote:
> On 17/09/12 16:50, Christophe Lyon wrote:
>> On 17 September 2012 17:21, Richard Earnshaw  wrote:
>>> On 17/09/12 16:13, Christophe Lyon wrote:
 On 17 September 2012 14:56, Richard Earnshaw  wrote:
> On 05/09/12 23:14, Christophe Lyon wrote:
>> Hello,
>>
>> Although the recent optimization I have committed to use Neon vext
>> instruction for suitable builtin_shuffle calls does not support
>> big-endian yet, I have written a patch to the existing testcases such
>> they now support big-endian mode.
>>
>> I think it's worth improving these tests since writing the right masks
>> for big-endian (such that the program computes the same results as in
>> little-endian) is not always straightforward.
>>
>> In particular:
>> * I have added some comments in a few tests were it took me a while to
>> find the right mask.
>> * In the case of the test which is executed, I had to force the
>> noinline attribute on the helper functions, otherwise the computed
>> results are wrong in big-endian. It is probably an overkill workaround
>> but it works :-)
>>   I am going to file a bugzilla for this problem.
>>
>> I have checked that replacing calls to builtin_shuffle by the expected
>> Neon vext variant produces the expected results in big-endian mode,
>> and I arranged the big-endian masks to get the same results.
>>
>> Christophe.=
>>
>>
>> neon-vext-big-endian-tests.patch
>>
>>
>> N ¬n‡r¥ªíÂ)emçhÂyhi× ¢w^™©Ý
>>
>
>
> I'm not sure about this.  Looking at the documentation in the manual for
> builtin_suffle makes no mention of the results/behaviour being endian
> dependent, which makes me wonder why this test needs to be.
>
> R.


 Indeed, but I had to modify the mask value in order to get the same
 results in big and little-endian.

 If the mask should be the same (it would be much more confortable for
 the developers indeed), then GCC needs to be changed/fixed.

>>>
>>> That's what I'm trying to establish.  I suspect that there is a bug in
>>> GCC for all big-endian code here.
>>>
>>> What happens for a test of uint8x8_t?
>>>
>>
>> Well, in my sample testcase in little-endian, I used mask = {2, 3, 4,
>> 5, 6, 7, 8, 9}, which can be optimized into vext #2.
>>
>> In big-endian mode, explicitly forcing use of vext #2 leads to the
>> right result, but to achieve it using builtin_shuffle, I had to change
>> the mask into {14, 15, 0, 1, 2, 3, 4, 5}.
>>
>> I did read the thread starting at
>> http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01133.html and the
>> threads it references, and I must admit that I got a bit confused :-)
>>
>> IMHO, it's currently impossible for a GCC user to write code using
>> vector initializers that would be portable on big and little endian
>> targets. It's too much of a headache
>>
>> It was also a purpose of this patch: have someone react if it looked
>> inappropriate.
>>
>> Thanks for the review,
>>
>> Christophe.
>>
>
> I think for big-endian, __builtin_shuffle needs to expand to (for 64-bit
> vectors)
>
> vrev64. mask
> vext
>
> and for 128-bit vectors
>
> vrev64. mask
> vswap  mask, mask
> vext ...
>
> Obviously, if you've got a literal you can simplify the operations down
> to something that doesn't need the extra instructions.
>
> R.
>

Does this mean that the currently generated code is wrong (I mean when
no optimization is performed by the compiler, as it is currently the
case with GCC in big-endian) ?
When the input mask is known by the compiler, it generates a series a
moves to perform the shuffle operation.

Christophe.

Re: [Patch, fortran] PR46897 - [OOP] type-bound defined ASSIGNMENT(=) not used for derived type component in intrinsic assign

[Mikael Morin]

Hello,

On 10/09/2012 20:58, Paul Richard Thomas wrote:
> Dear All,
> 
> Please find attached a new attempt at the patch for PR46897.  It now
> uses temporaries to overcome the side effects that Mikael pointed out.

And here comes the next round of comments.


> Index: gcc/fortran/resolve.c
> ===
> *** gcc/fortran/resolve.c (revision 191115)
> --- gcc/fortran/resolve.c (working copy)
> *** resolve_ordinary_assign (gfc_code *code,
> *** 9516,9521 
> --- 9516,9791 
>   }
>   
>   
> + /* Add a component reference onto an expression.  */
> + 
> + static void
> + add_comp_ref (gfc_expr *e, gfc_component *c)
> + {
> +   gfc_ref **ref;
> +   ref = &(e->ref);
> +   while (*ref)
> + ref = &((*ref)->next);
> +   *ref = gfc_get_ref();
> +   (*ref)->type = REF_COMPONENT;
> +   (*ref)->u.c.sym = e->ts.u.derived;
> +   (*ref)->u.c.component = c;
> +   e->ts = c->ts;
> + 
> +   /* Add a full array ref, as necessary.  */
> +   e->rank = c && c->as ? c->as->rank : 0;
This is bogus if  e->rank was != 0 previously (think of the case
array(:)%scalar_comp).
The c == NULL case should be handled at the beginning (if at all).

> +   if (e->rank)
the condition should be on c->as (for the case array(:)%scalar_comp again).

> + gfc_add_full_array_ref (e, c->as);
> + }
> + 
> + 
> + /* Build an assignment.  */
> + 
> + static gfc_code *
> + build_assignment (gfc_exec_op op, gfc_expr *expr1, gfc_expr *expr2,
> +   gfc_component *comp1, gfc_component *comp2, locus loc)
> + {
> +   gfc_code *this_code;
> + 
> +   this_code = gfc_get_code ();
> +   this_code->op = op;
all calls are with op == EXEC_ASSIGN, you may as well hardcode it.

> +   this_code->next = NULL;
> +   this_code->expr1 = gfc_copy_expr (expr1);
> +   this_code->expr2 = gfc_copy_expr (expr2);
> +   this_code->loc = loc;
> +   if (comp1 && comp2)
> + {
> +   add_comp_ref (this_code->expr1, comp1);
> +   add_comp_ref (this_code->expr2, comp2);
> + }
> + 
> +   return this_code;
> + }
> + 
> + 
> + /* Makes a temporary variable expression based on the characteristics of
> +a given expression.  */
> + 
> + static gfc_expr*
> + get_temp_from_expr (gfc_expr *e, gfc_namespace *ns)
> + {
> +   static int serial = 0;
> +   char name[GFC_MAX_SYMBOL_LEN];
> +   gfc_symtree *tmp;
> +   gfc_ref *ref = NULL, *eref;
> + 
> +   gcc_assert (e->expr_type == EXPR_VARIABLE
> +   || e->expr_type == EXPR_FUNCTION);
As far as I know anything can be used, not only variables and functions.
The derived type cases are a bit specific but at least array/structure
constructors are missing.  There could be also typebound function calls
(I never know whether they are EXPR_FUNCTION or something else).

> +   sprintf (name, "da@%d", serial++);
> +   gfc_get_sym_tree (name, ns, &tmp, false);
> +   gfc_add_type (tmp->n.sym, &e->ts, NULL);
> + 
> +   for (eref = e->ref; eref; eref = eref->next)
> + if (eref->type == REF_COMPONENT)
> +   ref = eref;
> + 
> +   if (!ref)
> + {
> +   tmp->n.sym->attr = e->symtree->n.sym->attr;
> +   if (e->symtree->n.sym->as)
> + tmp->n.sym->as
> + = gfc_copy_array_spec (e->symtree->n.sym->as);
> + }
> +   else
> + {
> +   tmp->n.sym->attr = ref->u.c.component->attr;
> +   if (ref->u.c.component->as)
> + tmp->n.sym->as
> + = gfc_copy_array_spec (ref->u.c.component->as);
> + }
> + 
> +   gfc_set_sym_referenced (tmp->n.sym);
> +   gfc_add_flavor (&tmp->n.sym->attr, FL_VARIABLE, name, NULL);
> +   return gfc_lval_expr_from_sym (tmp->n.sym);
> + }
> + 
> + 
> + /* Add one line of code to the code chain, making sure that 'head' and
> +'tail' are appropriately updated.  */
> + 
> + static void
> + add_code_to_chain (gfc_code **this_code, gfc_code **head, gfc_code **tail)
> + {
> +   gcc_assert (this_code);
> +   if (*head == NULL)
> + *head = *tail = *this_code;
> +   else
> + *tail = gfc_append_code (*tail, *this_code);
> +   *this_code = NULL;
> + }
> + 
> + 
> + /* Implement 7.2.1.3 of the F08 standard:
> +"An intrinsic assignment where the variable is of derived type is
> +performed as if each component of the variable were assigned from the
> +corresponding component of expr using pointer assignment (7.2.2) for
> +each pointer component, defined assignment for each nonpointer
> +nonallocatable component of a type that has a type-bound defined
> +assignment consistent with the component, intrinsic assignment for
> +each other nonpointer nonallocatable component, ..." 
> + 
> +The pointer assignments are taken care of by the intrinsic
> +assignment of the structure itself.  This function recursively adds
> +defined assignments where required.
> + 
> +Since the lhs in a defined assignment can have intent INOUT, the code
> +to do this gets a bit messy.  In pseudo-code:
> + 
> +! Only call function lhs once.
> +  

Re: [PATCH] PR 53528 c++/ C++11 Generalized Attribute support

[Jason Merrill]

On 09/17/2012 11:35 AM, Dodji Seketeli wrote:

>And I wonder if we want to offer this as an optional warning for GNU

   attribute syntax.

What option would be used to control this optional feature?  Would
you accept this a separate patch?


Let's not worry about this for now.


+ found_attrs = true;


You don't need a separate found_attrs variable; you can just check 
whether attrs is set or not.  VEC_iterate sets the element pointer to 
NULL at the end of the vector.  You should also be able to share more of 
the code between the cases where you do or do not already have the 
appropriate namespace set up.



+static scoped_attributes_t*
+find_attribute_namespace (const char* ns)
+{
+  unsigned ix;
+  scoped_attributes_t *iter;
+
+  FOR_EACH_VEC_ELT (scoped_attributes_t, attributes_table, ix, iter)
+if (ns == iter->ns
+   || (iter->ns != NULL
+   && ns != NULL
+   && !strcmp (iter->ns, ns)))
+  {
+   if (iter->attribute_hash == 0)
+ iter->attribute_hash =
+   htab_create (200, hash_attr, eq_attr, NULL);
+   return VEC_index (scoped_attributes_t, attributes_table, ix);
+  }


Rather than write the code to search the table in two places, let's call 
this function from register_scoped_attributes.


You don't need to do another VEC_index since you already have the 
pointer you want in 'iter'.



+attributes_array_length (const struct attribute_spec *attributes_array)


Rather than calculate this first and then pass it to 
register_scoped_attributes, why not just have register_scoped_attributes 
stop at a null entry?



+  if (name_space->attribute_hash == NULL)
+   name_space->attribute_hash = htab_create (200, hash_attr, eq_attr, NULL);


Why do we need this both here and in find_attribute_namespace?


 }
+/*
+   If in c++-11, check if the c++-11 alignment constraint with respect


Need a blank line after the }.


+check_cxx_fundamental_alignment_constraints (tree node,


In this function it would be nice to print out the requested and
maximum alignments in the error.


Done.


I don't see that:


+  if (alignment_too_large_p)
+error ("requested alignment is too large");



This seems like a good change in general; I'd be inclined to drop the
check for C++11 syntax.  If there are multiple conflicting alignments
specified for a declaration, the only things that make sense are to
choose the largest alignment or give an error; the current behavior of
choosing the most recently-specified alignment is just broken.


Done.  I realized that I forgot to check for DECL_USER_ALIGNED there.
Fixed too.


I don't see this either:


+  else if (flags & ATTR_FLAG_CXX11
+  && DECL_ALIGN (decl) > (1U << i) * BITS_PER_UNIT)


Did you send me an old patch by mistake?

Jason

Re: [PATCH] Prevent cselib substitution of FP, SP, SFP

[Ahmad Sharif]

On Fri, Sep 14, 2012 at 9:39 AM, Carrot Wei  wrote:
>
> Hi Jakub
>
> I have run it on 4.6, it passes the following testing:
>
> x86-64 bootstrap
> x86-64 regression test
> regression test on arm qemu
>
> Is it OK for gcc4.6?
>
> Ahmad, is it OK for google/gcc-4_6/ and google/gcc-4_6-mobile ?

Yes, provided you build and run ChromeOS tests and there is no regression.

Re: [Patch ARM] big-endian support for Neon vext tests

[Richard Earnshaw]

On 17/09/12 16:50, Christophe Lyon wrote:
> On 17 September 2012 17:21, Richard Earnshaw  wrote:
>> On 17/09/12 16:13, Christophe Lyon wrote:
>>> On 17 September 2012 14:56, Richard Earnshaw  wrote:
 On 05/09/12 23:14, Christophe Lyon wrote:
> Hello,
>
> Although the recent optimization I have committed to use Neon vext
> instruction for suitable builtin_shuffle calls does not support
> big-endian yet, I have written a patch to the existing testcases such
> they now support big-endian mode.
>
> I think it's worth improving these tests since writing the right masks
> for big-endian (such that the program computes the same results as in
> little-endian) is not always straightforward.
>
> In particular:
> * I have added some comments in a few tests were it took me a while to
> find the right mask.
> * In the case of the test which is executed, I had to force the
> noinline attribute on the helper functions, otherwise the computed
> results are wrong in big-endian. It is probably an overkill workaround
> but it works :-)
>   I am going to file a bugzilla for this problem.
>
> I have checked that replacing calls to builtin_shuffle by the expected
> Neon vext variant produces the expected results in big-endian mode,
> and I arranged the big-endian masks to get the same results.
>
> Christophe.=
>
>
> neon-vext-big-endian-tests.patch
>
>
> N ¬n‡r¥ªíÂ)emçhÂyhi× ¢w^™©Ý
>


 I'm not sure about this.  Looking at the documentation in the manual for
 builtin_suffle makes no mention of the results/behaviour being endian
 dependent, which makes me wonder why this test needs to be.

 R.
>>>
>>>
>>> Indeed, but I had to modify the mask value in order to get the same
>>> results in big and little-endian.
>>>
>>> If the mask should be the same (it would be much more confortable for
>>> the developers indeed), then GCC needs to be changed/fixed.
>>>
>>
>> That's what I'm trying to establish.  I suspect that there is a bug in
>> GCC for all big-endian code here.
>>
>> What happens for a test of uint8x8_t?
>>
> 
> Well, in my sample testcase in little-endian, I used mask = {2, 3, 4,
> 5, 6, 7, 8, 9}, which can be optimized into vext #2.
> 
> In big-endian mode, explicitly forcing use of vext #2 leads to the
> right result, but to achieve it using builtin_shuffle, I had to change
> the mask into {14, 15, 0, 1, 2, 3, 4, 5}.
> 
> I did read the thread starting at
> http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01133.html and the
> threads it references, and I must admit that I got a bit confused :-)
> 
> IMHO, it's currently impossible for a GCC user to write code using
> vector initializers that would be portable on big and little endian
> targets. It's too much of a headache
> 
> It was also a purpose of this patch: have someone react if it looked
> inappropriate.
> 
> Thanks for the review,
> 
> Christophe.
> 

I think for big-endian, __builtin_shuffle needs to expand to (for 64-bit
vectors)

vrev64. mask
vext

and for 128-bit vectors

vrev64. mask
vswap  mask, mask
vext ...

Obviously, if you've got a literal you can simplify the operations down
to something that doesn't need the extra instructions.

R.

Re: [Patch, Fortran] PR54608 - fix SCAN/VERIFY simplification

[Steve Kargl]

On Mon, Sep 17, 2012 at 07:34:12PM +0200, Tobias Burnus wrote:
> gfortran shouldn't simplify SCAN/VERIFY if the BACK= argument is present 
> but not a constant.
> 
> Build and regtested on x86-64-linux.
> OK for the trunk?
> 

OK.

-- 
Steve

PATCH COMMITTED: Fix libbacktrace bootstrap on Darwin

[Ian Lance Taylor]

It didn't take long to find a build problem with libbacktrace.  I forgot
to back and retest the unknown cases after changing the way backtrace
state was handled.  This patch should fix bootstrap.  Tested on
x86_64-unknown-linux-gnu, which proves little since the file is not used
on that platform.  Committed to mainline.

Ian


2012-09-17  Ian Lance Taylor  

PR bootstrap/54609
* unknown.c (unknown_fileline): Add state parameter, remove
fileline_data parameter, name error_callback parameter.
(backtrace_initialize): Add state parameter.


Index: unknown.c
===
--- unknown.c	(revision 191397)
+++ unknown.c	(working copy)
@@ -40,9 +40,9 @@ POSSIBILITY OF SUCH DAMAGE.  */
 /* A trivial routine that always fails to find fileline data.  */
 
 static int
-unknown_fileline (void *fileline_data ATTRIBUTE_UNUSED,
+unknown_fileline (struct backtrace_state *state ATTRIBUTE_UNUSED,
 		  uintptr_t pc, backtrace_full_callback callback,
-		  backtrace_error_callback ATTRIBUTE_UNUSED,
+		  backtrace_error_callback error_callback ATTRIBUTE_UNUSED,
 		  void *data)
 
 {
@@ -53,12 +53,12 @@ unknown_fileline (void *fileline_data AT
debug info.  */
 
 int
-backtrace_initialize (int descriptor ATTRIBUTE_UNUSED,
+backtrace_initialize (struct backtrace_state *state ATTRIBUTE_UNUSED,
+		  int descriptor ATTRIBUTE_UNUSED,
 		  backtrace_error_callback error_callback ATTRIBUTE_UNUSED,
-		  void *data ATTRIBUTE_UNUSED, fileline *fileline_fn,
-		  void **fileline_data)
+		  void *data ATTRIBUTE_UNUSED, fileline *fileline_fn)
 {
+  state->fileline_data = NULL;
   *fileline_fn = unknown_fileline;
-  *fileline_data = NULL;
   return 1;
 }

[Patch, Fortran] PR54608 - fix SCAN/VERIFY simplification

[Tobias Burnus]

gfortran shouldn't simplify SCAN/VERIFY if the BACK= argument is present 
but not a constant.


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

Tobias
2012-09-17  Tobias Burnus  

	PR fortran/54608
	* simplify.c (gfc_simplify_scan, gfc_simplify_verify):
	Fix handling of BACK=variable.

2012-09-17  Tobias Burnus  

	PR fortran/54608
	* gfortran.dg/scan_2.f90

diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c
index 5aa2704..1c9dff2 100644
--- a/gcc/fortran/simplify.c
+++ b/gcc/fortran/simplify.c
@@ -5247,7 +5247,8 @@ gfc_simplify_scan (gfc_expr *e, gfc_expr *c, gfc_expr *b, gfc_expr *kind)
   if (k == -1)
 return &gfc_bad_expr;
 
-  if (e->expr_type != EXPR_CONSTANT || c->expr_type != EXPR_CONSTANT)
+  if (e->expr_type != EXPR_CONSTANT || c->expr_type != EXPR_CONSTANT
+  || ( b != NULL && b->expr_type !=  EXPR_CONSTANT))
 return NULL;
 
   if (b != NULL && b->value.logical != 0)
@@ -6335,7 +6336,8 @@ gfc_simplify_verify (gfc_expr *s, gfc_expr *set, gfc_expr *b, gfc_expr *kind)
   if (k == -1)
 return &gfc_bad_expr;
 
-  if (s->expr_type != EXPR_CONSTANT || set->expr_type != EXPR_CONSTANT)
+  if (s->expr_type != EXPR_CONSTANT || set->expr_type != EXPR_CONSTANT
+  || ( b != NULL && b->expr_type !=  EXPR_CONSTANT))
 return NULL;
 
   if (b != NULL && b->value.logical != 0)
--- /dev/null	2012-09-17 07:46:24.707708299 +0200
+++ gcc/gcc/testsuite/gfortran.dg/scan_2.f90	2012-09-17 18:10:31.0 +0200
@@ -0,0 +1,35 @@
+! { dg-do compile }
+! { dg-options "-fdump-tree-original" }
+!
+! PR fortran/54608
+!
+! Contributed by James Van Buskirk
+!
+module m1
+   implicit none
+   contains
+  subroutine s1(A)
+ logical A
+ integer iscan, iverify
+ character(7), parameter :: tf(2) = ['.FALSE.','.TRUE. ']
+
+ iscan = scan('AA','A',back=A)
+ iverify = verify('xx','A',back=A)
+ if (iscan /= 2 .or. iverify /= 2) call abort ()
+ print *, iverify, iscan
+! write(*,'(a)') 'SCAN test: A = '//trim(tf(iscan)) ! should print true
+! write(*,'(a)') 'VERIFY test: A = '//trim(tf(iverify)) ! should print true
+  end subroutine s1
+end module m1
+
+program p1
+   use m1
+   implicit none
+   logical B
+
+   call s1(.TRUE.)
+end program p1
+
+! { dg-final { scan-tree-dump-times "iscan = _gfortran_string_scan \\(2," 1 "original" } }
+! { dg-final { scan-tree-dump-times "iverify = _gfortran_string_verify \\(2," 1 "original" } }
+! { dg-final { cleanup-tree-dump "original" } }

Re: [patch] Fix PR rtl-optimization/54290

[Ulrich Weigand]

Eric Botcazou wrote:

> Reload 1 of insn #85 inherits the reload reg from reload 1 of insn #84, the
> bug being that the same reload reg is also used for reload 0 of insn #85.
> 
> This is supposed to work like so: the inheritance code in choose_reload_regs
> calls free_for_value_p with IGNORE_ADDRESS_RELOADS set to 1 to bypass the
> conflict with reload 0 because there is special code in the same function to
> discard reload 0 in this case:
> 
> /* If we can inherit a RELOAD_FOR_INPUT, or can use a
>reload_override_in, then we do not need its related
>RELOAD_FOR_INPUT_ADDRESS / RELOAD_FOR_INPADDR_ADDRESS reloads;
>likewise for other reload types.
>We handle this by removing a reload when its only replacement
>is mentioned in reload_in of the reload we are going to inherit.
>A special case are auto_inc expressions; even if the input is
>inherited, we still need the address for the output.  We can
>recognize them because they have RELOAD_OUT set to RELOAD_IN.
> If we succeeded removing some reload and we are doing a 
> preliminary
>pass just to remove such reloads, make another pass, since the
>removal of one reload might allow us to inherit another one.  */
> else if (rld[r].in
>  && rld[r].out != rld[r].in
>  && remove_address_replacements (rld[r].in) && pass)
>   pass = 2;
> 
> But it is called with rld[r].in equal to:
> (gdb) p debug_rtx(in_rtx)
>   (reg:SI 40 %f8 [orig:109 prephitmp.12 ] [109])
> 
> and the following replacement for reload 0:
> (gdb) p debug_rtx(*replacements[0].where)
>   (plus:SI (reg/f:SI 30 %fp)
> (const_int -6140 [0xe804]))
> 
> so loc_mentioned_in_p returns false and reload 0 isn't discarded.
> 
> The problem is that reload 0 is pushed because of SECONDARY_MEMORY_NEEDED,
> i.e. (reg:SI 40 %f8) is spilled to memory at the address
> (gdb) p debug_rtx(secondary_memlocs_elim[11][0])
>   (mem/c:SI (plus:SI (reg/f:SI 30 %fp)
> (const_int -6140 [0xe804])) [0 S4 A32])
> 
> and replacements[0].where above points to within this MEM instead of IN_RTX.

This analysis looks correct to me.

> The attached patch fixes the problem (on the 4.6 branch) by also invoking 
> remove_address_replacements on the result of get_secondary_mem if a secondary 
> memory is needed.  The condition to detect it has been copied from 
> push_reload 
> on the 4.6 branch, but it has already slightly changed on the mainline and 
> I'm 
> not sure how to adjust it.

It is unfortunate that we need to re-do the test over and over ... longer term
it might be better to add a predicate to directly *check* whether we decided we
needed a secondary memory slot for the operand.

In any case, the change in the condition you noticed was introduced by a recent
patch by Bernd: http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00171.html

It seems that we ought to use a similar test to what Bernd introduced in
gen_reload, that is, use the "replaced_subreg" routine on rld[r].in, check
whether the result is a hard register and use its REGNO_REG_CLASS.

Bernd, given that you worked on this recently, any other thoughts?

Bye,
Ulrich

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

Re: [PATCH] Add missing include file in Makefile

[Ian Lance Taylor]

On Mon, Sep 17, 2012 at 8:34 AM, Florian Weimer  wrote:
> The attached patch is required so that plug-ins can include gimple.h.  I
> tested that cfg-flags.def is actually installed after this change.

> -BASIC_BLOCK_H = basic-block.h $(PREDICT_H) $(VEC_H) $(FUNCTION_H) cfghooks.h
> +BASIC_BLOCK_H = basic-block.h $(PREDICT_H) $(VEC_H) $(FUNCTION_H) 
> cfg-flags.def cfghooks.h

Break the line with a continuation character before cfg-flags.def so
that it remains less than 80 columns.

This is OK with that change.

Thanks.

Ian

Re: [DOC] Update -feliminate-unused-debug-types description

[Ian Lance Taylor]

On Mon, Sep 17, 2012 at 8:59 AM,   wrote:
>
> 2012-09-17  Paul Koning  
>
> * doc/invoke.text (-feliminate-unused-debug-types): Update to
> reflect that this is enabled by default.

This is OK.

Thanks.

Ian

Re: [PATCH, ARM] Use vld1/vst1 to implement vec_set/vec_extract

[Ulrich Weigand]

Richard Earnshaw wrote:

> You confused me for a bit with the reference to "line numbers", but I
> think you must mean "lane numbers".

Indeed, sorry for the confusion.

> FTR, I see no reason why GCC would have problems with 64-bit vectors in
> big-endian mode, it's only 128-bit (and larger) vectors that pose a
> problem (ok, the HW numbers the lanes from the other end, but the
> transformation is trivial).

The transformation may be trivial, but it is not done (by the original
code) :-)  The problem is that, as I understand, "subpart" numbers used
as argument to "vec_select" are supposed to use the numbering that array
indexes in an in-memory array would have; this is different from the NEON
lane numbers in big-endian mode.  The existing neon_vst1_lane
pattern, however, directly uses a NEON lane number as "subpart" number.

This usually does not cause visible problems, since it does the same
both when expanding the pattern and when recognizing the pattern.
However, in theory, common middle-end code might also look at the
subpart numbers (e.g. during simplification), and it will assume
the standard ordering is used ...

All other code in neon.md *either* transforms the NEON lane numbers
into RTL subpart numbers and put those in vec_select etc. *or* uses
a NEON lane number unchanged as argument of an UNSPEC.  It was only
this one pattern that broke this rule.

> This is OK.

Checked in.

Thanks,
Ulrich

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

PATCH RFA: Print backtrace on ICE

[Ian Lance Taylor]

This patch to the diagnostic code uses the new backtrace library to
print a backtrace on an ICE.  For example, here is the output of a test
case I took from a C++ PR:

/home/iant/foo2.cc:6:6: internal compiler error: in cp_lexer_new_from_tokens, 
at cp/parser.c:638
0xec549f internal_error(char const*, ...)
../../trunk/gcc/diagnostic.c:1057
0xec3f53 fancy_abort(char const*, int, char const*)
../../trunk/gcc/diagnostic.c:
0x5ff78e cp_lexer_new_from_tokens
../../trunk/gcc/cp/parser.c:638
0x5ff78e cp_parser_push_lexer_for_tokens
../../trunk/gcc/cp/parser.c:3290
0x60ff40 cp_parser_late_parsing_for_member
../../trunk/gcc/cp/parser.c:21713
0x60ff40 cp_parser_class_specifier_1
../../trunk/gcc/cp/parser.c:18207
0x60ff40 cp_parser_class_specifier
../../trunk/gcc/cp/parser.c:18231
0x60ff40 cp_parser_type_specifier
../../trunk/gcc/cp/parser.c:13390
0x61c83d cp_parser_decl_specifier_seq
../../trunk/gcc/cp/parser.c:10731
0x628317 cp_parser_single_declaration
../../trunk/gcc/cp/parser.c:21313
0x6289c0 cp_parser_template_declaration_after_export
../../trunk/gcc/cp/parser.c:21198
0x62de39 cp_parser_declaration
../../trunk/gcc/cp/parser.c:10183
0x62c487 cp_parser_declaration_seq_opt
../../trunk/gcc/cp/parser.c:10105
0x62c762 cp_parser_translation_unit
../../trunk/gcc/cp/parser.c:3757
0x62c762 c_parse_file()
../../trunk/gcc/cp/parser.c:27557
0x72e4e4 c_common_parse_file()
../../trunk/gcc/c-family/c-opts.c:1138
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


Bootstrapped on x86_64-unknown-linux-gnu.  I didn't bother to run the
testsuite, since the code only changes when an ICE occurs anyhow.

OK for mainline?

Ian

gcc/:

2012-09-17  Ian Lance Taylor  

* diagnostic.c: Include "demangle.h" and "backtrace.h".
(bt_stop): New static array.
(bt_callback, bt_err_callback): New static functions.
(diagnostic_action_after_output): Call backtrace_full for DK_ICE.
* Makefile.in (BACKTRACE): New variable.
(BACKTRACEINC, LIBBACKTRACE): New variables.
(BACKTRACE_H): New variable.
(LIBDEPS, LIBS): Add $(LIBBACKTRACE).
(INCLUDES): Add $(BACKTRACEINC).
(diagnostic.o): Depend upon $(DEMANGLE_H) and $(BACKTRACE_H).

./:

2012-09-17  Ian Lance Taylor  

* Makefile.def: Make all-gcc depend on all-libbacktrace.
* Makefile.in: Rebuild.


Index: gcc/diagnostic.c
===
--- gcc/diagnostic.c	(revision 191393)
+++ gcc/diagnostic.c	(working copy)
@@ -27,8 +27,10 @@ along with GCC; see the file COPYING3.  
 #include "system.h"
 #include "coretypes.h"
 #include "version.h"
+#include "demangle.h"
 #include "input.h"
 #include "intl.h"
+#include "backtrace.h"
 #include "diagnostic.h"
 
 #define pedantic_warning_kind(DC)			\
@@ -296,6 +298,93 @@ diagnostic_show_locus (diagnostic_contex
   pp_set_prefix (context->printer, saved_prefix);
 }
 
+/* Functions at which to stop the backtrace print.  It's not
+   particularly helpful to print the callers of these functions.  */
+
+static const char * const bt_stop[] =
+{
+  "main",
+  "toplev_main",
+  "execute_one_pass",
+  "compile_file",
+};
+
+/* A callback function passed to the backtrace_full function.  */
+
+static int
+bt_callback (void *data, uintptr_t pc, const char *filename, int lineno,
+	 const char *function)
+{
+  int *pcount = (int *) data;
+
+  /* If we don't have any useful information, don't print
+ anything.  */
+  if (filename == NULL && function == NULL)
+return 0;
+
+  /* Print up to 20 functions.  We could make this a --param, but
+ since this is only for debugging just use a constant for now.  */
+  if (*pcount >= 20)
+{
+  /* Returning a non-zero value stops the backtrace.  */
+  return 1;
+}
+  ++*pcount;
+
+  char *alc = NULL;
+  if (function != NULL)
+{
+  char *str = cplus_demangle_v3 (function,
+ (DMGL_VERBOSE | DMGL_ANSI
+  | DMGL_GNU_V3 | DMGL_PARAMS));
+  if (str != NULL)
+	{
+	  alc = str;
+	  function = str;
+	}
+
+  for (size_t i = 0; i < ARRAY_SIZE (bt_stop); ++i)
+	{
+	  size_t len = strlen (bt_stop[i]);
+	  if (strncmp (function, bt_stop[i], len) == 0
+	  && (function[len] == '\0' || function[len] == '('))
+	{
+	  if (alc != NULL)
+		free (alc);
+	  /* Returning a non-zero value stops the backtrace.  */
+	  return 1;
+	}
+	}
+}
+
+  fprintf (stderr, "0x%lx %s\n\t%s:%d\n",
+	   pc,
+	   function == NULL ? "???" : function,
+	   filename == NULL ? "???" : filename,
+	   lineno);
+
+  if (alc != NULL)
+free (alc);
+
+  return 0;
+}
+
+/* A callback function passed to the backtrace_full function.  This is
+   called if backtrace_full has an error.  */
+
+static void
+bt_err_callback (void *data ATTRIBUTE_UNUSED, const char

Re: [PATCH] Rs6000 infrastructure cleanup (switches)

[Michael Meissner]

On Mon, Sep 17, 2012 at 09:21:09AM +0100, Iain Sandoe wrote:
> Hello Michael, 
> 
> On 12 Sep 2012, at 23:43, Michael Meissner wrote:
> 
> >  It would be nice to know if this doesn't break the other ppc
> > environments (AIX, Darwin) before I commit it.  Are there any problems with
> > this patch? 
> 
> For powerpc-darwin9, there are a couple of issues which I've hacked around to 
> get bootstrap to complete.
> 
> 1. In rs6000.h
> 
> Where there are TARGET_XXX macros set to zero and guarded by config-time 
> HAVE_AS_YYY (e.g. TARGET_POPCNTD, HAVE_AS_POPCNTD)
> This causes an error when the #define TARGET_POPCNTD OPTION_POPCNTD is parsed.

I think changing the #ifdef TARGET_XXX to #ifdef OPTION_XXX's is the right
thing.  I wish the opt*.awk scripts did not change TARGET_ to OPTION_
and MASK_ to OPTION_MASK_.  I had already made a similar change in
the update to the patches I was going to send out today, but I will check them
once again.

> For the sake of making progress, I just worked around these by moving the 
> guarded defines to where the OPTION_XXXs are equated -- I.E: 
> 
> #ifndef HAVE_AS_XXX
> #define TARGET_XXX 0
> #else
> #define TARGET_XXX OPTION_XXX
> #endif
> 
> likely, that's not the Right Solution, but it allowed me to get to the next 
> step -
> 
> 2. rs6000_misc_flags{,explicit} and rs6000_debug_flags{,explicit} are 
> declared as HOST_WIDE_INT which is 'long long' for this target.  This causes 
> fails on lines 1841, 1842, 1844 and 1846 in rs6000.c because of mismatched 
> format specifier and argument.  I just worked around this with a temporary 
> definition of a suitable format descriptor.

Ok.  Thanks.

> With these two hacks, bootstrap completes for all langs including Java, Ada 
> and ObjC++.
> I haven't done any formal reg-tests yet, but a selection of checks across the 
> board look reasonable so far.
> 
> If there is any other specific input that would be useful let me know - these 
> older platforms are somewhat slow for the full build/test cycle.

Not at the moment, let me try get a revised patch out there.

Thanks for doing the tests.

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

Re: [PATCH, ARM] Prefer vld1.64/vst1.64 over vldm/vstm

[Ulrich Weigand]

Richard Earnshaw wrote:
> On 14/09/12 19:02, Ulrich Weigand wrote:
> > * config/arm/arm.c (output_move_neon): Update comment.
> > Use vld1.64/vst1.64 instead of vldm/vstm where possible.
> > (neon_vector_mem_operand): Support double-word modes.
> > * config/arm/neon.md (*neon_mov VD): Call output_move_neon
> > instead of output_move_vfp.  Change constraint from Uv to Un.
> 
> You should use HARD_REGNO_NREGS rather than ARM_NUM_REGS (which is
> really intended only for core registers).
> 
> OK with that change.

I've now committed the following version of the patch.

Thanks,
Ulrich


2012-09-17  Ramana Radhakrishnan  
Ulrich Weigand  

* config/arm/arm.c (output_move_neon): Update comment.
Use vld1.64/vst1.64 instead of vldm/vstm where possible.
(neon_vector_mem_operand): Support double-word modes.
* config/arm/neon.md (*neon_mov VD): Call output_move_neon
instead of output_move_vfp.  Change constraint from Uv to Un.


Index: gcc-head/gcc/config/arm/arm.c
===
--- gcc-head.orig/gcc/config/arm/arm.c  2012-09-17 15:43:05.0 +0200
+++ gcc-head/gcc/config/arm/arm.c   2012-09-17 15:43:17.0 +0200
@@ -9629,7 +9629,11 @@ neon_vector_mem_operand (rtx op, int typ
   && REG_MODE_OK_FOR_BASE_P (XEXP (ind, 0), VOIDmode)
   && CONST_INT_P (XEXP (ind, 1))
   && INTVAL (XEXP (ind, 1)) > -1024
-  && INTVAL (XEXP (ind, 1)) < 1016
+  /* For quad modes, we restrict the constant offset to be slightly less
+than what the instruction format permits.  We have no such constraint
+on double mode offsets.  (This must match arm_legitimate_index_p.)  */
+  && (INTVAL (XEXP (ind, 1))
+ < (VALID_NEON_QREG_MODE (GET_MODE (op))? 1016 : 1024))
   && (INTVAL (XEXP (ind, 1)) & 3) == 0)
 return TRUE;
 
@@ -14573,15 +14577,16 @@ output_move_vfp (rtx *operands)
   return "";
 }
 
-/* Output a Neon quad-word load or store, or a load or store for
-   larger structure modes.
+/* Output a Neon double-word or quad-word load or store, or a load
+   or store for larger structure modes.
 
WARNING: The ordering of elements is weird in big-endian mode,
-   because we use VSTM, as required by the EABI.  GCC RTL defines
-   element ordering based on in-memory order.  This can be differ
-   from the architectural ordering of elements within a NEON register.
-   The intrinsics defined in arm_neon.h use the NEON register element
-   ordering, not the GCC RTL element ordering.
+   because the EABI requires that vectors stored in memory appear
+   as though they were stored by a VSTM, as required by the EABI.
+   GCC RTL defines element ordering based on in-memory order.
+   This can be different from the architectural ordering of elements
+   within a NEON register. The intrinsics defined in arm_neon.h use the
+   NEON register element ordering, not the GCC RTL element ordering.
 
For example, the in-memory ordering of a big-endian a quadword
vector with 16-bit elements when stored from register pair {d0,d1}
@@ -14595,13 +14600,28 @@ output_move_vfp (rtx *operands)
  dN -> (rN+1, rN), dN+1 -> (rN+3, rN+2)
 
So that STM/LDM can be used on vectors in ARM registers, and the
-   same memory layout will result as if VSTM/VLDM were used.  */
+   same memory layout will result as if VSTM/VLDM were used.
+
+   Instead of VSTM/VLDM we prefer to use VST1.64/VLD1.64 where
+   possible, which allows use of appropriate alignment tags.
+   Note that the choice of "64" is independent of the actual vector
+   element size; this size simply ensures that the behavior is
+   equivalent to VSTM/VLDM in both little-endian and big-endian mode.
+
+   Due to limitations of those instructions, use of VST1.64/VLD1.64
+   is not possible if:
+- the address contains PRE_DEC, or
+- the mode refers to more than 4 double-word registers
+
+   In those cases, it would be possible to replace VSTM/VLDM by a
+   sequence of instructions; this is not currently implemented since
+   this is not certain to actually improve performance.  */
 
 const char *
 output_move_neon (rtx *operands)
 {
   rtx reg, mem, addr, ops[2];
-  int regno, load = REG_P (operands[0]);
+  int regno, nregs, load = REG_P (operands[0]);
   const char *templ;
   char buff[50];
   enum machine_mode mode;
@@ -14613,6 +14633,7 @@ output_move_neon (rtx *operands)
 
   gcc_assert (REG_P (reg));
   regno = REGNO (reg);
+  nregs = HARD_REGNO_NREGS (regno, mode) / 2;
   gcc_assert (VFP_REGNO_OK_FOR_DOUBLE (regno)
  || NEON_REGNO_OK_FOR_QUAD (regno));
   gcc_assert (VALID_NEON_DREG_MODE (mode)
@@ -14629,13 +14650,23 @@ output_move_neon (rtx *operands)
   switch (GET_CODE (addr))
 {
 case POST_INC:
-  templ = "v%smia%%?\t%%0!, %%h1";
-  ops[0] = XEXP (addr, 0);
+  /* We have to use vldm / vstm for too-large modes.  */
+  if (nregs > 4)
+   {
+ templ = "v%

Re: [PATCH] Rs6000 infrastructure cleanup (switches)

[Michael Meissner]

On Sat, Sep 15, 2012 at 06:49:19PM +0200, Andreas Tobler wrote:
> Tested on powerpc64-freebsd10.0, results here:
> 
> http://gcc.gnu.org/ml/gcc-testresults/2012-09/msg01403.html
> 
> I ran the tests with and w/o patch. No diffs seen.

Great, thanks.

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

Re: Backtrace library [1/3]

[Ian Lance Taylor]

On Thu, Sep 13, 2012 at 1:00 PM, Diego Novillo  wrote:
> On 2012-09-11 18:53 , Ian Lance Taylor wrote:
>
>> 2012-09-11  Ian Lance Taylor  
>>
>> * Initial implementation.
>
> OK.

Thanks for all the reviews.  I have committed the libbacktrace library
to trunk.  I will follow up with a patch to actually use it.

Please let me know about any build problems.

Ian

[Patch,lto,committed]: Fix PR lto/54598

[Georg-Johann Lay]

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

Committed as preapproved in http://gcc.gnu.org/PR54598#c1

Johann


PR lto/54598
* tree-streamer-in.c (unpack_ts_real_cst_value_fields): Use ggc'ed
FIXED_VALUE_TYPE instead of struct fixed_value.


Index: tree-streamer-in.c
===
--- tree-streamer-in.c	(revision 191393)
+++ tree-streamer-in.c	(revision 191394)
@@ -172,12 +172,11 @@ unpack_ts_real_cst_value_fields (struct
 static void
 unpack_ts_fixed_cst_value_fields (struct bitpack_d *bp, tree expr)
 {
-  struct fixed_value fv;
-
-  fv.mode = bp_unpack_enum (bp, machine_mode, MAX_MACHINE_MODE);
-  fv.data.low = bp_unpack_var_len_int (bp);
-  fv.data.high = bp_unpack_var_len_int (bp);
-  TREE_FIXED_CST (expr) = fv;
+  FIXED_VALUE_TYPE *fp = ggc_alloc_fixed_value ();
+  fp->mode = bp_unpack_enum (bp, machine_mode, MAX_MACHINE_MODE);
+  fp->data.low = bp_unpack_var_len_int (bp);
+  fp->data.high = bp_unpack_var_len_int (bp);
+  TREE_FIXED_CST_PTR (expr) = fp;
 }
 
 

C++ PATCH for c++/53661 (wrong narrowing error with enum)

[Jason Merrill]

When determining whether a conversion from an unscoped enum is a 
narrowing conversion, we check whether the values of the enum fit into 
the target type.  [dcl.enum] defines the values of an enum with 
unspecified underlying type to be the values of the smallest bit-field 
that could hold it, not all the values representable in the size of the 
type.  This patch fixes that check.


Tested x86_64-pc-linux-gnu, applying to trunk and 4.7.
commit 373e79aaea9c5b73cebeb1e8fd4fedbdfd553a35
Author: Jason Merrill 
Date:   Fri Sep 14 09:48:48 2012 -0400

	PR c++/53661
	* typeck2.c (check_narrowing): Avoid false positives on conversion
	from enumeral type.

diff --git a/gcc/cp/typeck2.c b/gcc/cp/typeck2.c
index 6faebb5..58b2db6 100644
--- a/gcc/cp/typeck2.c
+++ b/gcc/cp/typeck2.c
@@ -787,6 +787,9 @@ check_narrowing (tree type, tree init)
   else if (INTEGRAL_OR_ENUMERATION_TYPE_P (ftype)
 	   && CP_INTEGRAL_TYPE_P (type))
 {
+  if (TREE_CODE (ftype) == ENUMERAL_TYPE)
+	/* Check for narrowing based on the values of the enumeration. */
+	ftype = ENUM_UNDERLYING_TYPE (ftype);
   if ((tree_int_cst_lt (TYPE_MAX_VALUE (type),
 			TYPE_MAX_VALUE (ftype))
 	   || tree_int_cst_lt (TYPE_MIN_VALUE (ftype),
diff --git a/gcc/testsuite/g++.dg/init/aggr9.C b/gcc/testsuite/g++.dg/init/aggr9.C
new file mode 100644
index 000..67d8299
--- /dev/null
+++ b/gcc/testsuite/g++.dg/init/aggr9.C
@@ -0,0 +1,9 @@
+// PR c++/53661
+
+enum Code {
+  SUCCESS = 0
+};
+
+Code a;
+
+int r[] = {a};

Re: [PATCH] PR other/54411: libiberty: objalloc_alloc integer overflows (CVE-2012-3509)

[Ian Lance Taylor]

On Mon, Sep 17, 2012 at 2:49 AM, Florian Weimer  wrote:
> On 09/05/2012 07:31 AM, Ian Lance Taylor wrote:
>>
>> On Wed, Aug 29, 2012 at 10:32 AM, Florian Weimer  wrote:
>>>
>>>
>>> This patches fixes an integer overflow in libiberty, which leads to
>>> crashes in binutils.  The long version of the objalloc_alloc macro
>>> would have needed another conditional, so I removed that and replaced
>>> it with a call to the actual implementation.
>>
>>
>> I guess I don't see why removing the macro is desirable.  In many uses
>> of objalloc_alloc the conditional can be optimized out anyhow.  It's
>> true that it can't always be, but, so what?  The macro is probably
>> still a win.
>
>
> Fair enough.  I've added a wraparound check to the macro.  Okay for trunk?

>  {
> +  unsigned long len = original_len;
>/* We avoid confusion from zero sized objects by always allocating
>   at least 1 byte.  */

Please add a blank line after the variable declaration.

> - (__len <= __o->current_space\
> + (__len && __len <= __o->current_space   \

Please write __len != 0 or len > 0.

This is OK with those changes.

Thanks.

Ian

[DOC] Update -feliminate-unused-debug-types description

[Paul_Koning]

Currently the description of -feliminate-unused-debug-types says that it is off 
by default.  In fact, it is on by default.  The attached patch corrects the 
documentation to reflect that.

Ok to commit?

paul

2012-09-17  Paul Koning  

* doc/invoke.text (-feliminate-unused-debug-types): Update to
reflect that this is enabled by default.

Index: invoke.texi
===
--- invoke.texi (revision 191393)
+++ invoke.texi (working copy)
@@ -324,7 +324,7 @@
 -fdump-tree-storeccp@r{[}-@var{n}@r{]} @gol
 -fdump-final-insns=@var{file} @gol
 -fcompare-debug@r{[}=@var{opts}@r{]}  -fcompare-debug-second @gol
--feliminate-dwarf2-dups -feliminate-unused-debug-types @gol
+-feliminate-dwarf2-dups -fno-eliminate-unused-debug-types @gol
 -feliminate-unused-debug-symbols -femit-class-debug-always @gol
 -fenable-@var{kind}-@var{pass} @gol
 -fenable-@var{kind}-@var{pass}=@var{range-list} @gol
@@ -6192,17 +6192,18 @@
 Print the compiler's built-in specs---and don't do anything else.  (This
 is used when GCC itself is being built.)  @xref{Spec Files}.
 
-@item -feliminate-unused-debug-types
+@item -fno-eliminate-unused-debug-types
 @opindex feliminate-unused-debug-types
-Normally, when producing DWARF 2 output, GCC emits debugging
+@opindex fno-eliminate-unused-debug-types
+Normally, when producing DWARF 2 output, GCC avoids producing debug symbol 
+output for types that are nowhere used in the source file being compiled.
+Sometimes it is useful to have GCC emit debugging
 information for all types declared in a compilation
 unit, regardless of whether or not they are actually used
-in that compilation unit.  Sometimes this is useful, such as
+in that compilation unit, for example 
 if, in the debugger, you want to cast a value to a type that is
 not actually used in your program (but is declared).  More often,
 however, this results in a significant amount of wasted space.
-With this option, GCC avoids producing debug symbol output
-for types that are nowhere used in the source file being compiled.
 @end table
 
 @node Optimize Options

Re: [Patch ARM] big-endian support for Neon vext tests

[Christophe Lyon]

On 17 September 2012 17:21, Richard Earnshaw  wrote:
> On 17/09/12 16:13, Christophe Lyon wrote:
>> On 17 September 2012 14:56, Richard Earnshaw  wrote:
>>> On 05/09/12 23:14, Christophe Lyon wrote:
 Hello,

 Although the recent optimization I have committed to use Neon vext
 instruction for suitable builtin_shuffle calls does not support
 big-endian yet, I have written a patch to the existing testcases such
 they now support big-endian mode.

 I think it's worth improving these tests since writing the right masks
 for big-endian (such that the program computes the same results as in
 little-endian) is not always straightforward.

 In particular:
 * I have added some comments in a few tests were it took me a while to
 find the right mask.
 * In the case of the test which is executed, I had to force the
 noinline attribute on the helper functions, otherwise the computed
 results are wrong in big-endian. It is probably an overkill workaround
 but it works :-)
   I am going to file a bugzilla for this problem.

 I have checked that replacing calls to builtin_shuffle by the expected
 Neon vext variant produces the expected results in big-endian mode,
 and I arranged the big-endian masks to get the same results.

 Christophe.=


 neon-vext-big-endian-tests.patch


 N ¬n‡r¥ªíÂ)emçhÂyhi× ¢w^™©Ý

>>>
>>>
>>> I'm not sure about this.  Looking at the documentation in the manual for
>>> builtin_suffle makes no mention of the results/behaviour being endian
>>> dependent, which makes me wonder why this test needs to be.
>>>
>>> R.
>>
>>
>> Indeed, but I had to modify the mask value in order to get the same
>> results in big and little-endian.
>>
>> If the mask should be the same (it would be much more confortable for
>> the developers indeed), then GCC needs to be changed/fixed.
>>
>
> That's what I'm trying to establish.  I suspect that there is a bug in
> GCC for all big-endian code here.
>
> What happens for a test of uint8x8_t?
>

Well, in my sample testcase in little-endian, I used mask = {2, 3, 4,
5, 6, 7, 8, 9}, which can be optimized into vext #2.

In big-endian mode, explicitly forcing use of vext #2 leads to the
right result, but to achieve it using builtin_shuffle, I had to change
the mask into {14, 15, 0, 1, 2, 3, 4, 5}.

I did read the thread starting at
http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01133.html and the
threads it references, and I must admit that I got a bit confused :-)

IMHO, it's currently impossible for a GCC user to write code using
vector initializers that would be portable on big and little endian
targets. It's too much of a headache

It was also a purpose of this patch: have someone react if it looked
inappropriate.

Thanks for the review,

Christophe.

Re: [patch, mips] Patch for new mips triplet - mips-mti-elf

[Steve Ellcey]

On Sun, 2012-09-16 at 09:22 +0100, Richard Sandiford wrote:

> > +/* This is idential to sde.h except for the ABI setting which defaults
> > +   to 32 instead of n32 on 32 bit architectures and the addition of
> > +   MIPS_ISA_SYNCI_SPEC.  */
> 
> SDE defaults to o32 (-mabi=32) for 32-bit targets and n32 for 64-bit targets.
> I think that's what you'd want here too, otherwise the mips64 multilibs
> are really no different from the mips32 ones.

I am a bit confused about this.  It looks like the current
mips-*-linux-gnu targets default to o32 when compiled for 64-bit targets
but the mips-sde-elf target defaults to n32 when compiled for 64-bit
targets.  I am not sure which default makes more sense but it seems odd
that the two targets have different defaults for the same architecture.
Do you know how the current state of affairs came to be with respect to
this difference in defaults?

Steve Ellcey
sell...@mips.com

[Patch,avr,committed]: Tidy up CONST_FIXED_P usage.

[Georg-Johann Lay]

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

Committed as obvious.

CONST_FIXED_P is promoted to rtl.h now.

Johann


* config/avr/avr.c (CONST_FIXED_P): Remove define.
* config/avr/avr.md (add3): Use CONST_FIXED_P.



Index: config/avr/avr.md
===
--- config/avr/avr.md   (revision 191392)
+++ config/avr/avr.md   (working copy)
@@ -1132,7 +1132,7 @@ (define_expand "add3"
   }
   }

-if (CONST_FIXED == GET_CODE (operands[2]))
+if (CONST_FIXED_P (operands[2]))
   {
 emit_insn (gen_add3_clobber (operands[0], operands[1],
operands[2]));
 DONE;
Index: config/avr/avr.c
===
--- config/avr/avr.c(revision 191392)
+++ config/avr/avr.c(working copy)
@@ -49,10 +49,6 @@
 #include "params.h"
 #include "df.h"

-#ifndef CONST_FIXED_P
-#define CONST_FIXED_P(X) (CONST_FIXED == GET_CODE (X))
-#endif
-
 /* Maximal allowed offset for an address in the LD command */
 #define MAX_LD_OFFSET(MODE) (64 - (signed)GET_MODE_SIZE (MODE))



Richard Guenther wrote:
> Georg-Johann Lay wrote:
>> The subject says it all:
>>
>> Add CONST_FIXED_P predicate macro similar to CONST_INT_P to rtl.h.
>>
>> Currently, CONST_FIXED_P is not used in the compiler, except in avr.c that 
>> does
>>
>> #ifndef CONST_FIXED_P
>> #define CONST_FIXED_P(X) (CONST_FIXED == GET_CODE (X))
>> #endif
>>
>> Ok for trunk?
> 
> Ok.
> 
> Thanks,
> Richard.
> 
>> If this change is fine, I'll clean up the avr BE in a separate change.
>>
>> Johann
>>
>> * rtl.h (CONST_FIXED_P): New predicate macro.
>>

[AArch64] Merge from upstream trunk r191370

[Sofiane Naci]

Hi,

I have just merged upstream trunk on the aarch64-branch up to r191370.

Thanks
Sofiane

[PATCH] Add missing include file in Makefile

[Florian Weimer]

The attached patch is required so that plug-ins can include gimple.h.  I 
tested that cfg-flags.def is actually installed after this change.


Okay for trunk?

--
Florian Weimer / Red Hat Product Security Team
2012-09-17  Florian Weimer  

	* Makefile.in (BASIC_BLOCK_H): Add cfg-flags.def.

Index: gcc/Makefile.in
===
--- gcc/Makefile.in	(revision 191378)
+++ gcc/Makefile.in	(working copy)
@@ -851,7 +851,7 @@
 	double-int.h alias.h $(SYMTAB_H) $(FLAGS_H) vecir.h \
 	$(REAL_H) $(FIXED_VALUE_H)
 REGSET_H = regset.h $(BITMAP_H) hard-reg-set.h
-BASIC_BLOCK_H = basic-block.h $(PREDICT_H) $(VEC_H) $(FUNCTION_H) cfghooks.h
+BASIC_BLOCK_H = basic-block.h $(PREDICT_H) $(VEC_H) $(FUNCTION_H) cfg-flags.def cfghooks.h
 GIMPLE_H = gimple.h gimple.def gsstruct.def pointer-set.h $(VEC_H) \
 	vecir.h $(GGC_H) $(BASIC_BLOCK_H) $(TREE_H) tree-ssa-operands.h \
 	tree-ssa-alias.h $(INTERNAL_FN_H)

Re: [Patch ARM] big-endian support for Neon vext tests

[Richard Earnshaw]

On 17/09/12 16:13, Christophe Lyon wrote:
> On 17 September 2012 14:56, Richard Earnshaw  wrote:
>> On 05/09/12 23:14, Christophe Lyon wrote:
>>> Hello,
>>>
>>> Although the recent optimization I have committed to use Neon vext
>>> instruction for suitable builtin_shuffle calls does not support
>>> big-endian yet, I have written a patch to the existing testcases such
>>> they now support big-endian mode.
>>>
>>> I think it's worth improving these tests since writing the right masks
>>> for big-endian (such that the program computes the same results as in
>>> little-endian) is not always straightforward.
>>>
>>> In particular:
>>> * I have added some comments in a few tests were it took me a while to
>>> find the right mask.
>>> * In the case of the test which is executed, I had to force the
>>> noinline attribute on the helper functions, otherwise the computed
>>> results are wrong in big-endian. It is probably an overkill workaround
>>> but it works :-)
>>>   I am going to file a bugzilla for this problem.
>>>
>>> I have checked that replacing calls to builtin_shuffle by the expected
>>> Neon vext variant produces the expected results in big-endian mode,
>>> and I arranged the big-endian masks to get the same results.
>>>
>>> Christophe.=
>>>
>>>
>>> neon-vext-big-endian-tests.patch
>>>
>>>
>>> N ¬n‡r¥ªíÂ)emçhÂyhi× ¢w^™©Ý
>>>
>>
>>
>> I'm not sure about this.  Looking at the documentation in the manual for
>> builtin_suffle makes no mention of the results/behaviour being endian
>> dependent, which makes me wonder why this test needs to be.
>>
>> R.
> 
> 
> Indeed, but I had to modify the mask value in order to get the same
> results in big and little-endian.
> 
> If the mask should be the same (it would be much more confortable for
> the developers indeed), then GCC needs to be changed/fixed.
> 

That's what I'm trying to establish.  I suspect that there is a bug in
GCC for all big-endian code here.

What happens for a test of uint8x8_t?

R.

> Christophe.
> 

Re: [Patch ARM] big-endian support for Neon vext tests

[Christophe Lyon]

On 17 September 2012 14:56, Richard Earnshaw  wrote:
> On 05/09/12 23:14, Christophe Lyon wrote:
>> Hello,
>>
>> Although the recent optimization I have committed to use Neon vext
>> instruction for suitable builtin_shuffle calls does not support
>> big-endian yet, I have written a patch to the existing testcases such
>> they now support big-endian mode.
>>
>> I think it's worth improving these tests since writing the right masks
>> for big-endian (such that the program computes the same results as in
>> little-endian) is not always straightforward.
>>
>> In particular:
>> * I have added some comments in a few tests were it took me a while to
>> find the right mask.
>> * In the case of the test which is executed, I had to force the
>> noinline attribute on the helper functions, otherwise the computed
>> results are wrong in big-endian. It is probably an overkill workaround
>> but it works :-)
>>   I am going to file a bugzilla for this problem.
>>
>> I have checked that replacing calls to builtin_shuffle by the expected
>> Neon vext variant produces the expected results in big-endian mode,
>> and I arranged the big-endian masks to get the same results.
>>
>> Christophe.=
>>
>>
>> neon-vext-big-endian-tests.patch
>>
>>
>> N ¬n‡r¥ªíÂ)emçhÂyhi× ¢w^™©Ý
>>
>
>
> I'm not sure about this.  Looking at the documentation in the manual for
> builtin_suffle makes no mention of the results/behaviour being endian
> dependent, which makes me wonder why this test needs to be.
>
> R.


Indeed, but I had to modify the mask value in order to get the same
results in big and little-endian.

If the mask should be the same (it would be much more confortable for
the developers indeed), then GCC needs to be changed/fixed.

Christophe.

Re: Decltype and opaque vectors

[Jason Merrill]

On 09/15/2012 09:01 AM, Marc Glisse wrote:

+ /* For vector types, pick a non-opaque variant.  */
+ if (TREE_CODE (type) == VECTOR_TYPE)
+   type = cp_build_qualified_type (TYPE_MAIN_VARIANT (type),
+   cp_type_quals (type));



I believe that template type deduction drops opacity by calling 
strip_typedefs, which also preserves type attributes.  So I think let's 
use it here as well.  OK with that change.


Jason

Re: [PATCH, AArch64] Implement ffs standard pattern

[Richard Earnshaw]

On 17/09/12 15:18, Ian Bolton wrote:
> OK for aarch64-4.7-branch as well?
> 

yes.

R.

>> -Original Message-
>> From: Richard Earnshaw
>> Sent: 14 September 2012 18:31
>> To: Ian Bolton
>> Cc: gcc-patches@gcc.gnu.org
>> Subject: Re: [PATCH, AArch64] Implement ffs standard pattern
>>
>> On 14/09/12 16:26, Ian Bolton wrote:
>>> I've implemented the standard pattern ffs, which leads to
>>> __builtin_ffs being generated with 4 instructions instead
>>> of 5 instructions.
>>>
>>> Regression tests and my new test pass.
>>>
>>> OK to commit?
>>>
>>>
>>> Cheers,
>>> Ian
>>>
>>>
>>>
>>> 2012-09-14  Ian Bolton  
>>>
>>> gcc/
>>> * config/aarch64/aarch64.md (csinc3): Make it into a
>>> named pattern.
>>> * config/aarch64/aarch64.md (ffs2): New pattern.
>>>
>>> testsuite/
>>>
>>> * gcc.target/aarch64/ffs.c: New test.
>>>
>>
>> OK.
>>
>> R.
> 
> 

Re: [PATCH, AArch64] Implement fnma, fms and fnms standard patterns

[Richard Earnshaw]

On 17/09/12 15:12, Ian Bolton wrote:
> OK for 4.7 as well?
> 

NO! But it is ok for the aarch64 branch of 4.7 :-)

R.

>> -Original Message-
>> From: Richard Earnshaw
>> Sent: 14 September 2012 18:18
>> To: Ian Bolton
>> Cc: gcc-patches@gcc.gnu.org
>> Subject: Re: [PATCH, AArch64] Implement fnma, fms and fnms standard
>> patterns
>>
>> On 14/09/12 18:05, Ian Bolton wrote:
>>> The following standard pattern names were implemented by simply
>>> renaming some existing patterns:
>>>
>>> * fnma
>>> * fms
>>> * fnms
>>>
>>> I have added an extra pattern for when we don't care about
>>> signed zero, so we can do "-fma (a,b,c)" more efficiently.
>>>
>>> Regression testing all passed.
>>>
>>> OK to commit?
>>>
>>> Cheers,
>>> Ian
>>>
>>>
>>> 2012-09-14  Ian Bolton  
>>>
>>> gcc/
>>> * config/aarch64/aarch64.md (fmsub4): Renamed
>>> to fnma4.
>>> * config/aarch64/aarch64.md (fnmsub4): Renamed
>>> to fms4.
>>> * config/aarch64/aarch64.md (fnmadd4): Renamed
>>> to fnms4.
>>> * config/aarch64/aarch64.md (*fnmadd4): New pattern.
>>>
>>> testsuite/
>>> * gcc.target/aarch64/fmadd.c: Added extra tests.
>>> * gcc.target/aarch64/fnmadd-fastmath.c: New test.
>>>
>>
>> OK.
>>
>> R.
> 
> 

RE: [PATCH, AArch64] Implement ffs standard pattern

[Ian Bolton]

OK for aarch64-4.7-branch as well?

> -Original Message-
> From: Richard Earnshaw
> Sent: 14 September 2012 18:31
> To: Ian Bolton
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH, AArch64] Implement ffs standard pattern
> 
> On 14/09/12 16:26, Ian Bolton wrote:
> > I've implemented the standard pattern ffs, which leads to
> > __builtin_ffs being generated with 4 instructions instead
> > of 5 instructions.
> >
> > Regression tests and my new test pass.
> >
> > OK to commit?
> >
> >
> > Cheers,
> > Ian
> >
> >
> >
> > 2012-09-14  Ian Bolton  
> >
> > gcc/
> > * config/aarch64/aarch64.md (csinc3): Make it into a
> > named pattern.
> > * config/aarch64/aarch64.md (ffs2): New pattern.
> >
> > testsuite/
> >
> > * gcc.target/aarch64/ffs.c: New test.
> >
> 
> OK.
> 
> R.

RE: [PATCH, AArch64] Implement fnma, fms and fnms standard patterns

[Ian Bolton]

OK for 4.7 as well?

> -Original Message-
> From: Richard Earnshaw
> Sent: 14 September 2012 18:18
> To: Ian Bolton
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH, AArch64] Implement fnma, fms and fnms standard
> patterns
> 
> On 14/09/12 18:05, Ian Bolton wrote:
> > The following standard pattern names were implemented by simply
> > renaming some existing patterns:
> >
> > * fnma
> > * fms
> > * fnms
> >
> > I have added an extra pattern for when we don't care about
> > signed zero, so we can do "-fma (a,b,c)" more efficiently.
> >
> > Regression testing all passed.
> >
> > OK to commit?
> >
> > Cheers,
> > Ian
> >
> >
> > 2012-09-14  Ian Bolton  
> >
> > gcc/
> > * config/aarch64/aarch64.md (fmsub4): Renamed
> > to fnma4.
> > * config/aarch64/aarch64.md (fnmsub4): Renamed
> > to fms4.
> > * config/aarch64/aarch64.md (fnmadd4): Renamed
> > to fnms4.
> > * config/aarch64/aarch64.md (*fnmadd4): New pattern.
> >
> > testsuite/
> > * gcc.target/aarch64/fmadd.c: Added extra tests.
> > * gcc.target/aarch64/fnmadd-fastmath.c: New test.
> >
> 
> OK.
> 
> R.

Re: [PATCH][RFC] Use overloads for gimple_build_assign_with_ops

[Richard Guenther]

On Mon, 17 Sep 2012, Diego Novillo wrote:

> On 2012-09-17 09:25 , Richard Guenther wrote:
> > 
> > This makes use of the new builtin functions for FILE, LINE and FUNCTION
> > to turn gimple_build_assign_with_ops/gimple_build_assign_with_ops3 into
> > two overloads of gimple_build_assign_with_ops (in theory the _stats
> > function can go and we could move the inlines to gimple.c instead,
> > eventually removing the assert and simply calling the 3-op overload
> > from the 2-op overload?)
> 
> Sounds like a good next step, yes.
> 
> > The patch merely serves as an example on how to transform mem-stat
> > code to non-macros.
> > 
> > Quickly build-tested with --disable-gather-detailed-mem-stats,
> > stage1 with --enable-gather-detailed-mem-stats and host GCC 4.6
> > prints
> > 
> > gimple.h:766 ((null)) 112: 0.0%
> > 0: 0.0%  0: 0.0%  0: 0.0%
> > 
> > for a former gimple_build_assign_with_ops3 call, stage2 (or stage1
> > with a GCC 4.8 host compiler) prints
> > 
> > tree-ssa-math-opts.c:2610 (convert_mult_to_fma) 112: 0.0%
> > 0: 0.0%  0: 0.0%  0: 0.0%  1
> > 
> > so it effectively cripples -fmem-report when not compiled with
> > a compiler supporting the builtins.
> 
> But for a bootstrapped 4.8+ compiler, this won't matter, right?  It's only
> when using a host compiler that doesn't support the builtins.

Yes.  Though as it's mostly used for development in which case
non-bootstrapped compilers are used it makes 
--enable-gather-detailed-mem-stats less useful unless you know of
this fact.  It will also actively break installed pre-release 4.8
compilers used as host compilers ...

> > Any comments/objections?
> 
> Looks good to me.  Thanks.

Thanks, currently bootstrapping / reg-testing on x86_64-unknown-linux-gnu,
I'll apply it tomorrow.

Richard.

Re: [PATCH][RFC] Use overloads for gimple_build_assign_with_ops

[Diego Novillo]

On 2012-09-17 09:25 , Richard Guenther wrote:


This makes use of the new builtin functions for FILE, LINE and FUNCTION
to turn gimple_build_assign_with_ops/gimple_build_assign_with_ops3 into
two overloads of gimple_build_assign_with_ops (in theory the _stats
function can go and we could move the inlines to gimple.c instead,
eventually removing the assert and simply calling the 3-op overload
from the 2-op overload?)


Sounds like a good next step, yes.


The patch merely serves as an example on how to transform mem-stat
code to non-macros.

Quickly build-tested with --disable-gather-detailed-mem-stats,
stage1 with --enable-gather-detailed-mem-stats and host GCC 4.6
prints

gimple.h:766 ((null)) 112: 0.0%
0: 0.0%  0: 0.0%  0: 0.0%

for a former gimple_build_assign_with_ops3 call, stage2 (or stage1
with a GCC 4.8 host compiler) prints

tree-ssa-math-opts.c:2610 (convert_mult_to_fma) 112: 0.0%
0: 0.0%  0: 0.0%  0: 0.0%  1

so it effectively cripples -fmem-report when not compiled with
a compiler supporting the builtins.


But for a bootstrapped 4.8+ compiler, this won't matter, right?  It's 
only when using a host compiler that doesn't support the builtins.



Any comments/objections?


Looks good to me.  Thanks.


Diego.

[PATCH][RFC] Use overloads for gimple_build_assign_with_ops

[Richard Guenther]

This makes use of the new builtin functions for FILE, LINE and FUNCTION
to turn gimple_build_assign_with_ops/gimple_build_assign_with_ops3 into
two overloads of gimple_build_assign_with_ops (in theory the _stats
function can go and we could move the inlines to gimple.c instead,
eventually removing the assert and simply calling the 3-op overload
from the 2-op overload?)

The patch merely serves as an example on how to transform mem-stat
code to non-macros.

Quickly build-tested with --disable-gather-detailed-mem-stats,
stage1 with --enable-gather-detailed-mem-stats and host GCC 4.6
prints

gimple.h:766 ((null)) 112: 0.0% 
 
0: 0.0%  0: 0.0%  0: 0.0% 

for a former gimple_build_assign_with_ops3 call, stage2 (or stage1
with a GCC 4.8 host compiler) prints

tree-ssa-math-opts.c:2610 (convert_mult_to_fma) 112: 0.0%  
0: 0.0%  0: 0.0%  0: 0.0%  1

so it effectively cripples -fmem-report when not compiled with
a compiler supporting the builtins.

Any comments/objections?

Thanks,
Richard.

2012-09-17  Richard Guenther  

* statistics.h (CXX_MEM_STAT_INFO): New define.
* gimple.h (gimple_build_assign_with_ops): Turn into an
overload of the inline function gimple_build_assign_with_ops.
(gimple_build_assign_with_ops3): Likewise.
* tree-ssa-loop-im.c (move_computations_stmt): Adjust.
* tree-ssa-math-opts.c (convert_mult_to_fma): Likewise.
* tree-vect-data-refs.c (vect_permute_store_chain): Likewise.
(vect_permute_load_chain): Likewise.
* tree-vect-generic.c (expand_vector_divmod): Likewise.
* tree-vect-patterns.c (vect_recog_dot_prod_pattern): Likewise.
(vect_recog_divmod_pattern): Likewise.
(vect_recog_mixed_size_cond_pattern): Likewise.
(adjust_bool_pattern): Likewise.
* tree-vect-slp.c (vect_create_mask_and_perm): Likewise.
* tree-vect-stmts.c (vectorizable_operation): Likewise.
(permute_vec_elements): Likewise.
(vectorizable_load): Likewise.

Index: trunk/gcc/gimple.h
===
*** trunk.orig/gcc/gimple.h 2012-09-11 12:25:21.0 +0200
--- trunk/gcc/gimple.h  2012-09-17 15:02:10.727065806 +0200
*** gimple gimple_build_assign_stat (tree, t
*** 744,755 
  
  void extract_ops_from_tree_1 (tree, enum tree_code *, tree *, tree *, tree *);
  
  gimple gimple_build_assign_with_ops_stat (enum tree_code, tree, tree,
  tree, tree MEM_STAT_DECL);
! #define gimple_build_assign_with_ops(c,o1,o2,o3)  \
!   gimple_build_assign_with_ops_stat (c, o1, o2, o3, NULL_TREE MEM_STAT_INFO)
! #define gimple_build_assign_with_ops3(c,o1,o2,o3,o4)  \
!   gimple_build_assign_with_ops_stat (c, o1, o2, o3, o4 MEM_STAT_INFO)
  
  gimple gimple_build_debug_bind_stat (tree, tree, gimple MEM_STAT_DECL);
  #define gimple_build_debug_bind(var,val,stmt) \
--- 744,774 
  
  void extract_ops_from_tree_1 (tree, enum tree_code *, tree *, tree *, tree *);
  
+ inline enum gimple_rhs_class get_gimple_rhs_class (enum tree_code);
  gimple gimple_build_assign_with_ops_stat (enum tree_code, tree, tree,
  tree, tree MEM_STAT_DECL);
! 
! inline gimple
! gimple_build_assign_with_ops (enum tree_code code, tree lhs,
! tree op1, tree op2 CXX_MEM_STAT_INFO)
! {
!   return gimple_build_assign_with_ops_stat (code, lhs,
!   op1, op2, NULL_TREE PASS_MEM_STAT);
! }
! 
! /* Build and return a GIMPLE assignment statement assigning CODE applied
!to OP1, OP2 and OP3 to LHS.
!CODE, OP1, OP2 and OP3 should be appropriate for a GIMPLE_TERNARY_RHS
!assign.  */
! 
! inline gimple
! gimple_build_assign_with_ops (enum tree_code code, tree lhs,
! tree op1, tree op2, tree op3 CXX_MEM_STAT_INFO)
! {
!   gcc_checking_assert (get_gimple_rhs_class (code) == GIMPLE_TERNARY_RHS);
!   return gimple_build_assign_with_ops_stat (code, lhs,
!   op1, op2, op3 PASS_MEM_STAT);
! }
  
  gimple gimple_build_debug_bind_stat (tree, tree, gimple MEM_STAT_DECL);
  #define gimple_build_debug_bind(var,val,stmt) \
*** is_gimple_assign (const_gimple gs)
*** 1811,1817 
  /* Determine if expression CODE is one of the valid expressions that can
 be used on the RHS of GIMPLE assignments.  */
  
! static inline enum gimple_rhs_class
  get_gimple_rhs_class (enum tree_code code)
  {
return (enum gimple_rhs_class) gimple_rhs_class_table[(int) code];
--- 1830,1836 
  /* Determine if expression CODE is one of the valid expressions that can
 be used on the RHS of GIMPLE assignments.  */
  
! inline enum gimple_rhs_class
  get_gimple_rhs_class (enum tree_code code)
  {

Re: [PATCH] Changes in mode switching

[Vladimir Yakovlev]

> Looks OK to me, though I have no authority to approve it
> except SH specific part.

Is there any more comments? Can it be committed in trank?

Regards,
Vladimir

2012/9/14 Kaz Kojima :
> Vladimir Yakovlev  wrote:
>> I reproduced the failure and found reason of it. I understood haw it
>> resolve and now I need small changes only - additional argument of
>> EMIT_MODE_SET. Is it good fo trunk?
>>
>> Thank you,
>> Vladimir
>>
>> 2012-09-14  Vladimir Yakovlev  
>>
>> * (optimize_mode_switching): Added an argument EMIT_MODE_SET calls.
>>
>> * config/epiphany/epiphany.h (EMIT_MODE_SET): Added an argument.
>>
>> * config/i386/i386.h (EMIT_MODE_SET): Added an argument.
>>
>> * config/sh/sh.h (EMIT_MODE_SET): Added an argument.
>
> No new failures on sh4-unknown-linux-gnu with your patch.
> Looks OK to me, though I have no authority to approve it
> except SH specific part.
>
> BTW, I guess that the active voice is usual in gcc/ChangeLog.
> Also, perhaps mailer issue, a tab should be used for indentation
> instead of 8 spaces and the empty line isn't required between
> items.  Maybe something like
>
> * mode-switching.c (optimize_mode_switching): Add an argument
> EMIT_MODE_SET calls.
> * config/epiphany/epiphany.h (EMIT_MODE_SET): Add an argument.
> * config/i386/i386.h (EMIT_MODE_SET): Likewise.
> * config/sh/sh.h (EMIT_MODE_SET): Likewise.
>
> is a usual form.
>
> Regards,
> kaz

[PATCHv3] rs6000: Add 2 built-ins to read the Time Base Register on PowerPC

[Tulio Magno Quites Machado Filho]

Add __builtin_ppc_get_timebase and __builtin_ppc_mftb to read the Time
Base Register on PowerPC.
They are required by applications that measure time at high frequencies
with high precision that can't afford a syscall.
__builtin_ppc_get_timebase returns the 64 bits of the Time Base Register
while __builtin_ppc_mftb generates only 1 instruction and returns the
least significant word on 32-bit environments and the whole Time Base value
on 64-bit.

[gcc]
2012-09-17 Tulio Magno Quites Machado Filho 

* config/rs6000/rs6000-builtin.def: Add __builtin_ppc_get_timebase
and __builtin_ppc_mftb.
* config/rs6000/rs6000.c (rs6000_expand_zeroop_builtin): New
function to expand an expression that calls a built-in without
arguments.
(rs6000_expand_builtin): Add __builtin_ppc_get_timebase and
__builtin_ppc_mftb.
(rs6000_init_builtins): Likewise.
* config/rs6000/rs6000.md: Likewise.
* doc/extend.texi (PowerPC Built-in Functions): New section.
(PowerPC AltiVec/VSX Built-in Functions):
Move some built-ins unrelated to Altivec/VSX to the new section.

[gcc/testsuite]
2012-09-17 Tulio Magno Quites Machado Filho 

* gcc.target/powerpc/ppc-get-timebase.c: New file.
* gcc.target/powerpc/ppc-mftb.c: New file.
---
 gcc/config/rs6000/rs6000-builtin.def   |6 ++
 gcc/config/rs6000/rs6000.c |   46 +++
 gcc/config/rs6000/rs6000.md|   79 
 gcc/doc/extend.texi|   51 -
 .../gcc.target/powerpc/ppc-get-timebase.c  |   20 +
 gcc/testsuite/gcc.target/powerpc/ppc-mftb.c|   18 +
 6 files changed, 202 insertions(+), 18 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/ppc-get-timebase.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/ppc-mftb.c

diff --git a/gcc/config/rs6000/rs6000-builtin.def 
b/gcc/config/rs6000/rs6000-builtin.def
index c8f8f86..9fa3a0f 100644
--- a/gcc/config/rs6000/rs6000-builtin.def
+++ b/gcc/config/rs6000/rs6000-builtin.def
@@ -1429,6 +1429,12 @@ BU_SPECIAL_X (RS6000_BUILTIN_RSQRT, "__builtin_rsqrt", 
RS6000_BTM_FRSQRTE,
 BU_SPECIAL_X (RS6000_BUILTIN_RSQRTF, "__builtin_rsqrtf", RS6000_BTM_FRSQRTES,
  RS6000_BTC_FP)
 
+BU_SPECIAL_X (RS6000_BUILTIN_GET_TB, "__builtin_ppc_get_timebase",
+RS6000_BTM_ALWAYS, RS6000_BTC_MISC)
+
+BU_SPECIAL_X (RS6000_BUILTIN_MFTB, "__builtin_ppc_mftb",
+RS6000_BTM_ALWAYS, RS6000_BTC_MISC)
+
 /* Darwin CfString builtin.  */
 BU_SPECIAL_X (RS6000_BUILTIN_CFSTRING, "__builtin_cfstring", RS6000_BTM_ALWAYS,
  RS6000_BTC_MISC)
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index a5a3848..c3bece1 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -9748,6 +9748,30 @@ rs6000_overloaded_builtin_p (enum rs6000_builtins fncode)
   return (rs6000_builtin_info[(int)fncode].attr & RS6000_BTC_OVERLOADED) != 0;
 }
 
+/* Expand an expression EXP that calls a builtin without arguments.  */
+static rtx
+rs6000_expand_zeroop_builtin (enum insn_code icode, rtx target)
+{
+  rtx pat;
+  enum machine_mode tmode = insn_data[icode].operand[0].mode;
+
+  if (icode == CODE_FOR_nothing)
+/* Builtin not supported on this processor.  */
+return 0;
+
+  if (target == 0
+  || GET_MODE (target) != tmode
+  || ! (*insn_data[icode].operand[0].predicate) (target, tmode))
+target = gen_reg_rtx (tmode);
+
+  pat = GEN_FCN (icode) (target);
+  if (! pat)
+return 0;
+  emit_insn (pat);
+
+  return target;
+}
+
 
 static rtx
 rs6000_expand_unop_builtin (enum insn_code icode, tree exp, rtx target)
@@ -11337,6 +11361,16 @@ rs6000_expand_builtin (tree exp, rtx target, rtx 
subtarget ATTRIBUTE_UNUSED,
   ? CODE_FOR_bpermd_di
   : CODE_FOR_bpermd_si), exp, target);
 
+case RS6000_BUILTIN_GET_TB:
+  return rs6000_expand_zeroop_builtin (CODE_FOR_rs6000_get_timebase,
+  target);
+
+case RS6000_BUILTIN_MFTB:
+  return rs6000_expand_zeroop_builtin (((TARGET_64BIT)
+   ? CODE_FOR_rs6000_mftb_di
+   : CODE_FOR_rs6000_mftb_si),
+  target);
+
 case ALTIVEC_BUILTIN_MASK_FOR_LOAD:
 case ALTIVEC_BUILTIN_MASK_FOR_STORE:
   {
@@ -11621,6 +11655,18 @@ rs6000_init_builtins (void)
 POWER7_BUILTIN_BPERMD, "__builtin_bpermd");
   def_builtin ("__builtin_bpermd", ftype, POWER7_BUILTIN_BPERMD);
 
+  ftype = build_function_type_list (unsigned_intDI_type_node,
+   NULL_TREE);
+  def_builtin ("__builtin_ppc_get_timebase", ftype, RS6000_BUILTIN_GET_TB);
+
+  if (TARGET_64BIT)
+ftype = build_function_type_list (unsigned_intDI_type_node

Re: [Patch ARM] big-endian support for Neon vext tests

[Richard Earnshaw]

On 05/09/12 23:14, Christophe Lyon wrote:
> Hello,
> 
> Although the recent optimization I have committed to use Neon vext
> instruction for suitable builtin_shuffle calls does not support
> big-endian yet, I have written a patch to the existing testcases such
> they now support big-endian mode.
> 
> I think it's worth improving these tests since writing the right masks
> for big-endian (such that the program computes the same results as in
> little-endian) is not always straightforward.
> 
> In particular:
> * I have added some comments in a few tests were it took me a while to
> find the right mask.
> * In the case of the test which is executed, I had to force the
> noinline attribute on the helper functions, otherwise the computed
> results are wrong in big-endian. It is probably an overkill workaround
> but it works :-)
>   I am going to file a bugzilla for this problem.
> 
> I have checked that replacing calls to builtin_shuffle by the expected
> Neon vext variant produces the expected results in big-endian mode,
> and I arranged the big-endian masks to get the same results.
> 
> Christophe.=
> 
> 
> neon-vext-big-endian-tests.patch
> 
> 
> N¬n‡r¥ªíÂ)emçhÂyhiם¢w^™©Ý
> 


I'm not sure about this.  Looking at the documentation in the manual for
builtin_suffle makes no mention of the results/behaviour being endian
dependent, which makes me wonder why this test needs to be.

R.

Re: [Patch, Fortran, F03] PR 54285: Calling a PPC with proc-ptr result

[Janus Weil]

>> Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
>
>
> Looks OK. Thanks for the patch.

Thanks a bunch. Committed as r191383.

Cheers,
Janus



>> 2012-09-17  Janus Weil  
>>
>> PR fortran/54285
>> * expr.c (gfc_check_pointer_assign): Correctly handle procedure
>> pointers
>> as function results.
>> * primary.c (gfc_match_varspec): Allow to call a PPC with proc-ptr
>> result.
>>
>> 2012-09-17  Janus Weil  
>>
>> PR fortran/54285
>> * gfortran.dg/proc_ptr_result_7.f90: New.
>
>

Re: [Patch]: Add CONST_FIXED_P predicate macro to rtl.h

[Richard Guenther]

On Mon, Sep 17, 2012 at 1:56 PM, Georg-Johann Lay  wrote:
> The subject says it all:
>
> Add CONST_FIXED_P predicate macro similar to CONST_INT_P to rtl.h.
>
> Currently, CONST_FIXED_P is not used in the compiler, except in avr.c that 
> does
>
> #ifndef CONST_FIXED_P
> #define CONST_FIXED_P(X) (CONST_FIXED == GET_CODE (X))
> #endif
>
> Ok for trunk?

Ok.

Thanks,
Richard.

> If this change is fine, I'll clean up the avr BE in a separate change.
>
> Johann
>
> * rtl.h (CONST_FIXED_P): New predicate macro.
>

Re: [patch] Fix memory exhaustion during cunrolli

[Richard Guenther]

On Mon, Sep 17, 2012 at 12:52 PM, Eric Botcazou  wrote:
>> Yes - now cfg_cleanup does that (and it really shouldn't be its job).  That
>> was the improvement I talked about - reducing the number of BBs a lot.
>
> OK, I removed the code and compiled the testcase of PR 43186 with --param max-
> completely-peel-loop-nest-depth=32 and got back the explosion.  Compilation is
> instantaneous again with my patch.
>
>> Ah, indeed ;)  Or just push struct loop of changed loops onto a stack.
>
> Thanks for the tip.  Revised patch attached, tested on x86_64-suse-linux.
> OK for the mainline?  Or do you want me to remove max-completely-peel-loop-
> nest-depth as well?

No, we can keep that.

Ok for trunk.

Thanks,
Richard.

>
> 2012-09-17  Eric Botcazou  
>
> * tree-cfgcleanup. (cleanup_control_expr_graph) : Remove
> code doing propagation from degenerate PHI nodes.
> * tree-ssa-loop-ivcanon.c (propagate_into_all_uses): New function.
> (propagate_constants_for_unrolling): Likewise.
> (tree_unroll_loops_completely): If the current loop has been unrolled
> and its father isn't the entire function, propagate constants within
> the new basic blocks by means of propagate_constants_for_unrolling.
>
>
> --
> Eric Botcazou

Re: [Patch, Fortran] PR54603 - fix structure constructors with proc-pointers

[Janus Weil]

Hi Tobias,

> structure constructures with proc-pointer arguments were either leading to
> wrong results or to ICEs.
> I use now the same condition as in gfc_trans_pointer_assignment.
>
> Build and regtested on x86-64-linux.
> OK for the trunk?

looks good to me. Thanks!

The "scan-tree-dump-times" directives in the test case are probably
supposed to check for the wrong-code issue, right? But shouldn't this
be caught by the runtime-checking already? Anyway a bit of
double-checking can not hurt, I guess ...

Cheers,
Janus

Re: [Patch,avr] Fix canadian cross build fail

[Denis Chertykov]

2012/9/15 Georg-Johann Lay :
> Canadian cross build fails because the wrong compiler is used to compile
> gen-avr-mmcu-texi.  This small tool must run on build and not on host, thus
> the right compiler is CC_FOR_BUILD.
>
> Just changing the compiler is not enough because files like system.h were
> dragged in that were configured for host, not for build.
>
> Therefore the patch factors out the structures/enums that are shared between
> the programs that run on host (compiler proper, driver) and gen-avr-mmcu-texi
> that runs on build.
>
> With the patch the compiler build fine, both as native cross
> (build=host!=target) and as canadian cross (build!=host!=target!=build).
>
> Moreover, I changed the string comparator in gen-avr-mmcu-texi.c to that
> it prints the devices in a more appropriate order with the AVR device name
> nomenclature.
>
> Ok to apply?
>

Approved.

Denis.

Re: [Patch, Fortran, F03] PR 54285: Calling a PPC with proc-ptr result

[Tobias Burnus]

On 09/17/2012 01:39 PM, Janus Weil wrote:

here is another proc-ptr patch, which allows to submit calls to
procedure-pointer components which have a procedure-pointer result.
This sounds a bit twisted (and I guess one has to suffer from some



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


Looks OK. Thanks for the patch.

Tobias


2012-09-17  Janus Weil  

PR fortran/54285
* expr.c (gfc_check_pointer_assign): Correctly handle procedure pointers
as function results.
* primary.c (gfc_match_varspec): Allow to call a PPC with proc-ptr
result.

2012-09-17  Janus Weil  

PR fortran/54285
* gfortran.dg/proc_ptr_result_7.f90: New.

[Patch, Fortran] PR54603 - fix structure constructors with proc-pointers

[Tobias Burnus]

structure constructures with proc-pointer arguments were either leading 
to wrong results or to ICEs.

I use now the same condition as in gfc_trans_pointer_assignment.

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

Tobias
2012-09-17  Tobias Burnus  

	PR fortran/54603
	* trans-expr.c (gfc_trans_subcomponent_assign): Handle
	proc-pointer components.

2012-09-17  Tobias Burnus  

	PR fortran/54603
	* gfortran.dg/structure_constructor_11.f90: New.

diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 84a4b34..98634c3 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -5506,11 +5506,11 @@ gfc_trans_subcomponent_assign (tree dest, gfc_component * cm, gfc_expr * expr)
 
   gfc_start_block (&block);
 
-  if (cm->attr.pointer)
+  if (cm->attr.pointer || cm->attr.proc_pointer)
 {
   gfc_init_se (&se, NULL);
   /* Pointer component.  */
-  if (cm->attr.dimension)
+  if (cm->attr.dimension && !cm->attr.proc_pointer)
 	{
 	  /* Array pointer.  */
 	  if (expr->expr_type == EXPR_NULL)
@@ -5530,6 +5530,11 @@ gfc_trans_subcomponent_assign (tree dest, gfc_component * cm, gfc_expr * expr)
 	  se.want_pointer = 1;
 	  gfc_conv_expr (&se, expr);
 	  gfc_add_block_to_block (&block, &se.pre);
+
+	  if (expr->symtree && expr->symtree->n.sym->attr.proc_pointer
+	  && expr->symtree->n.sym->attr.dummy)
+	se.expr = build_fold_indirect_ref_loc (input_location, se.expr);
+
 	  gfc_add_modify (&block, dest,
 			   fold_convert (TREE_TYPE (dest), se.expr));
 	  gfc_add_block_to_block (&block, &se.post);
--- /dev/null	2012-09-17 07:46:24.707708299 +0200
+++ gcc/gcc/testsuite/gfortran.dg/structure_constructor_11.f90	2012-09-17 12:11:02.0 +0200
@@ -0,0 +1,96 @@
+! { dg-do run}
+! { dg-options "-fdump-tree-original" }
+!
+! PR fortran/54603
+!
+! Contributed by Kacper Kowalik
+!
+module foo
+   implicit none
+
+   interface
+  subroutine cg_ext
+ implicit none
+  end subroutine cg_ext
+   end interface
+
+   type :: ext_ptr
+  procedure(cg_ext), nopass, pointer :: init
+  procedure(cg_ext), nopass, pointer :: cleanup
+   end type ext_ptr
+
+   type :: ext_ptr_array
+  type(ext_ptr) :: a
+  contains
+ procedure :: epa_init
+   end type ext_ptr_array
+
+   type(ext_ptr_array) :: bar
+
+contains
+   subroutine epa_init(this, init, cleanup)
+  implicit none
+  class(ext_ptr_array), intent(inout) :: this
+  procedure(cg_ext), pointer, intent(in):: init
+  procedure(cg_ext), pointer, intent(in):: cleanup
+
+  this%a = ext_ptr(null(), null())  ! Wrong code
+  this%a = ext_ptr(init, cleanup)  ! Wrong code
+
+  this%a%init => init  ! OK
+  this%a%cleanup => cleanup! OK
+
+  this%a = ext_ptr(this%a%init,this%a%cleanup) ! ICE in fold_convert_loc
+   end subroutine epa_init
+
+end module foo
+
+program ala
+   use foo, only: bar
+   implicit none
+   integer :: count1, count2
+   count1 = 0
+   count2 = 0
+
+   call setme
+   call bar%a%cleanup()
+   call bar%a%init()
+
+   ! They should be called once
+   if (count1 /= 23 .or. count2 /= 42) call abort ()
+
+contains
+
+   subroutine dummy1
+  implicit none
+  !print *, 'dummy1'
+  count1 = 23 
+   end subroutine dummy1
+
+   subroutine dummy2
+  implicit none
+  !print *, 'dummy2'
+  count2 = 42
+   end subroutine dummy2
+   
+   subroutine setme
+  use foo, only: bar, cg_ext
+  implicit none
+  procedure(cg_ext), pointer :: a_init, a_clean
+
+  a_init => dummy1
+  a_clean => dummy2
+  call bar%epa_init(a_init, a_clean)
+   end subroutine setme
+
+end program ala
+
+! { dg-final { scan-tree-dump-times "ext_ptr.\[0-9\]+.init = 0B;" 1 "original" } }
+! { dg-final { scan-tree-dump-times "ext_ptr.\[0-9\]+.cleanup = 0B;" 1 "original" } }
+! { dg-final { scan-tree-dump-times "ext_ptr.1.init = \\*init;" 1 "original" } }
+! { dg-final { scan-tree-dump-times "ext_ptr.1.cleanup = \\*cleanup;" 1 "original" } }
+! { dg-final { scan-tree-dump-times "this->_data->a.init = \\*init;" 1 "original" } }
+! { dg-final { scan-tree-dump-times "this->_data->a.cleanup = \\*cleanup;" 1 "original" } }
+! { dg-final { scan-tree-dump-times "ext_ptr.\[0-9\]+.init = this->_data->a.init;" 1 "original" } }
+! { dg-final { scan-tree-dump-times "ext_ptr.\[0-9\]+.cleanup = this->_data->a.cleanup;" 1 "original" } }
+! { dg-final { cleanup-tree-dump "original" } }

[Patch]: Add CONST_FIXED_P predicate macro to rtl.h

[Georg-Johann Lay]

The subject says it all:

Add CONST_FIXED_P predicate macro similar to CONST_INT_P to rtl.h.

Currently, CONST_FIXED_P is not used in the compiler, except in avr.c that does

#ifndef CONST_FIXED_P
#define CONST_FIXED_P(X) (CONST_FIXED == GET_CODE (X))
#endif

Ok for trunk?

If this change is fine, I'll clean up the avr BE in a separate change.

Johann

* rtl.h (CONST_FIXED_P): New predicate macro.

Index: rtl.h
===
--- rtl.h	(revision 191342)
+++ rtl.h	(working copy)
@@ -419,6 +419,9 @@ struct GTY((variable_size)) rtvec_def {
 /* Predicate yielding nonzero iff X is an rtx for a constant integer.  */
 #define CONST_INT_P(X) (GET_CODE (X) == CONST_INT)
 
+/* Predicate yielding nonzero iff X is an rtx for a constant fixed-point.  */
+#define CONST_FIXED_P(X) (GET_CODE (X) == CONST_FIXED)
+
 /* Predicate yielding true iff X is an rtx for a double-int
or floating point constant.  */
 #define CONST_DOUBLE_P(X) (GET_CODE (X) == CONST_DOUBLE)

[Patch, Fortran, F03] PR 54285: Calling a PPC with proc-ptr result

[Janus Weil]

Hi all,

here is another proc-ptr patch, which allows to submit calls to
procedure-pointer components which have a procedure-pointer result.
This sounds a bit twisted (and I guess one has to suffer from some
very special form of mental illness in order to feel the urge to do
something like this), but apparently it is allowed by the standard,
and by chance I came across it recently.

Fortunately the patch is rather straightforward and just makes some
minor adjustments in the corresponding parsing and checking routines.
Regtested on x86_64-unknown-linux-gnu. Ok for trunk?

Cheers,
Janus


2012-09-17  Janus Weil  

PR fortran/54285
* expr.c (gfc_check_pointer_assign): Correctly handle procedure pointers
as function results.
* primary.c (gfc_match_varspec): Allow to call a PPC with proc-ptr
result.

2012-09-17  Janus Weil  

PR fortran/54285
* gfortran.dg/proc_ptr_result_7.f90: New.


pr54285.diff
Description: Binary data


proc_ptr_result_7.f90
Description: Binary data

Re: [C++ PATCH] Add overflow checking to __cxa_vec_new[23]

[Florian Weimer]

On 09/17/2012 12:15 PM, Paolo Carlini wrote:

Hi,

On 09/17/2012 11:51 AM, Florian Weimer wrote:

On 08/21/2012 12:37 PM, Florian Weimer wrote:

I don't think there are any callers out there, but let's fix this for
completeness.

A compiler emitting code to call this function would still have to
perform overflow checks for the new T[n][m] case, so this interface is
not as helpful as it looks at first glance.

Tested on x86_64-redhat-linux-gnu.


Ping?

This function is apparently used by compilers based on the EDG
front-end, so it's not actually dead.



Being code that touches the library, the patch should go to the
libstdc++ maliling list too. Likewise the testcase, should be in the
libstdc++ testsuite, I guess.


Oh, I thought that this wouldn't apply to internal C++ support code.  Sorry.


That said, I didn't really follow the details of your recent work. Who
did? Jason? I would gently ping the same maintainer.


Indeed, Jason reviewed that.  Cc:ing.

--
Florian Weimer / Red Hat Product Security Team

Re: [patch] Fix memory exhaustion during cunrolli

[Eric Botcazou]

> Yes - now cfg_cleanup does that (and it really shouldn't be its job).  That
> was the improvement I talked about - reducing the number of BBs a lot.

OK, I removed the code and compiled the testcase of PR 43186 with --param max-
completely-peel-loop-nest-depth=32 and got back the explosion.  Compilation is 
instantaneous again with my patch.

> Ah, indeed ;)  Or just push struct loop of changed loops onto a stack.

Thanks for the tip.  Revised patch attached, tested on x86_64-suse-linux.
OK for the mainline?  Or do you want me to remove max-completely-peel-loop-
nest-depth as well?


2012-09-17  Eric Botcazou  

* tree-cfgcleanup. (cleanup_control_expr_graph) : Remove
code doing propagation from degenerate PHI nodes.
* tree-ssa-loop-ivcanon.c (propagate_into_all_uses): New function.
(propagate_constants_for_unrolling): Likewise.
(tree_unroll_loops_completely): If the current loop has been unrolled
and its father isn't the entire function, propagate constants within
the new basic blocks by means of propagate_constants_for_unrolling.


-- 
Eric BotcazouIndex: tree-cfgcleanup.c
===
--- tree-cfgcleanup.c	(revision 191365)
+++ tree-cfgcleanup.c	(working copy)
@@ -88,40 +88,11 @@ cleanup_control_expr_graph (basic_block
   switch (gimple_code (stmt))
 	{
 	case GIMPLE_COND:
-	  {
-	tree lhs = gimple_cond_lhs (stmt);
-	tree rhs = gimple_cond_rhs (stmt);
-	/* For conditions try harder and lookup single-argument
-	   PHI nodes.  Only do so from the same basic-block though
-	   as other basic-blocks may be dead already.  */
-	if (TREE_CODE (lhs) == SSA_NAME
-		&& !name_registered_for_update_p (lhs))
-	  {
-		gimple def_stmt = SSA_NAME_DEF_STMT (lhs);
-		if (gimple_code (def_stmt) == GIMPLE_PHI
-		&& gimple_phi_num_args (def_stmt) == 1
-		&& gimple_bb (def_stmt) == gimple_bb (stmt)
-		&& (TREE_CODE (PHI_ARG_DEF (def_stmt, 0)) != SSA_NAME
-			|| !name_registered_for_update_p (PHI_ARG_DEF (def_stmt,
-   0
-		  lhs = PHI_ARG_DEF (def_stmt, 0);
-	  }
-	if (TREE_CODE (rhs) == SSA_NAME
-		&& !name_registered_for_update_p (rhs))
-	  {
-		gimple def_stmt = SSA_NAME_DEF_STMT (rhs);
-		if (gimple_code (def_stmt) == GIMPLE_PHI
-		&& gimple_phi_num_args (def_stmt) == 1
-		&& gimple_bb (def_stmt) == gimple_bb (stmt)
-		&& (TREE_CODE (PHI_ARG_DEF (def_stmt, 0)) != SSA_NAME
-			|| !name_registered_for_update_p (PHI_ARG_DEF (def_stmt,
-   0
-		  rhs = PHI_ARG_DEF (def_stmt, 0);
-	  }
-	val = fold_binary_loc (loc, gimple_cond_code (stmt),
-   boolean_type_node, lhs, rhs);
-	break;
-	  }
+	  val = fold_binary_loc (loc, gimple_cond_code (stmt),
+ boolean_type_node,
+			 gimple_cond_lhs (stmt),
+ gimple_cond_rhs (stmt));
+	  break;
 
 	case GIMPLE_SWITCH:
 	  val = gimple_switch_index (stmt);
Index: tree-ssa-loop-ivcanon.c
===
--- tree-ssa-loop-ivcanon.c	(revision 191365)
+++ tree-ssa-loop-ivcanon.c	(working copy)
@@ -503,6 +503,80 @@ canonicalize_induction_variables (void)
   return 0;
 }
 
+/* Propagate VAL into all uses of SSA_NAME.  */
+
+static void
+propagate_into_all_uses (tree ssa_name, tree val)
+{
+  imm_use_iterator iter;
+  gimple use_stmt;
+
+  FOR_EACH_IMM_USE_STMT (use_stmt, iter, ssa_name)
+{
+  gimple_stmt_iterator use_stmt_gsi = gsi_for_stmt (use_stmt);
+  use_operand_p use;
+
+  FOR_EACH_IMM_USE_ON_STMT (use, iter)
+	SET_USE (use, val);
+
+  if (is_gimple_assign (use_stmt)
+	  && get_gimple_rhs_class (gimple_assign_rhs_code (use_stmt))
+	 == GIMPLE_SINGLE_RHS)
+	{
+	  tree rhs = gimple_assign_rhs1 (use_stmt);
+
+	  if (TREE_CODE (rhs) == ADDR_EXPR)
+	recompute_tree_invariant_for_addr_expr (rhs);
+	}
+
+  fold_stmt_inplace (&use_stmt_gsi);
+  update_stmt (use_stmt);
+}
+}
+
+/* Propagate constant SSA_NAMEs defined in basic block BB.  */
+
+static void
+propagate_constants_for_unrolling (basic_block bb)
+{
+  gimple_stmt_iterator gsi;
+
+  /* Look for degenerate PHI nodes with constant argument.  */
+  for (gsi = gsi_start_phis (bb); !gsi_end_p (gsi); )
+{
+  gimple phi = gsi_stmt (gsi);
+  tree result = gimple_phi_result (phi);
+  tree arg = gimple_phi_arg_def (phi, 0);
+
+  if (gimple_phi_num_args (phi) == 1 && TREE_CODE (arg) == INTEGER_CST)
+	{
+	  propagate_into_all_uses (result, arg);
+	  gsi_remove (&gsi, true);
+	  release_ssa_name (result);
+	}
+  else
+	gsi_next (&gsi);
+}
+
+  /* Look for assignments to SSA names with constant RHS.  */
+  for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); )
+{
+  gimple stmt = gsi_stmt (gsi);
+  tree lhs;
+
+  if (is_gimple_assign (stmt)
+	  && (lhs = gimple_assign_lhs (stmt), TREE_CODE (lhs) == SSA_NAME)
+	  && gimple_assign_rhs_code (stmt) == INTEGER_CST)
+	{
+	  propagate_into_all_u

Re: [Patch, fortran] PR46897 - [OOP] type-bound defined ASSIGNMENT(=) not used for derived type component in intrinsic assign

[Paul Richard Thomas]

Dear Tobias,

> The following test case doesn't work; it should print "Overloaded" - and
> does so with crayftn. But with your patch, it doesn't.

For some reason, I guess, the attribute defined_assign_comp is not
getting passed along to type 'b'.

> + build_assignment (gfc_exec_op op, gfc_expr *expr1, gfc_expr *expr2, +
> gfc_component *comp1, gfc_component *comp2, locus loc)
>
> For comp1/comp2, I am wondering whether one shouldn't add a
>   gcc_assert ((comp1 && comp2) || (!comp1 && !comp2));

I guess that it will do no harm and might be advised if this function
is called from elsewhere.
>
>
> + get_temp_from_expr (gfc_expr *e, gfc_namespace *ns)
>
> Not that we make so much use of it, but its symbol could be a candidate for
> attr.artificial. (I don't know whether it should.)

I don't know either.  I don't recall even noticing the artificial
attribute.  I will follow it up to see what use is made of it and see
if it applies here.  Presumably this couples directly to
DECL_ARTIFICIAL?

Thanks for the review.

Paul

PS I really, really want to get used to this PR!
PPS I presume that the reason for two temporaries is clear to you?

Re: [PATCH, ARM] Use vld1/vst1 to implement vec_set/vec_extract

[Richard Earnshaw]

On 14/09/12 19:03, Ulrich Weigand wrote:
> Hello,
> 
> following up on the prior patch, this patch exploits more opportunities to
> generate the vld1 / vst1 family of instructions, this time to implement the
> vec_set and vec_extract patterns with memory scalar operands.
> 
> Without the patch, vec_set/vec_extract only support register operands for the
> scalar, possibly requiring extra moves.  In some cases we'd still get a vst1
> instruction as a result, since combine would match a neon_vst1_lane pattern.
> 
> However, that pattern seems to be actually incorrect for big-endian systems
> (due to a line number ordering mismatch).  The patch therefore also changes
> neon_vst1_lane to use an UNSPEC instead of vec_select to model its operation,
> just like all the other NEON intrinsic patterns depending on line numbers
> already do.
> 
> Benchmarking showed only marginal improvements, but no regression.  It seems
> useful to support this anyway ...
> 
> Tested on arm-linux-gnueabi.
> OK for mainline?
> 

You confused me for a bit with the reference to "line numbers", but I
think you must mean "lane numbers".

FTR, I see no reason why GCC would have problems with 64-bit vectors in
big-endian mode, it's only 128-bit (and larger) vectors that pose a
problem (ok, the HW numbers the lanes from the other end, but the
transformation is trivial).

This is OK.

R.

> Bye,
> Ulrich
> 
> 
> 2012-09-14  Ulrich Weigand  
> 
> * config/arm/arm.c (arm_rtx_costs_1): Handle vec_extract and vec_set
> patterns.
> * config/arm/arm.md ("vec_set_internal"): Support memory source
> operands, implemented via vld1 instruction.
> ("vec_extract"): Support memory destination operands, 
> implemented
> via vst1 instruction.
> ("neon_vst1_lane"): Use UNSPEC_VST1_LANE instead of vec_select.
> * config/arm/predicates.md ("neon_lane_number"): Remove.
> 
> Index: gcc-head/gcc/config/arm/arm.c
> ===
> --- gcc-head.orig/gcc/config/arm/arm.c  2012-09-14 19:40:51.0 +0200
> +++ gcc-head/gcc/config/arm/arm.c   2012-09-14 19:41:14.0 +0200
> @@ -7666,6 +7666,28 @@ arm_rtx_costs_1 (rtx x, enum rtx_code ou
>return true;
> 
>  case SET:
> +  /* The vec_extract patterns accept memory operands that require an
> +address reload.  Account for the cost of that reload to give the
> +auto-inc-dec pass an incentive to try to replace them.  */
> +  if (TARGET_NEON && MEM_P (SET_DEST (x))
> + && GET_CODE (SET_SRC (x)) == VEC_SELECT)
> +   {
> + *total = rtx_cost (SET_DEST (x), code, 0, speed);
> + if (!neon_vector_mem_operand (SET_DEST (x), 2))
> +   *total += COSTS_N_INSNS (1);
> + return true;
> +   }
> +  /* Likewise for the vec_set patterns.  */
> +  if (TARGET_NEON && GET_CODE (SET_SRC (x)) == VEC_MERGE
> + && GET_CODE (XEXP (SET_SRC (x), 0)) == VEC_DUPLICATE
> + && MEM_P (XEXP (XEXP (SET_SRC (x), 0), 0)))
> +   {
> + rtx mem = XEXP (XEXP (SET_SRC (x), 0), 0);
> + *total = rtx_cost (mem, code, 0, speed);
> + if (!neon_vector_mem_operand (mem, 2))
> +   *total += COSTS_N_INSNS (1);
> + return true;
> +   }
>return false;
> 
>  case UNSPEC:
> Index: gcc-head/gcc/config/arm/neon.md
> ===
> --- gcc-head.orig/gcc/config/arm/neon.md2012-09-14 19:40:51.0 
> +0200
> +++ gcc-head/gcc/config/arm/neon.md 2012-09-14 19:41:14.0 +0200
> @@ -416,30 +416,33 @@
>[(set_attr "neon_type" "neon_vld1_1_2_regs")])
> 
>  (define_insn "vec_set_internal"
> -  [(set (match_operand:VD 0 "s_register_operand" "=w")
> +  [(set (match_operand:VD 0 "s_register_operand" "=w,w")
>  (vec_merge:VD
>(vec_duplicate:VD
> -(match_operand: 1 "s_register_operand" "r"))
> -  (match_operand:VD 3 "s_register_operand" "0")
> -  (match_operand:SI 2 "immediate_operand" "i")))]
> +(match_operand: 1 "nonimmediate_operand" "Um,r"))
> +  (match_operand:VD 3 "s_register_operand" "0,0")
> +  (match_operand:SI 2 "immediate_operand" "i,i")))]
>"TARGET_NEON"
>  {
>int elt = ffs ((int) INTVAL (operands[2])) - 1;
>if (BYTES_BIG_ENDIAN)
>  elt = GET_MODE_NUNITS (mode) - 1 - elt;
>operands[2] = GEN_INT (elt);
> -
> -  return "vmov.\t%P0[%c2], %1";
> +
> +  if (which_alternative == 0)
> +return "vld1.\t{%P0[%c2]}, %A1";
> +  else
> +return "vmov.\t%P0[%c2], %1";
>  }
> -  [(set_attr "neon_type" "neon_mcr")])
> +  [(set_attr "neon_type" "neon_vld1_vld2_lane,neon_mcr")])
> 
>  (define_insn "vec_set_internal"
> -  [(set (match_operand:VQ 0 "s_register_operand" "=w")
> +  [(set (match_operand:VQ 0 "s_register_operand" "=w,w")
>  (vec_merge:VQ
>(vec_duplicate:VQ
> -(match_operand: 1 "s_r

Re: [C++ PATCH] Add overflow checking to __cxa_vec_new[23]

[Paolo Carlini]

Hi,

On 09/17/2012 11:51 AM, Florian Weimer wrote:

On 08/21/2012 12:37 PM, Florian Weimer wrote:

I don't think there are any callers out there, but let's fix this for
completeness.

A compiler emitting code to call this function would still have to
perform overflow checks for the new T[n][m] case, so this interface is
not as helpful as it looks at first glance.

Tested on x86_64-redhat-linux-gnu.


Ping?

This function is apparently used by compilers based on the EDG 
front-end, so it's not actually dead.
Being code that touches the library, the patch should go to the 
libstdc++ maliling list too. Likewise the testcase, should be in the 
libstdc++ testsuite, I guess.


That said, I didn't really follow the details of your recent work. Who 
did? Jason? I would gently ping the same maintainer.


Thanks!
Paolo.

Re: [PATCH,ARM] Suppress the dynamic linker commands for statically linked programs

[Richard Earnshaw]

On 14/09/12 21:34, Ben Cheng wrote:
> Hi,
> 
> Recently we found out that the .interp section starts to show up in
> ARM executables compiled with "-shared -static" and the gold linker
> from binutils 2.22. We tracked down the origin of the dynamic linker
> commands and they are always explicitly specified in
> config/arm/linux-elf.h. We tested the following simple patch to
> suppress the dynamic linker options for statically linked programs on
> Android's AOSP tree. Everything builds fine and the unneeded .interp
> section is gone.
> 
> Thanks,
> -Ben
> 
> ==
> 
> gcc/ChangeLog
> 2012-09-14 Ben Cheng 
> * config/arm/linux-elf.h: Suppress the dynamic linker commands for
> statically linked programs.
> 
> Index: config/arm/linux-elf.h
> ===
> --- config/arm/linux-elf.h(revision 191198)
> +++ config/arm/linux-elf.h(working copy)
> @@ -65,8 +65,9 @@
> %{static:-Bstatic} \
> %{shared:-shared} \
> %{symbolic:-Bsymbolic} \
> -   %{rdynamic:-export-dynamic} \
> -   -dynamic-linker " GNU_USER_DYNAMIC_LINKER " \
> +   %{!static: \
> + %{rdynamic:-export-dynamic} \
> + -dynamic-linker " GNU_USER_DYNAMIC_LINKER "} \
> -X \
> %{mbig-endian:-EB} %{mlittle-endian:-EL}" \
> SUBTARGET_EXTRA_LINK_SPEC
> 

OK.

R.

Re: [PATCH, ARM] Prefer vld1.64/vst1.64 over vldm/vstm

[Richard Earnshaw]

On 14/09/12 19:02, Ulrich Weigand wrote:
> Hello,
> 
> this patch changes the ARM back-end to use vld1.64/vst1.64 instructions
> instead of vldm/vstm  -where possible-  to implement double-word moves.
> 
> The main benefit of this is that it allows the compiler to provide
> appropriate alignment hints, which may improve performance.
> 
> The patch is based on an earlier version by Ramana.  This version has
> now successfully passed regression testing and benchmarking (no
> performance regressions found, improvements of up to 2.5% on certain
> benchmarks).
> 
> Tested on arm-linux-gnueabi.
> OK for mainline?
> 
> Bye,
> Ulrich
> 
> 
> 2012-09-14  Ramana Radhakrishnan  
>   Ulrich Weigand  
> 
>   * config/arm/arm.c (output_move_neon): Update comment.
>   Use vld1.64/vst1.64 instead of vldm/vstm where possible.
>   (neon_vector_mem_operand): Support double-word modes.
>   * config/arm/neon.md (*neon_mov VD): Call output_move_neon
>   instead of output_move_vfp.  Change constraint from Uv to Un.
> 

You should use HARD_REGNO_NREGS rather than ARM_NUM_REGS (which is
really intended only for core registers).

OK with that change.

R.
> Index: gcc-head/gcc/config/arm/arm.c
> ===
> --- gcc-head.orig/gcc/config/arm/arm.c2012-09-14 19:38:20.0 
> +0200
> +++ gcc-head/gcc/config/arm/arm.c 2012-09-14 19:40:51.0 +0200
> @@ -9629,7 +9629,11 @@ neon_vector_mem_operand (rtx op, int typ
>&& REG_MODE_OK_FOR_BASE_P (XEXP (ind, 0), VOIDmode)
>&& CONST_INT_P (XEXP (ind, 1))
>&& INTVAL (XEXP (ind, 1)) > -1024
> -  && INTVAL (XEXP (ind, 1)) < 1016
> +  /* For quad modes, we restrict the constant offset to be slightly less
> +  than what the instruction format permits.  We have no such constraint
> +  on double mode offsets.  (This must match arm_legitimate_index_p.)  */
> +  && (INTVAL (XEXP (ind, 1))
> +   < (VALID_NEON_QREG_MODE (GET_MODE (op))? 1016 : 1024))
>&& (INTVAL (XEXP (ind, 1)) & 3) == 0)
>  return TRUE;
>  
> @@ -14573,15 +14577,16 @@ output_move_vfp (rtx *operands)
>return "";
>  }
>  
> -/* Output a Neon quad-word load or store, or a load or store for
> -   larger structure modes.
> +/* Output a Neon double-word or quad-word load or store, or a load
> +   or store for larger structure modes.
>  
> WARNING: The ordering of elements is weird in big-endian mode,
> -   because we use VSTM, as required by the EABI.  GCC RTL defines
> -   element ordering based on in-memory order.  This can be differ
> -   from the architectural ordering of elements within a NEON register.
> -   The intrinsics defined in arm_neon.h use the NEON register element
> -   ordering, not the GCC RTL element ordering.
> +   because the EABI requires that vectors stored in memory appear
> +   as though they were stored by a VSTM, as required by the EABI.
> +   GCC RTL defines element ordering based on in-memory order.
> +   This can be different from the architectural ordering of elements
> +   within a NEON register. The intrinsics defined in arm_neon.h use the
> +   NEON register element ordering, not the GCC RTL element ordering.
>  
> For example, the in-memory ordering of a big-endian a quadword
> vector with 16-bit elements when stored from register pair {d0,d1}
> @@ -14595,7 +14600,22 @@ output_move_vfp (rtx *operands)
>   dN -> (rN+1, rN), dN+1 -> (rN+3, rN+2)
>  
> So that STM/LDM can be used on vectors in ARM registers, and the
> -   same memory layout will result as if VSTM/VLDM were used.  */
> +   same memory layout will result as if VSTM/VLDM were used.
> +
> +   Instead of VSTM/VLDM we prefer to use VST1.64/VLD1.64 where
> +   possible, which allows use of appropriate alignment tags.
> +   Note that the choice of "64" is independent of the actual vector
> +   element size; this size simply ensures that the behavior is
> +   equivalent to VSTM/VLDM in both little-endian and big-endian mode.
> +
> +   Due to limitations of those instructions, use of VST1.64/VLD1.64
> +   is not possible if:
> +- the address contains PRE_DEC, or
> +- the mode refers to more than 4 double-word registers
> +
> +   In those cases, it would be possible to replace VSTM/VLDM by a
> +   sequence of instructions; this is not currently implemented since
> +   this is not certain to actually improve performance.  */
>  
>  const char *
>  output_move_neon (rtx *operands)
> @@ -14629,13 +14649,23 @@ output_move_neon (rtx *operands)
>switch (GET_CODE (addr))
>  {
>  case POST_INC:
> -  templ = "v%smia%%?\t%%0!, %%h1";
> -  ops[0] = XEXP (addr, 0);
> +  /* We have to use vldm / vstm for too-large modes.  */
> +  if (ARM_NUM_REGS (mode) / 2 > 4)
> + {
> +   templ = "v%smia%%?\t%%0!, %%h1";
> +   ops[0] = XEXP (addr, 0);
> + }
> +  else
> + {
> +   templ = "v%s1.64\t%%h1, %%A0";
> +   ops[0] = mem;

Re: [Patch, Fortran] PR54599 (4/n) FIx issues found by Coverity scann

[Mikael Morin]

On 17/09/2012 09:47, Tobias Burnus wrote:
> This patch fixes some of the issues collected in the PR.
> 
> 
> Some remarks to the changed in the attached patch:
> 
> 
> - gcc_assert (*format++ == '$');
> 
> That code gets executed when
>  "some error message with value %d for string %s"
> gets translated into
>  "some error message for string %2$s with value %1$d"
> 
> And without the ++ gfortran doesn't skip over the $ sign.
> 
> 
> +  gcc_assert (derived1 && derived2);
> One of the many places where we first check for non-NULL - and then
> dereference the pointer unconditionally.
> 
> 
> -  && ref->u.ar.as->lower && ref->u.ar.as->upper)
> 
> "lower" is an array of pointers but not a pointer itself - thus, "lower"
> is always != NULL. Ditto for upper.
> 
> 
> 
> - break;
> + continue;
> 
> It makes sense to walk through the loop more than once ;-)
> 
> +   size = int_size_in_bytes (type);
> +   gcc_assert (size >= 0);
> 
> The function returns a HOST_WIDE_INT or  -1 if it doesn't fit  into that
> signed variable. To silence the warning, I now check the result and
> added an assert.
> 
> 
> Build and regtested on x86-64-linux.
> OK for the trunk?
> 
> Tobias
OK

Re: [C++ PATCH] Add overflow checking to __cxa_vec_new[23]

[Florian Weimer]

On 08/21/2012 12:37 PM, Florian Weimer wrote:

I don't think there are any callers out there, but let's fix this for
completeness.

A compiler emitting code to call this function would still have to
perform overflow checks for the new T[n][m] case, so this interface is
not as helpful as it looks at first glance.

Tested on x86_64-redhat-linux-gnu.


Ping?

This function is apparently used by compilers based on the EDG 
front-end, so it's not actually dead.


--
Florian Weimer / Red Hat Product Security Team

Re: [PATCH] PR other/54411: libiberty: objalloc_alloc integer overflows (CVE-2012-3509)

[Florian Weimer]

On 09/05/2012 07:31 AM, Ian Lance Taylor wrote:

On Wed, Aug 29, 2012 at 10:32 AM, Florian Weimer  wrote:


This patches fixes an integer overflow in libiberty, which leads to
crashes in binutils.  The long version of the objalloc_alloc macro
would have needed another conditional, so I removed that and replaced
it with a call to the actual implementation.


I guess I don't see why removing the macro is desirable.  In many uses
of objalloc_alloc the conditional can be optimized out anyhow.  It's
true that it can't always be, but, so what?  The macro is probably
still a win.


Fair enough.  I've added a wraparound check to the macro.  Okay for trunk?

--
Florian Weimer / Red Hat Product Security Team
2012-09-17  Florian Weimer  

PR other/54411
* objalloc.h (objalloc_alloc): Do not use fast path on wraparound.

2012-09-17  Florian Weimer  

PR other/54411
* objalloc.c (_objalloc_alloc): Add overflow check covering
alignment and CHUNK_HEADER_SIZE addition.

Index: libiberty/objalloc.c
===
--- libiberty/objalloc.c	(revision 191378)
+++ libiberty/objalloc.c	(working copy)
@@ -1,5 +1,5 @@
 /* objalloc.c -- routines to allocate memory for objects
-   Copyright 1997 Free Software Foundation, Inc.
+   Copyright 1997-2012 Free Software Foundation, Inc.
Written by Ian Lance Taylor, Cygnus Solutions.
 
 This program is free software; you can redistribute it and/or modify it
@@ -112,8 +112,9 @@
 /* Allocate space from an objalloc structure.  */
 
 PTR
-_objalloc_alloc (struct objalloc *o, unsigned long len)
+_objalloc_alloc (struct objalloc *o, unsigned long original_len)
 {
+  unsigned long len = original_len;
   /* We avoid confusion from zero sized objects by always allocating
  at least 1 byte.  */
   if (len == 0)
@@ -121,6 +122,11 @@
 
   len = (len + OBJALLOC_ALIGN - 1) &~ (OBJALLOC_ALIGN - 1);
 
+  /* Check for overflow in the alignment operation above and the
+ malloc argument below. */
+  if (len + CHUNK_HEADER_SIZE < original_len)
+return NULL;
+
   if (len <= o->current_space)
 {
   o->current_ptr += len;
Index: include/objalloc.h
===
--- include/objalloc.h	(revision 191378)
+++ include/objalloc.h	(working copy)
@@ -1,5 +1,5 @@
 /* objalloc.h -- routines to allocate memory for objects
-   Copyright 1997, 2001 Free Software Foundation, Inc.
+   Copyright 1997-2012 Free Software Foundation, Inc.
Written by Ian Lance Taylor, Cygnus Solutions.
 
 This program is free software; you can redistribute it and/or modify it
@@ -91,7 +91,7 @@
  if (__len == 0)			\
__len = 1;			\
  __len = (__len + OBJALLOC_ALIGN - 1) &~ (OBJALLOC_ALIGN - 1);	\
- (__len <= __o->current_space	\
+ (__len && __len <= __o->current_space\
   ? (__o->current_ptr += __len,	\
 	 __o->current_space -= __len,	\
 	 (void *) (__o->current_ptr - __len))\

Re: GCC 4.7.2 Status Report (2012-09-14), branch frozen

[Jakub Jelinek]

On Sun, Sep 16, 2012 at 04:59:29PM -0400, Jack Howarth wrote:
> > All changes need explicit release manager approval until the final
> > release of GCC 4.7.2 which should happen roughly one week after
> > the release candidate if no issues show up with it.
> 
>The backport of changes required to adjust FSF gcc to crt changes made
> in Mountain Lion...
> 
> http://gcc.gnu.org/ml/gcc-patches/2012-06/msg01181.html
> 
> were approved by the darwin maintainer...
> 
> http://gcc.gnu.org/ml/gcc-patches/2012-06/msg01265.html
> 
> but never commited to the gcc-4_7-branch. Can we still get these into the gcc
> 4.7.2 release?

Is that a regression compared to 4.7.0 or 4.7.1?  If not, I'd prefer to
avoid doing yet another RC, it can wait for 4.7.3.  Just don't forget to
commit it.

Jakub

Re: [PATCH] Fix missing EH updates in execute_cse_sincos (PR tree-optimization/54563)

[Richard Guenther]

On Sun, Sep 16, 2012 at 5:55 PM, Jakub Jelinek  wrote:
> Hi!
>
> As discussed in the PR, this patch fixes the ICE by calling
> gimple_purge_dead_eh_edges if the last stmt has been replaced by the pass.
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> Still, I think it would be nice if e.g. powf or cosl were throw() in C++, at
> least if they are treated as builtins or at least in C++11 where they are
> library functions.

Ok.

Thanks,
Richard.

> 2012-09-16  Jakub Jelinek  
>
> PR tree-optimization/54563
> * tree-ssa-math-opts.c (execute_cse_sincos): Call
> gimple_purge_dead_eh_edges if last call has been changed.
>
> * g++.dg/torture/pr54563.C: New test.
>
> --- gcc/tree-ssa-math-opts.c.jj 2012-09-12 10:57:02.0 +0200
> +++ gcc/tree-ssa-math-opts.c2012-09-14 21:03:05.546319590 +0200
> @@ -1378,12 +1378,18 @@ execute_cse_sincos (void)
>FOR_EACH_BB (bb)
>  {
>gimple_stmt_iterator gsi;
> +  bool cleanup_eh = false;
>
>for (gsi = gsi_after_labels (bb); !gsi_end_p (gsi); gsi_next (&gsi))
>  {
>   gimple stmt = gsi_stmt (gsi);
>   tree fndecl;
>
> + /* Only the last stmt in a bb could throw, no need to call
> +gimple_purge_dead_eh_edges if we change something in the middle
> +of a basic block.  */
> + cleanup_eh = false;
> +
>   if (is_gimple_call (stmt)
>   && gimple_call_lhs (stmt)
>   && (fndecl = gimple_call_fndecl (stmt))
> @@ -1421,6 +1427,7 @@ execute_cse_sincos (void)
>   gimple_set_location (new_stmt, loc);
>   unlink_stmt_vdef (stmt);
>   gsi_replace (&gsi, new_stmt, true);
> + cleanup_eh = true;
>   if (gimple_vdef (stmt))
> release_ssa_name (gimple_vdef (stmt));
> }
> @@ -1443,6 +1450,7 @@ execute_cse_sincos (void)
>   gimple_set_location (new_stmt, loc);
>   unlink_stmt_vdef (stmt);
>   gsi_replace (&gsi, new_stmt, true);
> + cleanup_eh = true;
>   if (gimple_vdef (stmt))
> release_ssa_name (gimple_vdef (stmt));
> }
> @@ -1460,6 +1468,7 @@ execute_cse_sincos (void)
>   gimple_set_location (new_stmt, loc);
>   unlink_stmt_vdef (stmt);
>   gsi_replace (&gsi, new_stmt, true);
> + cleanup_eh = true;
>   if (gimple_vdef (stmt))
> release_ssa_name (gimple_vdef (stmt));
> }
> @@ -1469,6 +1478,8 @@ execute_cse_sincos (void)
> }
> }
> }
> +  if (cleanup_eh)
> +   cfg_changed |= gimple_purge_dead_eh_edges (bb);
>  }
>
>statistics_counter_event (cfun, "sincos statements inserted",
> --- gcc/testsuite/g++.dg/torture/pr54563.C.jj   2012-09-14 21:05:07.514702413 
> +0200
> +++ gcc/testsuite/g++.dg/torture/pr54563.C  2012-09-14 21:04:40.0 
> +0200
> @@ -0,0 +1,14 @@
> +// PR tree-optimization/54563
> +// { dg-do compile }
> +
> +extern "C" float powf (float, float);
> +struct S { ~S (); };
> +double bar ();
> +double x;
> +
> +void
> +foo ()
> +{
> +  S s;
> +  x = powf (bar (), 2.);
> +}
>
> Jakub

RE: [AArch64, AArch64-4.7] Fix target ordering in config.gcc.

[Sofiane Naci]

Now with the patch properly attached.

Apologies.
Sofiane

> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Sofiane Naci
> Sent: 13 September 2012 13:18
> To: gcc-patches@gcc.gnu.org
> Subject: [AArch64, AArch64-4.7] Fix target ordering in config.gcc.
> 
> Hi,
> 
> I've just committed the attached patch on the branches
> 
>ARM/aarch64-branch
>ARM/aarch64-4.7-branch
> 
> to fix the target ordering in supported_defaults in config.gcc.
> 
> Thank you
> Sofiane
> 
> 
> 
> 


aarch64-fix-order-config.patch
Description: Binary data

Re: [PATCH] Rs6000 infrastructure cleanup (switches)

[Iain Sandoe]

Hello Michael, 

On 12 Sep 2012, at 23:43, Michael Meissner wrote:

>  It would be nice to know if this doesn't break the other ppc
> environments (AIX, Darwin) before I commit it.  Are there any problems with
> this patch? 

For powerpc-darwin9, there are a couple of issues which I've hacked around to 
get bootstrap to complete.

1. In rs6000.h

Where there are TARGET_XXX macros set to zero and guarded by config-time 
HAVE_AS_YYY (e.g. TARGET_POPCNTD, HAVE_AS_POPCNTD)
This causes an error when the #define TARGET_POPCNTD OPTION_POPCNTD is parsed.

For the sake of making progress, I just worked around these by moving the 
guarded defines to where the OPTION_XXXs are equated -- I.E: 

#ifndef HAVE_AS_XXX
#define TARGET_XXX 0
#else
#define TARGET_XXX OPTION_XXX
#endif

likely, that's not the Right Solution, but it allowed me to get to the next 
step -

2. rs6000_misc_flags{,explicit} and rs6000_debug_flags{,explicit} are declared 
as HOST_WIDE_INT which is 'long long' for this target.  This causes fails on 
lines 1841, 1842, 1844 and 1846 in rs6000.c because of mismatched format 
specifier and argument.  I just worked around this with a temporary definition 
of a suitable format descriptor.

With these two hacks, bootstrap completes for all langs including Java, Ada and 
ObjC++.
I haven't done any formal reg-tests yet, but a selection of checks across the 
board look reasonable so far.

If there is any other specific input that would be useful let me know - these 
older platforms are somewhat slow for the full build/test cycle.

cheers
Iain

[Patch, Fortran] PR54599 (4/n) FIx issues found by Coverity scann

[Tobias Burnus]

This patch fixes some of the issues collected in the PR.


Some remarks to the changed in the attached patch:


- gcc_assert (*format++ == '$');

That code gets executed when
 "some error message with value %d for string %s"
gets translated into
 "some error message for string %2$s with value %1$d"

And without the ++ gfortran doesn't skip over the $ sign.


+  gcc_assert (derived1 && derived2);
One of the many places where we first check for non-NULL - and then 
dereference the pointer unconditionally.



-  && ref->u.ar.as->lower && ref->u.ar.as->upper)

"lower" is an array of pointers but not a pointer itself - thus, "lower" 
is always != NULL. Ditto for upper.




- break;
+ continue;

It makes sense to walk through the loop more than once ;-)

+   size = int_size_in_bytes (type);
+   gcc_assert (size >= 0);

The function returns a HOST_WIDE_INT or  -1 if it doesn't fit  into that 
signed variable. To silence the warning, I now check the result and 
added an assert.



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

Tobias
2012-09-17  Tobias Burnus  

	* error.c (error_print): Move increment out of the assert.
	* interface.c (gfc_compare_derived_types): Add assert.
	(get_expr_storage_size): Remove always-true logical condition.
	* resolve.c (resolve_allocate_expr): Fix looping logic.
	* target-memory.c (gfc_target_expr_size): Add assert.

diff --git a/gcc/fortran/error.c b/gcc/fortran/error.c
index 64b9357..4b06156 100644
--- a/gcc/fortran/error.c
+++ b/gcc/fortran/error.c
@@ -536,23 +536,24 @@ error_print (const char *type, const char *format0, va_list argp)
 
   if (ISDIGIT (*format))
 	{
 	  /* This is a position specifier.  For example, the number
 	 12 in the format string "%12$d", which specifies the third
 	 argument of the va_list, formatted in %d format.
 	 For details, see "man 3 printf".  */
 	  pos = atoi(format) - 1;
 	  gcc_assert (pos >= 0);
 	  while (ISDIGIT(*format))
 	format++;
-	  gcc_assert (*format++ == '$');
+	  gcc_assert (*format == '$');
+	  format++;
 	}
   else
 	pos++;
 
   c = *format++;
 
   if (pos > maxpos)
 	maxpos = pos;
 
   switch (c)
 	{
diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index b348856..88689aa 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -388,27 +388,28 @@ gfc_match_end_interface (void)
 /* Compare two derived types using the criteria in 4.4.2 of the standard,
recursing through gfc_compare_types for the components.  */
 
 int
 gfc_compare_derived_types (gfc_symbol *derived1, gfc_symbol *derived2)
 {
   gfc_component *dt1, *dt2;
 
   if (derived1 == derived2)
 return 1;
 
+  gcc_assert (derived1 && derived2);
+
   /* Special case for comparing derived types across namespaces.  If the
  true names and module names are the same and the module name is
  nonnull, then they are equal.  */
-  if (derived1 != NULL && derived2 != NULL
-  && strcmp (derived1->name, derived2->name) == 0
+  if (strcmp (derived1->name, derived2->name) == 0
   && derived1->module != NULL && derived2->module != NULL
   && strcmp (derived1->module, derived2->module) == 0)
 return 1;
 
   /* Compare type via the rules of the standard.  Both types must have
  the SEQUENCE or BIND(C) attribute to be equal.  */
 
   if (strcmp (derived1->name, derived2->name))
 return 0;
 
   if (derived1->component_access == ACCESS_PRIVATE
@@ -2259,24 +2260,23 @@ get_expr_storage_size (gfc_expr *e)
 		else
 		  return 0;
 	  }
 	else if (ref->u.ar.as->upper[i]
 		 && ref->u.ar.as->upper[i]->expr_type == EXPR_CONSTANT)
 	  end = mpz_get_si (ref->u.ar.as->upper[i]->value.integer);
 	else
 	  return 0;
 
 	elements *= (end - start)/stride + 1L;
 	  }
-  else if (ref->type == REF_ARRAY && ref->u.ar.type == AR_FULL
-	   && ref->u.ar.as->lower && ref->u.ar.as->upper)
+  else if (ref->type == REF_ARRAY && ref->u.ar.type == AR_FULL)
 	for (i = 0; i < ref->u.ar.as->rank; i++)
 	  {
 	if (ref->u.ar.as->lower[i] && ref->u.ar.as->upper[i]
 		&& ref->u.ar.as->lower[i]->expr_type == EXPR_CONSTANT
 		&& ref->u.ar.as->upper[i]->expr_type == EXPR_CONSTANT)
 	  elements *= mpz_get_si (ref->u.ar.as->upper[i]->value.integer)
 			  - mpz_get_si (ref->u.ar.as->lower[i]->value.integer)
 			  + 1L;
 	else
 	  return 0;
 	  }
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 6a7b6c9..f67c07f 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -7419,23 +7419,23 @@ check_symbols:
   for (i = ar->dimen; i < ar->codimen + ar->dimen; i++)
 {
   if (ar->dimen_type[i] == DIMEN_ELEMENT
 	  || ar->dimen_type[i] == DIMEN_RANGE)
 	{
 	  if (i == (ar->dimen + ar->codimen - 1))
 	{
 	  gfc_error ("Expected '*' in coindex specification in ALLOCATE "
 			 "statement at %L", &e->where);
 	  goto failure;
 	}
-	  break;
+	  continue;
 	}
 
   if (ar->dimen_type[i] ==