Re: support operator list

2014-10-26 Thread Prathamesh Kulkarni 
Fixed a silly mistake in match-bitwise.pd (I had put ')' at wrong place).
This patch also checks if operator-list is used outside for-pattern
(in parser::parse_operation).

* genmatch.c
(user_id): Add new member is_oper_list.
(user_id::user_id): Add new default argument.
(parser::parse_operator_list): New member function in parser.
(add_substitute): New function.
(flatten_substitutes): Likewise.
(parser::parse_for): Call add_substitute.
(parser::parse_pattern): Call parser::parse_operator_list.
(parser::parse_operation): Put check for operator-list.

* match-bitwise.pd
(bitwise_ors): New operator-list.
(bitwise_ops): Likewise.
Use bitwise_ors and bitwise_ops in patterns.

* match-comparison.pd
 (eq_ops): New operator-list.
 (cmp_ops): Likewise.
 Use cmp_ops and eq_ops in patterns.

Thanks,
Prathamesh



On Sat, Oct 25, 2014 at 10:44 PM, Prathamesh Kulkarni
bilbotheelffri...@gmail.com wrote:
 Hi,
 This patch adds support for operator-lists, and uses
 them in match-bitwise.pd and match-comparison.pd

 * genmatch.c
 (parser::parse_operator_list): New member function in parser.
 (add_substitute): New function.
 (flatten_substitutes): Likewise.
 (parser::parse_for): Call add_substitute.
 (parser::parse_pattern): Call parser::parse_operator_list.

 * match-bitwise.pd
 (bitwise_ors): New operator-list.
 (bitwise_ops): Likewise.
 Use bitwise_ors and bitwise_ops in patterns.

 * match-comparison.pd
  (eq_ops): New operator-list.
  (cmp_ops): Likewise.
  Use cmp_ops and eq_ops in patterns.

 Thanks,
 Prathamesh
Index: gcc/genmatch.c
===
--- gcc/genmatch.c	(revision 216673)
+++ gcc/genmatch.c	(working copy)
@@ -218,9 +218,10 @@
 
 struct user_id : public id_base
 {
-  user_id (const char *id_)
-: id_base (id_base::USER, id_), substitutes (vNULL) {}
+  user_id (const char *id_, bool is_oper_list_ = false)
+: id_base (id_base::USER, id_), substitutes (vNULL), is_oper_list (is_oper_list_) {}
   vecid_base * substitutes;
+  bool is_oper_list;
 };
 
 template
@@ -2419,6 +2420,7 @@
   void parse_simplify (source_location, vecsimplify *, predicate_id *,
 		   expr *);
   void parse_for (source_location);
+  void parse_operator_list ();
   void parse_if (source_location);
   void parse_predicates (source_location);
 
@@ -2582,8 +2584,14 @@
 	   || strcmp  (id, convert2) == 0)
 fatal_at (id_tok, expected '?' after conditional operator);
   id_base *op = get_operator (id);
+
   if (!op)
 fatal_at (id_tok, unknown operator %s, id);
+  
+  user_id *uid;
+  if ((uid = dyn_castuser_id * (op)) != 0  uid-is_oper_list)
+fatal_at (id_tok, operator-list '%s' can be used only in for, uid-id);
+
   return op;
 }
 
@@ -2900,6 +2908,20 @@
 
 /* Parsing of the outer control structures.  */
 
+bool
+add_substitute (user_id *op, id_base *idb, int arity) 
+{
+  if (arity == -1)
+arity = idb-nargs;
+  else if (idb-nargs == -1)
+;
+  else if (idb-nargs != arity)
+return false;
+
+  op-substitutes.safe_push (idb);
+  return true;
+}
+  
 /* Parse a for expression
  for = '(' 'for' subst... pattern ')'
  subst = ident '(' ident... ')'  */
@@ -2938,15 +2960,16 @@
 	  if (*idb == CONVERT0 || *idb == CONVERT1 || *idb == CONVERT2)
 	fatal_at (token, conditional operators cannot be used inside for);
 
-	  if (arity == -1)
-	arity = idb-nargs;
-	  else if (idb-nargs == -1)
-	;
-	  else if (idb-nargs != arity)
-	fatal_at (token, operator '%s' with arity %d does not match 
-		  others with arity %d, oper, idb-nargs, arity);
+	  vecid_base * substitutes = vNULL;
+	  if (idb-kind == id_base::USER)
+	substitutes = (as_auser_id * (idb))-substitutes;
+	  else
+	substitutes.safe_push (idb);
 
-	  op-substitutes.safe_push (idb);
+	  for (unsigned si = 0; si  substitutes.length (); ++si)
+	if (!add_substitute (op, substitutes[si], arity))
+	  fatal_at (token, operator '%s' with arity %d does not match 
+			   others with arity %d, oper, idb-nargs, arity);
 	}
   op-nargs = arity;
   token = expect (CPP_CLOSE_PAREN);
@@ -2997,6 +3020,55 @@
 operators-remove_elt (user_ids[i]);
 }
 
+void
+flatten_substitutes (vecid_base * ids, vecid_base * substitutes)
+{
+  user_id *op;
+ 
+  for (unsigned i = 0; i  ids.length (); ++i)
+if ((op = dyn_castuser_id * (ids[i])) != 0)
+  flatten_substitutes (op-substitutes, substitutes);
+else
+  substitutes.safe_push (ids[i]);
+}
+
+void
+parser::parse_operator_list ()
+{
+  const char *id = get_ident ();
+  user_id *op = new user_id (id, true);
+  vecconst cpp_token * user_id_tokens = vNULL;
+
+  id_base **slot = operators-find_slot_with_hash (op, op-hashval, INSERT);
+  if (*slot)
+fatal (operator %s already defined, id);
+  *slot = op;
+
+  const cpp_token *token;
+  vecid_base * ids = vNULL;
+
+  while ((token = peek_ident ()) != 0)
+{
+

Re: genmatch infinite loop during bootstrap on AIX

2014-10-26 Thread Richard Biener 
On October 26, 2014 12:26:29 AM CEST, David Edelsohn dje@gmail.com wrote:
Richard,

I confirmed again with gcc111, which fails with r216632 and succeeds
with r216624.

Can you revert r216631 but still keep the r216632 fix? I suppose bootstrap 
before r216632 still fails on AIX?

I'll try to reproduce on ppc-linux tomorrow, otherwise I have to get myself a 
cfarm account.

Thanks,
Richard.

On my internal AIX system bootstrapping with GCC 4.7.3, it enters an
infinite loop in stage 1.  With gcc111 and bootstrapping with GCC
4.8.1, it enters an infinite loop in stage 2.

Thanks, David

On Sat, Oct 25, 2014 at 2:36 PM, David Edelsohn dje@gmail.com
wrote:
 Richard,

 There definitely seems to be something wrong with genmatch and the
 recent match-and-simplify patch (r216632).  Using a different,
 internal AIX system to speed up testing the potential causes of the
 problem, a tree at r216661 (just before Marxin's patch) hangs in
 genmatch during stage 1 bootstrap using G++ 4.7.3:

 (gdb) where
 #0  0x10068158 in std::allocatorchar::allocator() ()
 #1  0x1000b0b0 in _ZN6parser13parse_captureEP7operand
(this=0x2ff20974, op=0x0)
 at /nasfarm/edelsohn/src/src/gcc/genmatch.c:2607
 #2  0x1000b994 in _ZN6parser8parse_opEv (this=0x2ff20974)
 at /nasfarm/edelsohn/src/src/gcc/genmatch.c:2767
 #3  0x1000b4f4 in _ZN6parser10parse_exprEv (this=0x2ff20974)
 at /nasfarm/edelsohn/src/src/gcc/genmatch.c:2669
 #4  0x1000b7c0 in _ZN6parser8parse_opEv (this=0x2ff20974)
 at /nasfarm/edelsohn/src/src/gcc/genmatch.c:2728
 #5  0x1000ba4c in

_ZN6parser14parse_simplifyEjR3vecIP8simplify7va_heap6vl_ptrEP12predicate_idP4expr
 (this=0x2ff20974, match_location=4614, simplifiers=...,
 matcher=0x0, result=0x0) at
/nasfarm/edelsohn/src/src/gcc/genmatch.c:2792
 #6  0x1000c868 in _ZN6parser13parse_patternEv (this=0x2ff20974)
 at /nasfarm/edelsohn/src/src/gcc/genmatch.c:3052
 #7  0x1000c544 in _ZN6parser9parse_forEj (this=0x2ff20974)
 at /nasfarm/edelsohn/src/src/gcc/genmatch.c:2991
 #8  0x1000cb1c in _ZN6parser13parse_patternEv (this=0x2ff20974)
 at /nasfarm/edelsohn/src/src/gcc/genmatch.c:3090
 #9  0x1000cd78 in _ZN6parserC2EP10cpp_reader (this=0x2ff20974,
r_=0x3000c8e8)
 at /nasfarm/edelsohn/src/src/gcc/genmatch.c:3122
 #10 0x10011614 in main (argc=3, argv=0x2ff20a3c)
 at /nasfarm/edelsohn/src/src/gcc/genmatch.c:3204

 r216624 (after Maxim's sched patches and before your
 match-and-simplify patch) does not have a problem on gcc111.

 - David


 On Sat, Oct 25, 2014 at 1:18 PM, David Edelsohn dje@gmail.com
wrote:
 Bootstrap succeeds with Maxim's patch (r216624).

 The other, significant changes I see on trunk between r216624 and
r216674 are:

 match-and-simplify through r216632
 ipc-icf in r216662
 libstdc++ in r216667

 No other patches to trunk *seem* like they should affect PPC
bootstrap.

 - David


 On Sat, Oct 25, 2014 at 10:04 AM, David Edelsohn dje@gmail.com
wrote:
 It may be fallout from Maxim's scheduler patch.  I'm testing that.
 Backing up before Maxim's patch and your genmatch patch does not
enter
 an endless loop.

 - David

 On Sat, Oct 25, 2014 at 4:06 AM, Richard Biener rguent...@suse.de
wrote:
 On October 25, 2014 1:33:39 AM CEST, David Edelsohn
dje@gmail.com wrote:
genmatch is hanging when bootstrapping on AIX (gcc111).  When I
attach
to the process:

#0  0x1007efac in std::basic_stringchar, std::char_traitschar,
std::allocatorchar ::basic_string ()
#1  0x1000e6b0 in _ZN6parser13parse_captureEP7operand
(this=0x300594b8,
op=0x0)
at /home/dje/src/src/gcc/genmatch.c:2607

 Does it really hang in libstdc++ or does it loop somewhere in
genmatch? Is this stage1 or later?

 Does this happen only after the 2nd part of the merge went in?
That is, what revision?

 Thanks,
 Richard.

#2  0x1000e9f0 in _ZN6parser10parse_exprEv (this=0x2ff20208)
at /home/dje/src/src/gcc/genmatch.c:2669
#3  0x1000ee38 in _ZN6parser8parse_opEv (this=0x2ff20208)
at /home/dje/src/src/gcc/genmatch.c:2728
#4  0x1000efc4 in
_ZN6parser14parse_simplifyEjR3vecIP8simplify7va_heap6vl_ptrEP12predicate_idP4expr
(this=0x2ff20208, match_location=4614, simplifiers=...,
matcher=0x0, result=0x0) at
/home/dje/src/src/gcc/genmatch.c:2792
#5  0x100102fc in _ZN6parser13parse_patternEv (this=0x2ff20208)
at /home/dje/src/src/gcc/genmatch.c:3052
#6  0x10010c0c in _ZN6parser9parse_forEj (this=0x2ff20208)
at /home/dje/src/src/gcc/genmatch.c:2991
#7  0x10010350 in _ZN6parser13parse_patternEv (this=0x2ff20208)
at /home/dje/src/src/gcc/genmatch.c:3090
#8  0x1001122c in _ZN6parserC2EP10cpp_reader (this=0x2ff20208,
r_=0x3003bbec)
at /home/dje/src/src/gcc/genmatch.c:3122
#9  0x10004acc in main (argc=error reading variable,
argv=error reading variable) at  _start_ :3204

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

2014-10-26 Thread Chen Gang 
On 10/22/2014 09:34 AM, Chen Gang wrote:
 

 Yes, if you want to test on a target, you will need a target.  You can 
 either have a simulator (see binutils and sim/* for an example of how to 
 write one) or target hardware in some form.


After tried 'sim', I found the root cause is microblaze sim does not
support '--sysroot', which is the environments for shared libraries and
system calls (need load microblaze kernel).

 - microblaze can successfully execute simple programs which has no
   glibc and no system call.

 - In upstream master branch of binutils, for microblaze sim, it has no
   related testsuite for sim in binutils, neither support '--sysroot',
   neither support function stack, startup parameters, and environments.

 - After hard code the default stack in sim, it can start the '-static'
   program with glibc, but stop at uname() which will use system call.

So I want to consult: at present, can we let microblaze sim run 'normal'
programs (have glibc, and use system call)?


If it does not support, I have to rewind to qemu. If it really happens,
it seems I can not finish gcc testsuite with target within this month.
(although I have several excuses) :-(

Thanks.

 
 I will continue sim, and should try to finish within 2014-10-31. Sorry,
 my other things which related open source maybe be delayed (maybe can
 not finish within this month, if happens, need finish within next month).
 

 After trying sim, for me, it is really useful way for test, although I
 also met issues:

 For a hello world C program, microblaze gcc succeeded building, gdb can
 load and display the source code, and disassembe code successfully, but
 sim reported failure, the related issue is below:

   [root@localhost test]# /upstream/release/bin/microblaze-gchen-linux-run 
 ./test
   Loading section .interp, size 0xd vma 0x10f4
   Loading section .note.ABI-tag, size 0x20 vma 0x1104
   Loading section .hash, size 0x24 vma 0x1124
   Loading section .dynsym, size 0x40 vma 0x1148
   Loading section .dynstr, size 0x3c vma 0x1188
   Loading section .gnu.version, size 0x8 vma 0x11c4
   Loading section .gnu.version_r, size 0x20 vma 0x11cc
   Loading section .rela.dyn, size 0x24 vma 0x11ec
   Loading section .rela.plt, size 0x24 vma 0x1210
   Loading section .init, size 0x58 vma 0x1234
   Loading section .plt, size 0x44 vma 0x128c
   Loading section .text, size 0x3d0 vma 0x12d0
   Loading section .fini, size 0x34 vma 0x16a0
   Loading section .rodata, size 0x12 vma 0x16d4
   Loading section .eh_frame, size 0x4 vma 0x16e8
   Loading section .ctors, size 0x8 vma 0x100016ec
   Loading section .dtors, size 0x8 vma 0x100016f4
   Loading section .jcr, size 0x4 vma 0x100016fc
   Loading section .dynamic, size 0xd0 vma 0x10001700
   Loading section .got, size 0xc vma 0x100017d0
   Loading section .got.plt, size 0x18 vma 0x100017dc
   Loading section .data, size 0x10 vma 0x100017f4
   Start address 0x12d0
   Transfer rate: 14424 bits in 1 sec.
   ERROR: Unknown opcode
   program stopped with signal 4.

 For me, I guess it is sim's issue, and I shall try to fix it in the next
 month, so sorry, I can not finish emulator for microblaze within this
 month. :-(


 Welcome any ideas, suggestions or completions.

 Thanks.

 


-- 
Chen Gang

Open share and attitude like air water and life which God blessed

[committed] Fix signal trampoline detection on hppa-linux

2014-10-26 Thread John David Anglin 
The attached change fixes an unwind problem during pthread  
cancellation.  For threads,
it turns out the return address is not marked as undefined.  As a  
result, pa32_fallback_frame_state
is called with an invalid context and the code generates a  
segmentation fault looking for
the signal trampoline.  This causes 30_threads/thread/native_handle/ 
cancel.cc and a number

of glibc tests to fail.

This change adds code to test whether the read accesses in  
pa32_fallback_frame_state are ok.
This prevents the segmentation fault and the outer most frame is now  
detected correctly.


Tested on hppa-unknown-linux-gnu.  Committed to trunk, 4.9 and 4.8.

Dave
--
John David Anglin   dave.ang...@bell.net


2014-10-26  John David Anglin  dang...@gcc.gnu.org

* config/pa/linux-unwind.h (pa32_read_access_ok): New function.
(pa32_fallback_frame_state): Use pa32_read_access_ok to check if
memory read accesses are ok.

Index: config/pa/linux-unwind.h
===
--- config/pa/linux-unwind.h(revision 216531)
+++ config/pa/linux-unwind.h(working copy)
@@ -32,6 +32,17 @@
 #include signal.h
 #include sys/ucontext.h
 
+/* Return TRUE if read access to *P is allowed.  */
+
+static inline long
+pa32_read_access_ok (void *p)
+{
+  long ret;
+
+  __asm__ (proberi (%1),3,%0 : =r (ret) : r (p) :);
+  return ret;
+}
+
 /* Unfortunately, because of various bugs and changes to the kernel,
we have several cases to deal with.
 
@@ -48,8 +59,13 @@
tell us how to locate the sigcontext structure.
 
Note that with a 2.4 64-bit kernel, the signal context is not properly
-   passed back to userspace so the unwind will not work correctly.  */
+   passed back to userspace so the unwind will not work correctly.
 
+   There is also a bug in various glibc versions.  The (CONTEXT)-ra
+   for the outermost frame is not marked as undefined, so we need to
+   check whether read access is allowed for all the accesses used in
+   searching for the signal trampoline.  */
+
 #define MD_FALLBACK_FRAME_STATE_FOR pa32_fallback_frame_state
 
 static _Unwind_Reason_Code
@@ -73,14 +89,17 @@
  e4008200 be,l 0x100(%sr2, %r0), %sr0, %r31
  08000240 nop  */
 
-  if (pc[0] == 0x3419 || pc[0] == 0x34190002)
+  if (pa32_read_access_ok (pc)
+   (pc[0] == 0x3419 || pc[0] == 0x34190002))
 off = 4*4;
-  else if (pc[4] == 0x3419 || pc[4] == 0x34190002)
+  else if (pa32_read_access_ok (pc[4])
+   (pc[4] == 0x3419 || pc[4] == 0x34190002))
 {
   pc += 4;
   off = 10 * 4;
 }
-  else if (pc[5] == 0x3419 || pc[5] == 0x34190002)
+  else if (pa32_read_access_ok (pc[5])
+   (pc[5] == 0x3419 || pc[5] == 0x34190002))
 {
   pc += 5;
   off = 10 * 4;
@@ -96,13 +115,16 @@
 word boundary and we can then determine the frame offset.  */
   sp = (unsigned long)context-ra;
   pc = (unsigned int *)sp;
-  if ((pc[0] == 0x3419 || pc[0] == 0x34190002)  (sp  4))
+  if ((sp  4)
+  pa32_read_access_ok (pc)
+  (pc[0] == 0x3419 || pc[0] == 0x34190002))
off = 5 * 4;
   else
return _URC_END_OF_STACK;
 }
 
-  if (pc[1] != 0x3414015a
+  if (!pa32_read_access_ok (pc[3])
+  || pc[1] != 0x3414015a
   || pc[2] != 0xe4008200
   || pc[3] != 0x08000240)
 return _URC_END_OF_STACK;

Re: [microblaze] RFA: Use new rtl iterators in microblaze_tls_referenced_p

2014-10-26 Thread Michael Eager 

On 10/25/14 03:05, Richard Sandiford wrote:

This is part of a series to remove uses of for_each_rtx from the ports.

Tested by making sure there were no code changes for gcc.dg, gcc.c-torture
and g++.dg for microblaze-elf.  OK to install?


Yes, this is OK.  Please check for trailing whitespace.



Thanks,
Richard


gcc/
* config/microblaze/microblaze.c: Include rtl-iter.h.
(microblaze_tls_referenced_p_1): Delete.
(microblaze_tls_referenced_p): Use FOR_EACH_SUBRTX.

Index: gcc/config/microblaze/microblaze.c
===
--- gcc/config/microblaze/microblaze.c  2014-10-25 09:40:37.967516501 +0100
+++ gcc/config/microblaze/microblaze.c  2014-10-25 09:51:27.863905096 +0100
@@ -56,6 +56,7 @@
  #include diagnostic-core.h
  #include cgraph.h
  #include builtins.h
+#include rtl-iter.h

  #define MICROBLAZE_VERSION_COMPARE(VA,VB) strcasecmp (VA, VB)

@@ -444,20 +445,6 @@ microblaze_tls_symbol_p (rtx x)
return SYMBOL_REF_TLS_MODEL (x) != 0;
  }

-static int
-microblaze_tls_operand_p_1 (rtx *x, void *data ATTRIBUTE_UNUSED)
-{
-  if (GET_CODE (*x) == SYMBOL_REF)
-return SYMBOL_REF_TLS_MODEL (*x) != 0;
-
-  /* Don't recurse into UNSPEC_TLS looking for TLS symbols; these are
- TLS offsets, not real symbol references.  */
-  if (GET_CODE (*x) == UNSPEC  XINT (*x, 1) == UNSPEC_TLS)
-return -1;
-
-  return 0;
-}
-
  /* Return TRUE if X contains any TLS symbol references.  */

  bool
@@ -465,8 +452,18 @@ microblaze_tls_referenced_p (rtx x)
  {
if (!TARGET_HAVE_TLS)
  return false;
-
-  return for_each_rtx (x, microblaze_tls_operand_p_1, NULL);
+  subrtx_iterator::array_type array;
+  FOR_EACH_SUBRTX (iter, array, x, ALL)
+{
+  const_rtx x = *iter;
+  if (GET_CODE (x) == SYMBOL_REF  SYMBOL_REF_TLS_MODEL (x) != 0)
+   return true;
+  /* Don't recurse into UNSPEC_TLS looking for TLS symbols; these are
+TLS offsets, not real symbol references.  */
+  if (GET_CODE (x) == UNSPEC  XINT (x, 1) == UNSPEC_TLS)
+   iter.skip_subrtxes ();
+}
+  return false;
  }

  bool




--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: [PATCH] Fix PR63266: Keep track of impact of sign extension in bswap

2014-10-26 Thread Christophe Lyon 
On 22 October 2014 10:56, Thomas Preud'homme thomas.preudho...@arm.com wrote:
 From: Christophe Lyon [mailto:christophe.l...@linaro.org]
 Sent: Tuesday, October 21, 2014 10:03 PM
  +typedef int SItype __attribute__ ((mode (SI)));
 What's the purpose of this? It seems unused.

 Sigh. Bad copy/paste from optimize-bswapsi-1.c

 I'll add it to my patch for pr63259.


 I believe this should be:
 checks that unknown byte markers are set correctly in case of cast

 Indeed, there is a 's' missing for markers.


  +
  +HItype
  +swap16 (HItype in)
  +{
  +  return (HItype) (((in  0)  0xFF)  8)
  +   | (((in  8)  0xFF)  0);
  +}
  +
   /* { dg-final { scan-tree-dump-times 16 bit load in target endianness
 found at 3 bswap } } */
  -/* { dg-final { scan-tree-dump-times 16 bit bswap implementation
 found at 3 bswap { xfail alpha*-*-* arm*-*-* } } } */
  +/* { dg-final { scan-tree-dump-times 16 bit bswap implementation
 found at 1 bswap { target alpha*-*-* arm*-*-* } } } */

 This line fails when forcing the compiler to target -march=armv5t for
 instance. I suspect this is because the check_effective_target_bswap
 test is too permissive.

 Yep, it's likely to be the case. Feel to add a version check in it.

I tried to modify check_effective_target_bswap
and added:
+   } else {
+   if { [istarget arm*-*-*]
+ [check_no_compiler_messages_nocache arm_v6_or_later object {
+#if __ARM_ARCH  6
+#error not armv6 or later
+#endif
+int i;
+} ] } {
+   set et_bswap_saved 1
+   }
since the rev* instructions appeared in v6.

Regarding the testsuite, it moves the tests to UNSUPPORTED vs a mix of
PASS/FAIL/XFAIL
 UNSUPPORTED: gcc.dg/optimize-bswaphi-1.c
 UNSUPPORTED: gcc.dg/optimize-bswapsi-1.c
 UNSUPPORTED: gcc.dg/optimize-bswapsi-2.c
---
 PASS: gcc.dg/optimize-bswaphi-1.c (test for excess errors)
 FAIL: gcc.dg/optimize-bswaphi-1.c scan-tree-dump-times bswap 16 bit bswap 
 implementation found at 1
 XFAIL: gcc.dg/optimize-bswaphi-1.c scan-tree-dump-times bswap 16 bit bswap 
 implementation found at 4
 PASS: gcc.dg/optimize-bswaphi-1.c scan-tree-dump-times bswap 16 bit load in 
 target endianness found at 3
 PASS: gcc.dg/optimize-bswapsi-1.c (test for excess errors)
 PASS: gcc.dg/optimize-bswapsi-1.c scan-tree-dump-times bswap 32 bit bswap 
 implementation found at 4
 PASS: gcc.dg/optimize-bswapsi-2.c (test for excess errors)
 XFAIL: gcc.dg/optimize-bswapsi-2.c scan-tree-dump-times bswap 32 bit bswap 
 implementation found at 3
 PASS: gcc.dg/optimize-bswapsi-2.c scan-tree-dump-times bswap 32 bit load in 
 target endianness found at 3

The PASS seems not very informative, so it may not be a problem to
loose these few PASS/XFAIL.

We can also explicitly skip optimize-bswaphi-1 when ARM_ARCH  6.

Not sure what's preferred?

Christophe.

 Thanks for the review.

 Best regards,

 Thomas

Re: [Patch ARM-AArch64/testsuite v3 00/21] Neon intrinsics executable tests

2014-10-26 Thread Christophe Lyon 
On 24 October 2014 10:07, Marcus Shawcroft marcus.shawcr...@gmail.com wrote:
 On 21 October 2014 14:02, Christophe Lyon christophe.l...@linaro.org wrote:
 This patch series is an updated version of the series I sent here:
 https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00022.html

 I addressed comments from Marcus and Richard, and decided to skip
 support for half-precision variants for the time being. I'll post
 dedicated patches later.

 Compared to v2:
 - the directory containing the new tests is named
   gcc.target/aarch64/adv-simd instead of
   gcc.target/aarch64/neon-intrinsics.
 - the driver is named adv-simd.exp instead of neon-intrinsics.exp
 - the driver is guarded against the new test parallelization framework
 - the README file uses 'Advanced SIMD (Neon)' instead of 'Neon'


 Thank you Christophe.  Please commit all 21 patches in the series.

Thanks, I have committed the whole series.

I've just realized afterwards that the tests aren't guarded against
targets not supporting Neon.

How about adding the attached small patch?

(ChangeLog incorrectly formatted :-()
2014-10-26  Christophe Lyon  christophe.l...@linaro.org

gcc.target/aarch64/advsimd-intrinsics/advsimd-intrinsics.exp: Skip
tests if target does not support Neon.


Christophe

 /Marcus
diff --git a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/advsimd-intrinsics.exp b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/advsimd-intrinsics.exp
index 3aa0e1c..938086b 100644
--- a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/advsimd-intrinsics.exp
+++ b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/advsimd-intrinsics.exp
@@ -32,6 +32,11 @@ load_lib torture-options.exp
 
 dg-init
 
+if {[istarget arm*-*-*]
+ ![check_effective_target_arm_neon_ok]} then {
+  return
+}
+
 torture-init
 set-torture-options $C_TORTURE_OPTIONS {{}} $LTO_TORTURE_OPTIONS

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

2014-10-26 Thread Michael Eager 

On 10/26/14 03:36, Chen Gang wrote:

On 10/22/2014 09:34 AM, Chen Gang wrote:




Yes, if you want to test on a target, you will need a target.  You can either 
have a simulator (see binutils and sim/* for an example of how to write one) or 
target hardware in some form.



After tried 'sim', I found the root cause is microblaze sim does not
support '--sysroot', which is the environments for shared libraries and
system calls (need load microblaze kernel).

  - microblaze can successfully execute simple programs which has no
glibc and no system call.

  - In upstream master branch of binutils, for microblaze sim, it has no
related testsuite for sim in binutils, neither support '--sysroot',
neither support function stack, startup parameters, and environments.

  - After hard code the default stack in sim, it can start the '-static'
program with glibc, but stop at uname() which will use system call.

So I want to consult: at present, can we let microblaze sim run 'normal'
programs (have glibc, and use system call)?


Microblaze-sim provides basic instruction set architecture and memory 
simulation.
There is no operating system support.  (It's also quite old.  I'm not sure
which version of the MB architecture it models, but it is not recent.)

Microblaze-sim is not a full system simulator, like QEMU.  To be able to
run a program which requires glibc, you need to be able to boot a full Linux
image on the simulator, which microblaze-sim cannot do.  QEMU models an
entire processor and can boot a Linux image.

--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: [PATCH diagnostics] PR 53061 cleanup initialization

2014-10-26 Thread Manuel López-Ibáñez 
I committed this as https://gcc.gnu.org/r216720 following all your
comments except for:


On 23 October 2014 12:31, Dodji Seketeli do...@redhat.com wrote:
 +
 +/* Construct a C++-aware pretty-printer for CONTEXT.  It is assumed
 +   that CONTEXT-printer is an already constructed basic pretty_printer.  */

 I'd be even more specific in the comment by saying that CONTEXT-printer
 is a basic pretty printer that was constructed presumably by
 diagnostic_initialize(), called early in the compiler's initialization
 process (in general_init) Before the FE is initialized.  This (C++)
 FE-specific diagnostic initializer is thus replacing the basic pretty
 printer with one that has C++-aware capacities.

 Or maybe write this generic big-picture awareness comment before the
 diagnostic_context::printer data member.  If you don't have time for
 this, I'll do it myself in a subsequent patch.  I am writing this, also
 for myself, as a reminder :-)

I did the former and not the latter because the basic pp does not need
to be overridden, the FEs can do it but they don't need to. Thus, I
was not sure what you really wanted me to write in diagnostic.h The
current comment is:

/* Where most of the diagnostic formatting work is done.  */
  pretty_printer *printer;

which admittedly is not that informative.

Cheers,

Manuel.

[Patch] Improving jump-thread pass for PR 54742

2014-10-26 Thread Sebastian Pop 
Sebastian Pop wrote:
 Jeff Law wrote:
  On 08/21/14 04:30, Richard Biener wrote:
  It turns Jeff's jump-threading code in to a strange franken-pass of bits 
  and
  pieces of detection and optimisation, and would need some substantial
  reworking to fit in with Jeff's changes last Autumn, but if it is more
  likely to be acceptable for trunk then perhaps we could look to revive it.
  It would be nice to reuse the path copy code Jeff added last year, but I
  don't have much intuition as to how feasible that is.
  
  Was this the sort of thing that you were imagining?
  
  Yeah, didn't look too closely though.
  It'd be pretty ugly I suspect.  But it's probably worth pondering
  since that approach would eliminate the concerns about the cost of
  detection (which is problematical for the jump threader) by using
  Steve's code for that.
  
  On the update side, I suspect most, if not all of the framework is
  in place to handle this kind of update if the right threading paths
  were passed to the updater.  I can probably cobble together that
  by-hand and see what the tree-ssa-threadupdate does with it.  But
  it'll be a week or so before I could look at it.
 
 I adapted the patch James has sent last year to use the new update paths

Attached an updated version of the patch.

 mechanism.  I verified that the attached patch does register all the paths 
 that
 need to be threaded.  Thread updater seems to have some problems handling the
 attached testcase (a simplified version of the testcase attached to the bug.)
 
 Jeff, could you please have a look at why the jump-thread updater is crashing?

I have tried to understand why the code generation part ICEs on coremark: the
first problem that I have seen is that tree-ssa-threadupdate.c does not handle
more than a joiner block per path to be threaded, so we would not be able to
jump thread accross the joiners of the if condition and the joiner of the switch
condition: i.e., these paths

patch:   Registering jump thread: (7, 10) incoming edge;  (10, 25) joiner;  
(25, 26) joiner;  (26, 4) nocopy; (4, 37) nocopy; (37, 36) nocopy; (36, 14) 
nocopy;
patch:   Registering jump thread: (28, 10) incoming edge;  (10, 25) joiner;  
(25, 26) joiner;  (26, 4) nocopy; (4, 37) nocopy; (37, 36) nocopy; (36, 11) 
nocopy;
patch:   Registering jump thread: (8, 10) incoming edge;  (10, 25) joiner;  
(25, 26) joiner;  (26, 4) nocopy; (4, 37) nocopy; (37, 36) nocopy; (36, 17) 
nocopy;
patch:   Registering jump thread: (9, 10) incoming edge;  (10, 25) joiner;  
(25, 26) joiner;  (26, 4) nocopy; (4, 37) nocopy; (37, 36) nocopy; (36, 25) 
nocopy;

Another problem is that we attach the path to be threaded to the -aux field of
the first edge in the path, such that we would have to cancel some of the paths
because we cannot keep track of all the paths to be threaded.

For coremark, we would discover some jump-thread paths from one of the switch
cases over the loop exit condition, either to bb_27 outside the loop, or to bb_4
staying inside the loop.  Then with the patch: we would discover jump threads
that would thread switch cases to switch cases, and because these paths start
with the same edges for which we have already assigned a path to e-aux, we
would have to cancel the interesting threads added by the patch:

  Registering jump thread: (12, 25) incoming edge;  (25, 26) joiner;  (26, 4) 
nocopy;
  Registering jump thread: (13, 25) incoming edge;  (25, 26) joiner;  (26, 27) 
nocopy;
  Registering jump thread: (29, 25) incoming edge;  (25, 26) joiner;  (26, 4) 
nocopy;
  Registering jump thread: (31, 25) incoming edge;  (25, 26) joiner;  (26, 27) 
nocopy;
  Registering jump thread: (16, 25) incoming edge;  (25, 26) joiner;  (26, 4) 
nocopy;
  Registering jump thread: (15, 25) incoming edge;  (25, 26) joiner;  (26, 4) 
nocopy;
  Registering jump thread: (32, 25) incoming edge;  (25, 26) joiner;  (26, 27) 
nocopy;
  Registering jump thread: (19, 25) incoming edge;  (25, 26) joiner;  (26, 4) 
nocopy;
  Registering jump thread: (18, 25) incoming edge;  (25, 26) joiner;  (26, 4) 
nocopy;
  Registering jump thread: (22, 25) incoming edge;  (25, 26) joiner;  (26, 27) 
nocopy;
  Registering jump thread: (21, 25) incoming edge;  (25, 26) joiner;  (26, 4) 
nocopy;
  Registering jump thread: (34, 25) incoming edge;  (25, 26) joiner;  (26, 27) 
nocopy;
  Registering jump thread: (33, 25) incoming edge;  (25, 26) joiner;  (26, 4) 
nocopy;
  Registering jump thread: (35, 25) incoming edge;  (25, 26) joiner;  (26, 27) 
nocopy;
  Registering jump thread: (24, 25) incoming edge;  (25, 26) joiner;  (26, 4) 
nocopy;
patch:   Registering jump thread: (12, 25) incoming edge;  (25, 26) joiner;  
(26, 4) nocopy; (4, 37) nocopy; (37, 36) nocopy; (36, 17) nocopy;
patch:   Registering jump thread: (16, 25) incoming edge;  (25, 26) joiner;  
(26, 4) nocopy; (4, 37) nocopy; (37, 36) nocopy; (36, 14) nocopy;
patch:   Registering jump thread: (19, 25) incoming edge;  (25, 26) joiner;  
(26, 4) nocopy; (4, 37)

Fwd: g++ off-by-one bug in utf16 conversion

2014-10-26 Thread John Schmerge 
I believe I sent this yesterday to the incorrect list...


-- Forwarded message --
From: John Schmerge jbschme...@gmail.com
Date: Sun, Oct 26, 2014 at 1:58 AM
Subject: g++ off-by-one bug in utf16 conversion
To: gcc-b...@gcc.gnu.org


Hey guys,

I came across this bug earlier today in implementing some
unit tests for utf8/16 conversions... The following c++
fragment gives the wrong result:

int main() {
  char16_t s[] = u\u;
  std::cout  std::hex  s[0] s[1]  std::endl;
}

it prints:
  d7ff dfff
where as it should print:
   0
For those unfamiliar with utf16, all unicode values less than
or equal to 0x remain 16 bit values and no conversion is
done on them, code points greater than 0x get converted
to a pair of 16-bit shorts, where the 1st is in the range
0xd800-dbff and the 2nd is in the range 0xdc00-d.

Clearly this is an off-by-one issue. I traced it down to a
use of a less-than operator vs less-than-equal operator in
libcpp/charset.c

I have verified this is a bug with versions 4.4.7 (rhel 6.5),
4.8.2 (linaro/ubuntu/mint) and g++ (GCC) 5.0.0 20141025...
I am a bit surprised  that this has gone so many years unnoticed
or at least unresolved.

Attached is a patch against gcc 4.8.2 from the gcc website for
the issue to $gcc-root/libcpp/charset.c that fixes the issue by my tests.

Thanks,
John
--- libcpp/charset.c	2014-10-26 01:24:10.583796875 -0400
+++ libcpp/charset.c.old	2014-10-26 01:23:50.103796842 -0400
@@ -353,7 +353,7 @@
   return EILSEQ;
 }
 
-  if (s = 0x)
+  if (s  0x)
 {
   if (*outbytesleftp  2)
 	{

Re: [patch] only emit one DIE for external declarations in the local scope

2014-10-26 Thread Jason Merrill 

OK.

Jason

Re: genmatch infinite loop during bootstrap on AIX

2014-10-26 Thread David Edelsohn 
Richi,

Does genmatch rely on static constructors or implicitly rely on the
order of static constructors? Sometimes those cause problems on AIX.

Bootstrap on AIX succeeds prior to r216631, e.g., r216624.  It works
after your commit r216619 to correct Makefile.in, or prior to that by
manually editing Makefile.in to add LIBICONV and LIBINTL.

Thanks, David

On Sun, Oct 26, 2014 at 5:36 AM, Richard Biener rguent...@suse.de wrote:
 On October 26, 2014 12:26:29 AM CEST, David Edelsohn dje@gmail.com 
 wrote:
Richard,

I confirmed again with gcc111, which fails with r216632 and succeeds
with r216624.

 Can you revert r216631 but still keep the r216632 fix? I suppose bootstrap 
 before r216632 still fails on AIX?

 I'll try to reproduce on ppc-linux tomorrow, otherwise I have to get myself a 
 cfarm account.

 Thanks,
 Richard.

On my internal AIX system bootstrapping with GCC 4.7.3, it enters an
infinite loop in stage 1.  With gcc111 and bootstrapping with GCC
4.8.1, it enters an infinite loop in stage 2.

Thanks, David

On Sat, Oct 25, 2014 at 2:36 PM, David Edelsohn dje@gmail.com
wrote:
 Richard,

 There definitely seems to be something wrong with genmatch and the
 recent match-and-simplify patch (r216632).  Using a different,
 internal AIX system to speed up testing the potential causes of the
 problem, a tree at r216661 (just before Marxin's patch) hangs in
 genmatch during stage 1 bootstrap using G++ 4.7.3:

 (gdb) where
 #0  0x10068158 in std::allocatorchar::allocator() ()
 #1  0x1000b0b0 in _ZN6parser13parse_captureEP7operand
(this=0x2ff20974, op=0x0)
 at /nasfarm/edelsohn/src/src/gcc/genmatch.c:2607
 #2  0x1000b994 in _ZN6parser8parse_opEv (this=0x2ff20974)
 at /nasfarm/edelsohn/src/src/gcc/genmatch.c:2767
 #3  0x1000b4f4 in _ZN6parser10parse_exprEv (this=0x2ff20974)
 at /nasfarm/edelsohn/src/src/gcc/genmatch.c:2669
 #4  0x1000b7c0 in _ZN6parser8parse_opEv (this=0x2ff20974)
 at /nasfarm/edelsohn/src/src/gcc/genmatch.c:2728
 #5  0x1000ba4c in

_ZN6parser14parse_simplifyEjR3vecIP8simplify7va_heap6vl_ptrEP12predicate_idP4expr
 (this=0x2ff20974, match_location=4614, simplifiers=...,
 matcher=0x0, result=0x0) at
/nasfarm/edelsohn/src/src/gcc/genmatch.c:2792
 #6  0x1000c868 in _ZN6parser13parse_patternEv (this=0x2ff20974)
 at /nasfarm/edelsohn/src/src/gcc/genmatch.c:3052
 #7  0x1000c544 in _ZN6parser9parse_forEj (this=0x2ff20974)
 at /nasfarm/edelsohn/src/src/gcc/genmatch.c:2991
 #8  0x1000cb1c in _ZN6parser13parse_patternEv (this=0x2ff20974)
 at /nasfarm/edelsohn/src/src/gcc/genmatch.c:3090
 #9  0x1000cd78 in _ZN6parserC2EP10cpp_reader (this=0x2ff20974,
r_=0x3000c8e8)
 at /nasfarm/edelsohn/src/src/gcc/genmatch.c:3122
 #10 0x10011614 in main (argc=3, argv=0x2ff20a3c)
 at /nasfarm/edelsohn/src/src/gcc/genmatch.c:3204

 r216624 (after Maxim's sched patches and before your
 match-and-simplify patch) does not have a problem on gcc111.

 - David


 On Sat, Oct 25, 2014 at 1:18 PM, David Edelsohn dje@gmail.com
wrote:
 Bootstrap succeeds with Maxim's patch (r216624).

 The other, significant changes I see on trunk between r216624 and
r216674 are:

 match-and-simplify through r216632
 ipc-icf in r216662
 libstdc++ in r216667

 No other patches to trunk *seem* like they should affect PPC
bootstrap.

 - David


 On Sat, Oct 25, 2014 at 10:04 AM, David Edelsohn dje@gmail.com
wrote:
 It may be fallout from Maxim's scheduler patch.  I'm testing that.
 Backing up before Maxim's patch and your genmatch patch does not
enter
 an endless loop.

 - David

 On Sat, Oct 25, 2014 at 4:06 AM, Richard Biener rguent...@suse.de
wrote:
 On October 25, 2014 1:33:39 AM CEST, David Edelsohn
dje@gmail.com wrote:
genmatch is hanging when bootstrapping on AIX (gcc111).  When I
attach
to the process:

#0  0x1007efac in std::basic_stringchar, std::char_traitschar,
std::allocatorchar ::basic_string ()
#1  0x1000e6b0 in _ZN6parser13parse_captureEP7operand
(this=0x300594b8,
op=0x0)
at /home/dje/src/src/gcc/genmatch.c:2607

 Does it really hang in libstdc++ or does it loop somewhere in
genmatch? Is this stage1 or later?

 Does this happen only after the 2nd part of the merge went in?
That is, what revision?

 Thanks,
 Richard.

#2  0x1000e9f0 in _ZN6parser10parse_exprEv (this=0x2ff20208)
at /home/dje/src/src/gcc/genmatch.c:2669
#3  0x1000ee38 in _ZN6parser8parse_opEv (this=0x2ff20208)
at /home/dje/src/src/gcc/genmatch.c:2728
#4  0x1000efc4 in
_ZN6parser14parse_simplifyEjR3vecIP8simplify7va_heap6vl_ptrEP12predicate_idP4expr
(this=0x2ff20208, match_location=4614, simplifiers=...,
matcher=0x0, result=0x0) at
/home/dje/src/src/gcc/genmatch.c:2792
#5  0x100102fc in _ZN6parser13parse_patternEv (this=0x2ff20208)
at /home/dje/src/src/gcc/genmatch.c:3052
#6  0x10010c0c in _ZN6parser9parse_forEj (this=0x2ff20208)
at /home/dje/src/src/gcc/genmatch.c:2991
#7  0x10010350 in _ZN6parser13parse_patternEv (this=0x2ff20208)
at /home/dje/src/src/gcc/genmatch.c:3090
#8  0x1001122c

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

2014-10-26 Thread Chen Gang 


On 10/27/14 2:22, Michael Eager wrote:
 On 10/26/14 03:36, Chen Gang wrote:
 On 10/22/2014 09:34 AM, Chen Gang wrote:


 Yes, if you want to test on a target, you will need a target.  You can 
 either have a simulator (see binutils and sim/* for an example of how to 
 write one) or target hardware in some form.


 After tried 'sim', I found the root cause is microblaze sim does not
 support '--sysroot', which is the environments for shared libraries and
 system calls (need load microblaze kernel).

   - microblaze can successfully execute simple programs which has no
 glibc and no system call.

   - In upstream master branch of binutils, for microblaze sim, it has no
 related testsuite for sim in binutils, neither support '--sysroot',
 neither support function stack, startup parameters, and environments.

   - After hard code the default stack in sim, it can start the '-static'
 program with glibc, but stop at uname() which will use system call.

 So I want to consult: at present, can we let microblaze sim run 'normal'
 programs (have glibc, and use system call)?
 
 Microblaze-sim provides basic instruction set architecture and memory 
 simulation.
 There is no operating system support.  (It's also quite old.  I'm not sure
 which version of the MB architecture it models, but it is not recent.)
 
 Microblaze-sim is not a full system simulator, like QEMU.  To be able to
 run a program which requires glibc, you need to be able to boot a full Linux
 image on the simulator, which microblaze-sim cannot do.  QEMU models an
 entire processor and can boot a Linux image.
 

OK, thank you very much, I shall rewind to qemu, and should try my best
to finish within within this month.


Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

[PATCH, ifcvt] Check size cost in noce_try_store_flag_mask

2014-10-26 Thread Zhenqiang Chen 
Hi,

Function noce_try_store_flag_mask converts if (test) x = 0; to x =
-(test == 0);

But from code size view, x = -(test == 0); might have more instructions
than if (test) x = 0;. The patch checks the cost to determine the
conversion is valuable or not.

Bootstrap and no make check regression on X86-64.
No make check regression with Cortex-M0 qemu.
For CSiBE, ARM Cortex-m0 result is a little better. A little regression for
MIPS. Roughly no change for PowerPC.

OK for trunk?

Thanks!
-Zhenqiang

ChangeLog:
2014-10-27  Zhenqiang Chen  zhenqiang.c...@arm.com

* ifcvt.c (noce_try_store_flag_mask): Check rtx cost.

testsuite/ChangeLog:
2014-10-27  Zhenqiang Chen  zhenqiang.c...@arm.com

* gcc.target/arm/ifcvt-size-check.c: New test.

diff --git a/gcc/ifcvt.c b/gcc/ifcvt.c
index 949d2b4..3abd518 100644
--- a/gcc/ifcvt.c
+++ b/gcc/ifcvt.c
@@ -1393,6 +1393,14 @@ noce_try_store_flag_mask (struct noce_if_info
*if_info)
  if (!seq)
return FALSE;
 
+ if (optimize_function_for_size_p (cfun))
+   {
+ int old_cost = COSTS_N_INSNS (if_info-branch_cost + 1);
+ int new_cost = seq_cost (seq, 0);
+ if (new_cost  old_cost)
+   return FALSE;
+   }
+
  emit_insn_before_setloc (seq, if_info-jump,
   INSN_LOCATION (if_info-insn_a));
  return TRUE;
diff --git a/gcc/testsuite/gcc.target/arm/ifcvt-size-check.c
b/gcc/testsuite/gcc.target/arm/ifcvt-size-check.c
new file mode 100644
index 000..43fa16b
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/ifcvt-size-check.c
@@ -0,0 +1,13 @@
+/* { dg-do assemble } */
+/* { dg-options -mthumb -Os  }  */
+/* { dg-require-effective-target arm_thumb1_ok } */
+
+int
+test (unsigned char iov_len, int count, int i)
+{
+  unsigned char bytes = 0;
+  if ((unsigned char) ((char) 127 - bytes)  iov_len)
+return 22;
+  return 0;
+}
+/* { dg-final { object-size text = 12 } } */

Re: [PATCH, ifcvt] Check size cost in noce_try_store_flag_mask

2014-10-26 Thread Andrew Pinski 
On Sun, Oct 26, 2014 at 6:53 PM, Zhenqiang Chen zhenqiang.c...@arm.com wrote:
 Hi,

 Function noce_try_store_flag_mask converts if (test) x = 0; to x =
 -(test == 0);

 But from code size view, x = -(test == 0); might have more instructions
 than if (test) x = 0;. The patch checks the cost to determine the
 conversion is valuable or not.

 Bootstrap and no make check regression on X86-64.
 No make check regression with Cortex-M0 qemu.
 For CSiBE, ARM Cortex-m0 result is a little better. A little regression for
 MIPS. Roughly no change for PowerPC.

 OK for trunk?

 Thanks!
 -Zhenqiang

 ChangeLog:
 2014-10-27  Zhenqiang Chen  zhenqiang.c...@arm.com

 * ifcvt.c (noce_try_store_flag_mask): Check rtx cost.

 testsuite/ChangeLog:
 2014-10-27  Zhenqiang Chen  zhenqiang.c...@arm.com

 * gcc.target/arm/ifcvt-size-check.c: New test.

 diff --git a/gcc/ifcvt.c b/gcc/ifcvt.c
 index 949d2b4..3abd518 100644
 --- a/gcc/ifcvt.c
 +++ b/gcc/ifcvt.c
 @@ -1393,6 +1393,14 @@ noce_try_store_flag_mask (struct noce_if_info
 *if_info)
   if (!seq)
 return FALSE;

 + if (optimize_function_for_size_p (cfun))
 +   {
 + int old_cost = COSTS_N_INSNS (if_info-branch_cost + 1);
 + int new_cost = seq_cost (seq, 0);
 + if (new_cost  old_cost)
 +   return FALSE;
 +   }


Why not do it unconditionally rather than base this on optimize for size?
If the costs are incorrect for non optimize for size, we need to fix those.

Thanks,
Andrew Pinski

 +
   emit_insn_before_setloc (seq, if_info-jump,
INSN_LOCATION (if_info-insn_a));
   return TRUE;
 diff --git a/gcc/testsuite/gcc.target/arm/ifcvt-size-check.c
 b/gcc/testsuite/gcc.target/arm/ifcvt-size-check.c
 new file mode 100644
 index 000..43fa16b
 --- /dev/null
 +++ b/gcc/testsuite/gcc.target/arm/ifcvt-size-check.c
 @@ -0,0 +1,13 @@
 +/* { dg-do assemble } */
 +/* { dg-options -mthumb -Os  }  */
 +/* { dg-require-effective-target arm_thumb1_ok } */
 +
 +int
 +test (unsigned char iov_len, int count, int i)
 +{
 +  unsigned char bytes = 0;
 +  if ((unsigned char) ((char) 127 - bytes)  iov_len)
 +return 22;
 +  return 0;
 +}
 +/* { dg-final { object-size text = 12 } } */

[RFC PATCH, AARCH64] Add support for -mlong-calls option

2014-10-26 Thread Yangfei (Felix) 
Hi,

This patch adds support for -mlong-calls option for aarch64 port. Major 
code borrowed from ARM.
I'm doing regression test for it right now.  Any comments? 


Index: gcc/config/aarch64/aarch64.opt
===
--- gcc/config/aarch64/aarch64.opt  (revision 216558)
+++ gcc/config/aarch64/aarch64.opt  (working copy)
@@ -75,6 +75,10 @@ mlittle-endian
 Target Report RejectNegative InverseMask(BIG_END)
 Assume target CPU is configured as little endian
 
+mlong-calls
+Target Report Mask(LONG_CALLS)
+Generate call insns as indirect calls, if necessary
+
 mcmodel=
 Target RejectNegative Joined Enum(cmodel) Var(aarch64_cmodel_var) 
Init(AARCH64_CMODEL_SMALL)
 Specify the code model
Index: gcc/config/aarch64/aarch64-protos.h
===
--- gcc/config/aarch64/aarch64-protos.h (revision 216558)
+++ gcc/config/aarch64/aarch64-protos.h (working copy)
@@ -217,6 +217,10 @@ bool aarch64_use_return_insn_p (void);
 const char *aarch64_output_casesi (rtx *);
 const char *aarch64_rewrite_selected_cpu (const char *name);
 
+extern void aarch64_pr_long_calls (struct cpp_reader *);
+extern void aarch64_pr_no_long_calls (struct cpp_reader *);
+extern void aarch64_pr_long_calls_off (struct cpp_reader *);
+
 enum aarch64_symbol_type aarch64_classify_symbol (rtx,
  enum aarch64_symbol_context);
 enum aarch64_symbol_type aarch64_classify_tls_symbol (rtx);
Index: gcc/config/aarch64/aarch64.c
===
--- gcc/config/aarch64/aarch64.c(revision 216558)
+++ gcc/config/aarch64/aarch64.c(working copy)
@@ -69,6 +69,9 @@
 #include dumpfile.h
 #include builtins.h
 
+static void aarch64_set_default_type_attributes (tree);
+static int aarch64_comp_type_attributes (const_tree, const_tree);
+
 /* Defined for convenience.  */
 #define POINTER_BYTES (POINTER_SIZE / BITS_PER_UNIT)
 
@@ -530,12 +533,158 @@ aarch64_hard_regno_caller_save_mode (unsigned regn
 return choose_hard_reg_mode (regno, nregs, false);
 }
 
+/* Table of machine attributes.  */
+static const struct attribute_spec aarch64_attribute_table[] =
+{
+  /* { name, min_len, max_len, decl_req, type_req, fn_type_req, handler,
+   affects_type_identity } */
+  /* Function calls made to this symbol must be done indirectly, because
+ it may lie outside of the 26 bit addressing range of a normal function
+ call.  */
+  { long_call,0, 0, false, true,  true,  NULL, false },
+  /* Whereas these functions are always known to reside within the 26 bit
+ addressing range.  */
+  { short_call,   0, 0, false, true,  true,  NULL, false },
+  { NULL,   0, 0, false, false, false, NULL, false }
+};
+
+/* Encode the current state of the #pragma [no_]long_calls.  */
+typedef enum
+{
+  OFF, /* No #pragma [no_]long_calls is in effect.  */
+  LONG,/* #pragma long_calls is in effect.  */
+  SHORT/* #pragma no_long_calls is in effect.  */
+} aarch64_pragma_enum;
+
+static aarch64_pragma_enum aarch64_pragma_long_calls = OFF;
+
+void
+aarch64_pr_long_calls (struct cpp_reader * pfile ATTRIBUTE_UNUSED)
+{
+  aarch64_pragma_long_calls = LONG;
+}
+
+void
+aarch64_pr_no_long_calls (struct cpp_reader * pfile ATTRIBUTE_UNUSED)
+{
+  aarch64_pragma_long_calls = SHORT;
+}
+
+void
+aarch64_pr_long_calls_off (struct cpp_reader * pfile ATTRIBUTE_UNUSED)
+{
+  aarch64_pragma_long_calls = OFF;
+}
+
+/* Return 0 if the attributes for two types are incompatible, 1 if they
+   are compatible, and 2 if they are nearly compatible (which causes a
+   warning to be generated).  */
+static int
+aarch64_comp_type_attributes (const_tree type1, const_tree type2)
+{
+  int l1, l2, s1, s2;
+
+  /* Check for mismatch of non-default calling convention.  */
+  if (TREE_CODE (type1) != FUNCTION_TYPE)
+return 1;
+
+  /* Check for mismatched call attributes.  */
+  l1 = lookup_attribute (long_call, TYPE_ATTRIBUTES (type1)) != NULL;
+  l2 = lookup_attribute (long_call, TYPE_ATTRIBUTES (type2)) != NULL;
+  s1 = lookup_attribute (short_call, TYPE_ATTRIBUTES (type1)) != NULL;
+  s2 = lookup_attribute (short_call, TYPE_ATTRIBUTES (type2)) != NULL;
+
+  /* Only bother to check if an attribute is defined.  */
+  if (l1 | l2 | s1 | s2)
+{
+  /* If one type has an attribute, the other must have the same attribute. 
 */
+  if ((l1 != l2) || (s1 != s2))
+   return 0;
+
+  /* Disallow mixed attributes.  */
+  if ((l1  s2) || (l2  s1))
+   return 0;
+}
+
+  return 1;
+}
+
+/*  Assigns default attributes to newly defined type.  This is used to
+set short_call/long_call attributes for function types of
+functions defined inside corresponding #pragma scopes.  */
+static void
+aarch64_set_default_type_attributes (tree type)
+{
+  /* Add __attribute__ ((long_call)) to all functions, when
+ inside

[C++ PING] Re: [PATCH 5/5] Add illegal cilk checks to C++ front.

2014-10-26 Thread Andi Kleen 
Andi Kleen a...@firstfloor.org writes:

Ping!

Can someone from the C++ side please approve this patch?
That's the only patch not approved in this patch kit, but blocking
the commit.

-Andi

 From: Andi Kleen a...@linux.intel.com

 Add calls for several illegal Cilk cases to the C++ frontend.
 C++ usually doesn't ICE unlike C on illegal cilk, but it's
 better to match C in what is allowed and what is not.

 if (_Cilk_spawn ...) is still not errored, but at least it doesn't ICE.

 gcc/cp/:

 2014-09-30  Andi Kleen  a...@linux.intel.com

   * semantics.c (finish_goto_stmt): Call check_no_cilk.
   (finish_while_stmt_cond): Dito.
   (finish_do_stmt): Dito.
   (finish_for_cond): Dito.
   (finish_switch_cond): Dito.
 ---
  gcc/cp/semantics.c | 12 
  1 file changed, 12 insertions(+)

 diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
 index 7569826..9ca03be 100644
 --- a/gcc/cp/semantics.c
 +++ b/gcc/cp/semantics.c
 @@ -621,6 +621,8 @@ finish_goto_stmt (tree destination)
  TREE_USED (destination) = 1;
else
  {
 +  if (check_no_cilk (destination, as a computed goto expression))
 + destination = error_mark_node;
destination = mark_rvalue_use (destination);
if (!processing_template_decl)
   {
 @@ -792,6 +794,8 @@ begin_while_stmt (void)
  void
  finish_while_stmt_cond (tree cond, tree while_stmt, bool ivdep)
  {
 +  if (check_no_cilk (cond, as a condition for while statement))
 +cond = error_mark_node;
cond = maybe_convert_cond (cond);
finish_cond (WHILE_COND (while_stmt), cond);
begin_maybe_infinite_loop (cond);
 @@ -847,6 +851,8 @@ finish_do_body (tree do_stmt)
  void
  finish_do_stmt (tree cond, tree do_stmt, bool ivdep)
  {
 +  if (check_no_cilk (cond, as a condition for a do-while statement))
 +cond = error_mark_node;
cond = maybe_convert_cond (cond);
end_maybe_infinite_loop (cond);
if (ivdep  cond != error_mark_node)
 @@ -956,6 +962,8 @@ finish_for_init_stmt (tree for_stmt)
  void
  finish_for_cond (tree cond, tree for_stmt, bool ivdep)
  {
 +  if (check_no_cilk (cond, in a condition for a for-loop))
 +cond = error_mark_node;
cond = maybe_convert_cond (cond);
finish_cond (FOR_COND (for_stmt), cond);
begin_maybe_infinite_loop (cond);
 @@ -1118,6 +1126,10 @@ void
  finish_switch_cond (tree cond, tree switch_stmt)
  {
tree orig_type = NULL;
 +
 +  if (check_no_cilk (cond, as a condition for switch statement))
 +cond = error_mark_node;
 +
if (!processing_template_decl)
  {
/* Convert the condition to an integer or enumeration type.  */

-- 
a...@linux.intel.com -- Speaking for myself only