Re: [google gcc-4_8] Don't use gcov counter related ssa name as induction variables

[Wei Mi]

Here is the updated patch, which follow UD chain to determine whether
iv.base is defined by __gcovx.xxx[] var. It is a lot simpler than
adding a tree bit.

regression test and previously failed benchmark in piii mode is ok.
Other test is going on.

2014-02-10  Wei Mi  

* tree-ssa-loop-ivopts.c (defined_by_gcov_counter): New.
(contains_abnormal_ssa_name_p): Add defined_by_gcov_counter
check for ssa name.

* testsuite/gcc.dg/profile-generate-4.c: New.

Index: tree-ssa-loop-ivopts.c
===
--- tree-ssa-loop-ivopts.c  (revision 207019)
+++ tree-ssa-loop-ivopts.c  (working copy)
@@ -705,6 +705,68 @@ idx_contains_abnormal_ssa_name_p (tree b
   return !abnormal_ssa_name_p (*index);
 }

+/* Return true if the use is defined by a gcov counter var.
+   It is used to check if an iv candidate is generated for
+   profiling. For profile generated ssa name, we should not
+   use it as IV because gcov counter may have data-race for
+   multithread program, it could involve tricky bug to use
+   such ssa var in IVOPT.
+
+   To limit patterns to be checked, we list the possible cases
+   here:
+   Before PRE, the ssa name used to set __gcov counter is as
+   follows:
+   for () {
+ PROF_edge_counter_1 = __gcov.foo[i];
+ PROF_edge_counter_2 = PROF_edge_counter_1 + 1;
+ __gcov.foo[i] = PROF_edge_counter_2;
+   }
+   If PRE works, the loop may be transformed to:
+   pretmp_1 = __gcov.foo[i];
+   for () {
+ prephitmp_1 = PHI (PROF_edge_counter_2, pretmp_1);
+ PROF_edge_counter_1 = prephitmp_1;
+ PROF_edge_counter_2 = PROF_edge_counter_1 + 1;
+ __gcov.foo[i] = PROF_edge_counter_2;
+   }
+   So there are two cases:
+   case1: If PRE doesn't work, PROF_edge_counter_1 and PROF_edge_counter_2
+   are neither induction variables candidates. We don't have to worry
+   about this case.
+   case2: If PRE works, the iv candidate base of PROF_edge_counter_1 and
+   PROF_edge_counter_2 are pretmp_1 or pretmp_1 + 1. pretmp_1 is defined
+   by __gcov var.
+
+   So this func only has to check case2. For a ssa name which is an iv
+   candidate, check its base USE and see if it is defined by __gcov var.
+   Returning true means the ssa name is generated for profiling.  */
+
+bool
+defined_by_gcov_counter (tree use)
+{
+  gimple stmt;
+  tree rhs, decl;
+  const char *name;
+
+  stmt = SSA_NAME_DEF_STMT (use);
+  if (!is_gimple_assign (stmt))
+return false;
+
+  rhs = gimple_assign_rhs1 (stmt);
+  if (TREE_CODE (rhs) != ARRAY_REF)
+return false;
+
+  decl = TREE_OPERAND (rhs, 0);
+  if (TREE_CODE (decl) != VAR_DECL)
+return false;
+
+  name = IDENTIFIER_POINTER (DECL_NAME (decl));
+  if (strncmp (name, "__gcov", 6))
+return false;
+
+  return true;
+}
+
 /* Returns true if EXPR contains a ssa name that occurs in an
abnormal phi node.  */

@@ -721,7 +783,8 @@ contains_abnormal_ssa_name_p (tree expr)
   codeclass = TREE_CODE_CLASS (code);

   if (code == SSA_NAME)
-return SSA_NAME_OCCURS_IN_ABNORMAL_PHI (expr) != 0;
+return SSA_NAME_OCCURS_IN_ABNORMAL_PHI (expr) != 0
+  || defined_by_gcov_counter (expr);

   if (code == INTEGER_CST
   || is_gimple_min_invariant (expr))
Index: testsuite/gcc.dg/profile-generate-4.c
===
--- testsuite/gcc.dg/profile-generate-4.c   (revision 0)
+++ testsuite/gcc.dg/profile-generate-4.c   (revision 0)
@@ -0,0 +1,21 @@
+/* { dg-do compile { target { i?86-*-* x86_64-*-* } } } */
+/* { dg-options "-O2 -fprofile-generate -fno-tree-loop-im
-fdump-tree-ivopts-details-blocks" } */
+
+/* Because gcov counter related var has data race for multithread program,
+   compiler should prevent them from affecting program correctness. So
+   PROF_edge_counter variable should not be used as induction variable, or
+   else IVOPT may use such variable to compute loop boundary.  */
+
+void *ptr;
+int N;
+
+void foo(void *t) {
+  int i;
+  for (i = 0; i < N; i++) {
+t = *(void **)t;
+  }
+  ptr = t;
+}
+
+/* { dg-final { scan-tree-dump-times "ssa name PROF_edge_counter" 0
"ivopts"} } */
+/* { dg-final { cleanup-tree-dump "ivopts" } } */

Re: [RS6000] power8 internal compiler errors

[David Edelsohn]

On Mon, Feb 10, 2014 at 8:33 PM, Alan Modra  wrote:
> On Mon, Feb 10, 2014 at 07:01:03PM -0500, David Edelsohn wrote:
>> On Mon, Feb 10, 2014 at 5:18 PM, Alan Modra  wrote:
>>
>> Shouldn't addr_op2 also be set from find_replacement?
>
> Sorry, I thought after I sent the email that I should have added some
> explanation of why certain parts need find_replacement and others
> don't.  We want just those parts of addresses that might have been
> reloaded.
>
> There's the case of the entire address being reloaded (actually, I'm
> not sure this one is needed) and then all the ones we do in the rs6000
> backend in legitimize_reload_address.  I think I found all the
> required parts but it certainly won't hurt if you check too.  Calling
> find_replacement when not strictly necessary will slow down gcc a
> little..

It looked like either piece of the address could be a more complicated
address that is reloaded, especially in a failure case, at least based
on the few other uses of find_replacement in other backends. But it is
difficult to determine.

The secondary_reload_inner code seems to be prepared for more
complicated addresses that could require reloads in the second
operand, but I agree that legitimize_reload_address should affect the
first operand.

- David

[google][gcc-4_8][patch]Handle Split functions in the Function Reordering Plugin

[Sriraman Tallam]

Hi Teresa,

   I have attached a patch to recognize and reorder split functions in
the function reordering plugin. Please review.

Thanks
Sri
This enhances the linker plugin to reorder functions that are split when
using -freorder-blocks-and-partition.

Index: function_reordering_plugin/callgraph.h
===
--- function_reordering_plugin/callgraph.h  (revision 207671)
+++ function_reordering_plugin/callgraph.h  (working copy)
@@ -236,6 +236,8 @@ typedef struct section_id_
  is comdat hot and kept, pointer to the kept cold split
  section.  */
   struct section_id_ *split_section;
+  /* If this is the cold part of a split section.  */
+  char is_split_cold_section;
   /* Check if this section has been considered for output.  */
   char processed;
 } Section_id;
@@ -260,6 +262,7 @@ make_section_id (char *name, char *full_name,
   s->computed_weight = 0;
   s->max_count = 0;
   s->split_section = NULL;
+  s->is_split_cold_section = 0;
 
   return s;
 }
Index: function_reordering_plugin/callgraph.c
===
--- function_reordering_plugin/callgraph.c  (revision 207671)
+++ function_reordering_plugin/callgraph.c  (working copy)
@@ -550,6 +550,25 @@ static void set_node_type (Node *n)
   s->computed_weight = n->computed_weight; 
   s->max_count = n->max_count;
 
+  /* If s is split into a cold section, assign the split weight to the
+ max count of the split section.   Use this also for the weight of the
+ split section.  */
+  if (s->split_section)
+{
+  s->split_section->max_count = s->split_section->weight = 
n->split_weight;
+  /* If split_section is comdat, update all the comdat
+candidates for weight.  */
+  s_comdat = s->split_section->comdat_group;
+  while (s_comdat != NULL)
+{
+  s_comdat->weight = s->split_section->weight;
+  s_comdat->computed_weight
+   = s->split_section->computed_weight;
+  s_comdat->max_count = s->split_section->max_count;
+  s_comdat = s_comdat->comdat_group;
+}
+   }
+
   /* If s is comdat, update all the comdat candidates for weight.  */
   s_comdat = s->comdat_group;
   while (s_comdat != NULL)
@@ -699,26 +718,129 @@ map_section_name_to_index (char *section_name, voi
 }
   else
 {
-  /* The function already exists, it must be a COMDAT.  Only one section
-in the comdat group will be kept, we don't know which.  Chain all the
- comdat sections in the same comdat group to be emitted together later.
- Keep one section as representative (kept) and update its section_type
- to be equal to the type of the highest priority section in the
- group.  */
+  /* Handle function splitting here.  With function splitting, the split
+ function sections have the same name and they are in the same module.
+Here, we only care about the section that is marked with prefix
+like ".text.hot".  The other section is cold.  The plugin should not
+be adding this cold section to the section_map.  In get_layout it will
+later be picked up when processing the non-callgraph sections and it
+will laid out appropriately.  */
   Section_id *kept = (Section_id *)(*slot);
   Section_id *section = make_section_id (function_name, section_name,
  section_type, handle, shndx);
+  int is_split_function = 0;
+  Section_id *split_comdat = NULL;
+  /* Check if this is a split function. The modules are the same means this
+is not comdat and we assume it is split.  It can be split and comdat
+too, in which case we have to search the comdat list of kept.  */
+  if (kept->handle == handle)
+   is_split_function = 1;
+  else if (kept->comdat_group != NULL)
+   {
+ split_comdat = kept;
+ do
+   {
+ if (split_comdat->comdat_group->handle == handle)
+   break;
+ split_comdat = split_comdat->comdat_group;
+   }
+ while (split_comdat->comdat_group != NULL);
+   }
 
-  /* Two comdats in the same group can have different priorities.  This
-ensures that the "kept" comdat section has the priority of the higest
-section in that comdat group.   This is necessary because the plugin
-does not know which section will be kept.  */
-  if (section_priority[kept->section_type]
- > section_priority[section_type])
-kept->section_type = section_type;
+  /* It is split and it is comdat.  */
+  if (split_comdat != NULL
+ && split_comdat->comdat_group != NULL)
+   {
+ /* The comdat_section that is split.  */
+ Section_id *comdat_section = split_comdat->comdat_group;
+

Re: [Patch, microblaze]: Extended mcpu version format

[Michael Eager]

On 11/25/13 23:53, David Holsgrove wrote:

MicroBlaze currently only supports mcpu version of format vX.YY.Z

This patch extends the mcpu version format to include;

  vX.YY.Z
  vXX.YY.Z
  vXX.YY
  vX.YY.Z

Changelog

2013-11-26  Nagaraju Mekala 

  * gcc/config/microblaze/microblaze.c: Extend mcpu version format.


Parsing a version number could be better done in fewer lines using sscanf()
instead of 50 lines.

GCC-head: Committed revision 207680.
GCC-4.8-branch: Committed revision 207681.

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

Re: [RS6000] power8 internal compiler errors

[Alan Modra]

On Mon, Feb 10, 2014 at 07:01:03PM -0500, David Edelsohn wrote:
> On Mon, Feb 10, 2014 at 5:18 PM, Alan Modra  wrote:
> 
> Shouldn't addr_op2 also be set from find_replacement?

Sorry, I thought after I sent the email that I should have added some
explanation of why certain parts need find_replacement and others
don't.  We want just those parts of addresses that might have been
reloaded.

There's the case of the entire address being reloaded (actually, I'm
not sure this one is needed) and then all the ones we do in the rs6000
backend in legitimize_reload_address.  I think I found all the
required parts but it certainly won't hurt if you check too.  Calling
find_replacement when not strictly necessary will slow down gcc a
little..

-- 
Alan Modra
Australia Development Lab, IBM

Re: [Patch, microblaze]: Add SIZE_TYPE and PTRDIFF_TYPE to microblaze.h

[Michael Eager]

On 11/25/13 23:52, David Holsgrove wrote:

Hi Michael,

I've attached patch based on latest gcc master. Please let me know if
you need anything further.

thanks,
David


On 15 July 2013 14:42, David Holsgrove  wrote:


Hi Michael,

On 18 March 2013 22:50, David Holsgrove  wrote:

Changelog

2013-03-18  David Holsgrove 

  * gcc/config/microblaze/microblaze.h: Define SIZE_TYPE
and PTRDIFF_TYPE.

Signed-off-by: David Holsgrove 



This patch remains the same, please review when ready.

thanks,
David


GCC-head: Committed revision 207678.
GCC-4_8-branch: Committed revision 207679.


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

[PATCH] Fix PR target/60137, no splitters for vectors that get GPR registers

[Michael Meissner]

This patch fixes PR target/60137 that shows up when some vector types get
allocated to GPR registers, and there wasn't a splitter for the type.  It shows
up when targetting ISA 2.07 (power8) when VSX is disabled but Altivec (VMX) is
enabled, though I suspect there are other failure cases.

I bootstrapped and checked the patch, and it caused no regressions in the test
suite.  Is it ok to apply?

[gcc]
2014-02-10  Michael Meissner  

PR target/60137
* config/rs6000/rs6000.md (128-bit GPR splitter): Add a splitter
for VSX/Altivec vectors that land in GPR registers.

[gcc/testsuite]
2014-02-10  Michael Meissner  

PR target/60137
* gcc.target/powerpc/pr60137.c: New file.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/rs6000.md
===
--- gcc/config/rs6000/rs6000.md (revision 207668)
+++ gcc/config/rs6000/rs6000.md (working copy)
@@ -9963,6 +9963,15 @@ (define_insn_and_split "reload_vsx_from_
   [(set_attr "length" "12")
(set_attr "type" "three")])
 
+(define_split
+  [(set (match_operand:FMOVE128_GPR 0 "nonimmediate_operand" "")
+   (match_operand:FMOVE128_GPR 1 "input_operand" ""))]
+  "reload_completed
+   && (int_reg_operand (operands[0], mode)
+   || int_reg_operand (operands[1], mode))"
+  [(pc)]
+{ rs6000_split_multireg_move (operands[0], operands[1]); DONE; })
+
 ;; Move SFmode to a VSX from a GPR register.  Because scalar floating point
 ;; type is stored internally as double precision in the VSX registers, we have
 ;; to convert it from the vector format.
Index: gcc/testsuite/gcc.target/powerpc/pr60137.c
===
--- gcc/testsuite/gcc.target/powerpc/pr60137.c  (revision 0)
+++ gcc/testsuite/gcc.target/powerpc/pr60137.c  (revision 0)
@@ -0,0 +1,17 @@
+/* { dg-do compile { target { powerpc*-*-* } } } */
+/* { dg-skip-if "" { powerpc*-*-darwin* } { "*" } { "" } } */
+/* { dg-require-effective-target powerpc_p8vector_ok } */
+/* { dg-options "-mcpu=power8 -O3 -mno-vsx" } */
+
+/* target/60137, compiler got a 'could not split insn error'.  */
+
+extern int target_flags;
+extern char fixed_regs[53];
+extern char call_used_regs[53];
+
+void init_reg_sets_1(void)
+{
+  int i;
+  for (i = 0; i < 53; i++)
+fixed_regs[i] = call_used_regs[i] = (call_used_regs[i] &((target_flags & 
0x0200) ? 2 : 1)) != 0;
+}

Re: [C PATCH] Improve column info of initializers (PR c/60114)

[Joseph S. Myers]

On Mon, 10 Feb 2014, Marek Polacek wrote:

> This patch improves location information in a bunch of various
> initializers; see the testcase.  Main issue was that digest_init
> was getting only input_location.
> 
> Regtested/bootstrapped on x86_64-linux, ok for trunk at this stage
> or should I queue it for 5.0?

OK for after 4.9 branches.

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

Re: print quotes around )

[Joseph S. Myers]

On Sun, 9 Feb 2014, Prathamesh Kulkarni wrote:

> On Sun, Feb 9, 2014 at 8:31 PM, Prathamesh Kulkarni
>  wrote:
> > A trivial fix to print quotes around ) in libcpp/macro.c
> > OK for trunk ?
> Will not work for if pfile->cb.error callback does not recognize %< and %>
> (maybe clients other than c, c++ front-ends ?).
> So we cannot include %< and %> in the error message ?

Certainly not while the callback is declared ATTRIBUTE_FPTR_PRINTF, I'd 
have expected the bootstrap to fail with -Werror warnings  (Declaring 
the callback to allow GCC-internal formats might have corresponding 
requirements for particular types to be declared first, where the 
format-checking machinery knows how GCC-internal formats use GCC-internal 
typedefs; you'd need to check.)

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

Re: [RS6000] power8 internal compiler errors

[David Edelsohn]

On Mon, Feb 10, 2014 at 5:18 PM, Alan Modra  wrote:

Shouldn't addr_op2 also be set from find_replacement?

- David

> @@ -16201,7 +16200,7 @@
>   || !rs6000_legitimate_offset_address_p (PTImode, addr,
>   false, true)))
> {
> - addr_op1 = XEXP (addr, 0);
> + addr_op1 = find_replacement (&XEXP (addr, 0));
>   addr_op2 = XEXP (addr, 1);
^
>   if (!legitimate_indirect_address_p (addr_op1, false))
> rs6000_secondary_reload_fail (__LINE__, reg, mem, scratch, 
> store_p);

> @@ -16310,7 +16308,7 @@
>
>else if (GET_CODE (addr) == PLUS)
> {
> - addr_op1 = XEXP (addr, 0);
> + addr_op1 = find_replacement (&XEXP (addr, 0));
>   addr_op2 = XEXP (addr, 1);
^
>   if (!REG_P (addr_op1))
> rs6000_secondary_reload_fail (__LINE__, reg, mem, scratch, 
> store_p);

Re: [google gcc-4_8] Don't use gcov counter related ssa name as induction variables

[Xinliang David Li]

I don't think you should add a new tree bit just for this.  A simple
UD check can determine prephitmp_23, etc are abnormal ssa names:

 # prephitmp_23 = PHI 
  PROF_edge_counter_10 = prephitmp_23 + 1;
  __gcov0.foo[0] = PROF_edge_counter_10;

Note you may need to 'hack' a little to check if a static variable is
a counter variable by name, but that is better than a bit.

David


On Mon, Feb 10, 2014 at 3:16 PM, Wei Mi  wrote:
> Hi,
>
> I saw a bug happened in fdo-gen phase when a gcov counter related ssa
> name was used as induction variable and used to calculate loop
> boundary after loop cond was replaced by an expr with the ssa name. We
> knew that there was data race in gcov counter in multithread program,
> so the values in gcov counter may be changed unexpectedly. Normally
> compiler optimizations assume global variables have no data race, so
> it was compiler's responsiblity to prevent gcov counter related
> variables from affecting program's correctness. However, using gcov
> counter related ssa tmp as induction variable and doing iv
> replacements was a break to this rule.
>
> The following testcase shows the problem in concept.
>
> void *ptr;
> int N;
>
> void foo(void *t) {
>   int i;
>   for (i = 0; i < N; i++) {
> t = *(void **)t;
>   }
>   ptr = t;
> }
>
> The compile command:
> gcc-r206603/build/install/bin/gcc -O2 -fprofile-generate=./fdoprof
> -fno-tree-loop-im -fdump-tree-ivopts-details-blocks -c 1.c
>
> IR for kernel loop before IVOPT:
>
> ;;   basic block 3, loop depth 0, count 0, freq 819, maybe hot
> ;;prev block 2, next block 4, flags: (NEW)
> ;;pred:   2 [91.0%]  (TRUE_VALUE,EXECUTABLE)
>   pretmp_1 = __gcov0.foo[0];
> ;;succ:   4 [100.0%]  (FALLTHRU,EXECUTABLE)
>
> ;;   basic block 4, loop depth 1, count 0, freq 9100, maybe hot
> ;;prev block 3, next block 5, flags: (NEW, REACHABLE)
> ;;pred:   5 [100.0%]  (FALLTHRU,EXECUTABLE)
> ;;3 [100.0%]  (FALLTHRU,EXECUTABLE)
>   # t_25 = PHI 
>   # i_26 = PHI 
>   # prephitmp_23 = PHI 
>   PROF_edge_counter_10 = prephitmp_23 + 1;
>   __gcov0.foo[0] = PROF_edge_counter_10;
>   t_6 = MEM[(void * *)t_25];
>   i_7 = i_26 + 1;
>   if (i_7 < N.0_24)
> goto ;
>   else
> goto ;
> ;;succ:   5 [91.0%]  (TRUE_VALUE,EXECUTABLE)
> ;;6 [9.0%]  (FALSE_VALUE,EXECUTABLE)
>
> ;;   basic block 5, loop depth 1, count 0, freq 8281, maybe hot
> ;;prev block 4, next block 6, flags: (NEW)
> ;;pred:   4 [91.0%]  (TRUE_VALUE,EXECUTABLE)
>   goto ;
>
> Induction variable dumps:
>
> In IVOPT dump, I can see that some gcov counter related ssa names are
> used as induction variables.
> Induction variables:
> ssa name PROF_edge_counter_10
>   type long int
>   base pretmp_1 + 1
>   step 1
>   is a biv
> ssa name prephitmp_23
>   type long int
>   base pretmp_1
>   step 1
>   is a biv
>
> After IVOPT:
> pretmp_1 is a gcov counter related tmp var, and it is used to
> calculate _33 which is the loop boundary. Sometimes register
> allocation may replace the use of pretmp_1 with __gcov0.foo[0], so
> there may be muliple __gcov0.foo[0] accesses in loop boundary
> calculation. But the values of those __gcov0.foo[0] accesses may or
> may not be the same because of data race. That caused the bug.
>
> ;;   basic block 3, loop depth 0, count 0, freq 819, maybe hot
> ;;prev block 2, next block 4, flags: (NEW)
> ;;pred:   2 [91.0%]  (TRUE_VALUE,EXECUTABLE)
>   pretmp_1 = __gcov0.foo[0];
>   _22 = pretmp_1 + 1;
>   ivtmp.8_2 = (unsigned long) _22;
>   _21 = (unsigned int) N.0_24;
>   _29 = _21 + 4294967295;
>   _30 = (unsigned long) _29;
>   _31 = (unsigned long) pretmp_1;  // may be replaced by
> __gcov0.foo[0] in register allocation.
>   _32 = _30 + _31;
>   _33 = _32 + 2;
> ;;succ:   4 [100.0%]  (FALLTHRU,EXECUTABLE)
>
> ;;   basic block 4, loop depth 1, count 0, freq 9100, maybe hot
> ;;prev block 3, next block 5, flags: (NEW, REACHABLE)
> ;;pred:   5 [100.0%]  (FALLTHRU,EXECUTABLE)
> ;;3 [100.0%]  (FALLTHRU,EXECUTABLE)
>   # t_25 = PHI 
>   # ivtmp.8_9 = PHI 
>   PROF_edge_counter_10 = (long int) ivtmp.8_9;
>   __gcov0.foo[0] = PROF_edge_counter_10;
>   t_6 = MEM[(void * *)t_25];
>   ivtmp.8_5 = ivtmp.8_9 + 1;
>   if (ivtmp.8_5 != _33)
> goto ;
>   else
> goto ;
> ;;succ:   5 [91.0%]  (TRUE_VALUE,EXECUTABLE)
> ;;6 [9.0%]  (FALSE_VALUE,EXECUTABLE)
>
> ;;   basic block 5, loop depth 1, count 0, freq 8281, maybe hot
> ;;prev block 4, next block 6, flags: (NEW)
> ;;pred:   4 [91.0%]  (TRUE_VALUE,EXECUTABLE)
>   goto ;
>
>
> The patch is to mark ssa name generated in profile-gen as
> PROFILE_GENERATED. In IVOPT, for ssa name marked as PROFILE_GENERATED,
> or ssa name defined by PHI with other PROFILE_GENERATED ssa name as
> PHI operand, they will not be identified as induction variables.
>
> Testing is going on. Is it ok if tests pass?
>
> 2014-02-10  Wei Mi  
>
> * tree-flow-inline.h (

[google gcc-4_8] Don't use gcov counter related ssa name as induction variables

[Wei Mi]

Hi,

I saw a bug happened in fdo-gen phase when a gcov counter related ssa
name was used as induction variable and used to calculate loop
boundary after loop cond was replaced by an expr with the ssa name. We
knew that there was data race in gcov counter in multithread program,
so the values in gcov counter may be changed unexpectedly. Normally
compiler optimizations assume global variables have no data race, so
it was compiler's responsiblity to prevent gcov counter related
variables from affecting program's correctness. However, using gcov
counter related ssa tmp as induction variable and doing iv
replacements was a break to this rule.

The following testcase shows the problem in concept.

void *ptr;
int N;

void foo(void *t) {
  int i;
  for (i = 0; i < N; i++) {
t = *(void **)t;
  }
  ptr = t;
}

The compile command:
gcc-r206603/build/install/bin/gcc -O2 -fprofile-generate=./fdoprof
-fno-tree-loop-im -fdump-tree-ivopts-details-blocks -c 1.c

IR for kernel loop before IVOPT:

;;   basic block 3, loop depth 0, count 0, freq 819, maybe hot
;;prev block 2, next block 4, flags: (NEW)
;;pred:   2 [91.0%]  (TRUE_VALUE,EXECUTABLE)
  pretmp_1 = __gcov0.foo[0];
;;succ:   4 [100.0%]  (FALLTHRU,EXECUTABLE)

;;   basic block 4, loop depth 1, count 0, freq 9100, maybe hot
;;prev block 3, next block 5, flags: (NEW, REACHABLE)
;;pred:   5 [100.0%]  (FALLTHRU,EXECUTABLE)
;;3 [100.0%]  (FALLTHRU,EXECUTABLE)
  # t_25 = PHI 
  # i_26 = PHI 
  # prephitmp_23 = PHI 
  PROF_edge_counter_10 = prephitmp_23 + 1;
  __gcov0.foo[0] = PROF_edge_counter_10;
  t_6 = MEM[(void * *)t_25];
  i_7 = i_26 + 1;
  if (i_7 < N.0_24)
goto ;
  else
goto ;
;;succ:   5 [91.0%]  (TRUE_VALUE,EXECUTABLE)
;;6 [9.0%]  (FALSE_VALUE,EXECUTABLE)

;;   basic block 5, loop depth 1, count 0, freq 8281, maybe hot
;;prev block 4, next block 6, flags: (NEW)
;;pred:   4 [91.0%]  (TRUE_VALUE,EXECUTABLE)
  goto ;

Induction variable dumps:

In IVOPT dump, I can see that some gcov counter related ssa names are
used as induction variables.
Induction variables:
ssa name PROF_edge_counter_10
  type long int
  base pretmp_1 + 1
  step 1
  is a biv
ssa name prephitmp_23
  type long int
  base pretmp_1
  step 1
  is a biv

After IVOPT:
pretmp_1 is a gcov counter related tmp var, and it is used to
calculate _33 which is the loop boundary. Sometimes register
allocation may replace the use of pretmp_1 with __gcov0.foo[0], so
there may be muliple __gcov0.foo[0] accesses in loop boundary
calculation. But the values of those __gcov0.foo[0] accesses may or
may not be the same because of data race. That caused the bug.

;;   basic block 3, loop depth 0, count 0, freq 819, maybe hot
;;prev block 2, next block 4, flags: (NEW)
;;pred:   2 [91.0%]  (TRUE_VALUE,EXECUTABLE)
  pretmp_1 = __gcov0.foo[0];
  _22 = pretmp_1 + 1;
  ivtmp.8_2 = (unsigned long) _22;
  _21 = (unsigned int) N.0_24;
  _29 = _21 + 4294967295;
  _30 = (unsigned long) _29;
  _31 = (unsigned long) pretmp_1;  // may be replaced by
__gcov0.foo[0] in register allocation.
  _32 = _30 + _31;
  _33 = _32 + 2;
;;succ:   4 [100.0%]  (FALLTHRU,EXECUTABLE)

;;   basic block 4, loop depth 1, count 0, freq 9100, maybe hot
;;prev block 3, next block 5, flags: (NEW, REACHABLE)
;;pred:   5 [100.0%]  (FALLTHRU,EXECUTABLE)
;;3 [100.0%]  (FALLTHRU,EXECUTABLE)
  # t_25 = PHI 
  # ivtmp.8_9 = PHI 
  PROF_edge_counter_10 = (long int) ivtmp.8_9;
  __gcov0.foo[0] = PROF_edge_counter_10;
  t_6 = MEM[(void * *)t_25];
  ivtmp.8_5 = ivtmp.8_9 + 1;
  if (ivtmp.8_5 != _33)
goto ;
  else
goto ;
;;succ:   5 [91.0%]  (TRUE_VALUE,EXECUTABLE)
;;6 [9.0%]  (FALSE_VALUE,EXECUTABLE)

;;   basic block 5, loop depth 1, count 0, freq 8281, maybe hot
;;prev block 4, next block 6, flags: (NEW)
;;pred:   4 [91.0%]  (TRUE_VALUE,EXECUTABLE)
  goto ;


The patch is to mark ssa name generated in profile-gen as
PROFILE_GENERATED. In IVOPT, for ssa name marked as PROFILE_GENERATED,
or ssa name defined by PHI with other PROFILE_GENERATED ssa name as
PHI operand, they will not be identified as induction variables.

Testing is going on. Is it ok if tests pass?

2014-02-10  Wei Mi  

* tree-flow-inline.h (make_prof_ssa_name): New.
(make_temp_prof_ssa_name): Ditto.
* tree.h (struct tree_base): Add PROFILE_GENERATED flag for ssa name.
* tree-inline.c (remap_ssa_name): Set PROFILE_GENERATED flag for
ssa name.
* tree-profile.c (add_sampling_wrapper): Ditto.
(add_execonce_wrapper): Ditto.
(gimple_gen_edge_profiler): Ditto.
(gimple_gen_ic_profiler): Ditto.
(gimple_gen_dc_profiler): Ditto.
* value-prof.c (gimple_divmod_fixed_value): Ditto.
(gimple_mod_pow2): Ditto.
(gimple_mod_subtract): Ditto.
(gimple_ic): Ditto.
(gimple_stringop_fixed_value): Ditto.
* tre

Re: [PATCH 5/6] [GOMP4] OpenACC 1.0+ support in fortran front-end

[Tobias Burnus]

Hi!

Thomas Schwinge wrote:

Please see
[...]
 $ git diff --stat 765faa80eda3bb75aa044ad015e2e5214bf02c6d 
origin/gomp-4_0-branch | grep -v ChangeLog


I am now browsing through the changes. Remarks:

1) I think you also want to set in gcc/fortran/options.c
 gfc_option.flag_recursive = -1
for OpenACC as it is done for OpenMP. That should be also mentioned in 
fortran/invoke.texi - without -frecursive, local array variables might 
be allocated in static memory, which should be incompatible with 
concurrent invocation. [At least with OpenACC 2.0's $acc routine.]


2) I think OpenACC should also be mentioned at 
http://gcc.gnu.org/onlinedocs/gfortran/Standards.html and, maybe, at 
http://gcc.gnu.org/onlinedocs/gfortran/Project-Status.html - however, I 
suggest not to put the version number there.


3) I think it would be useful to document the constants and the still 
lacking functions/procedures of openacc.h, openacc_lib.h and the openacc 
module; maybe you should start with a stub documentation - either by 
adding it into a separate chapter in libgomp.texi or in an extra 
document. In any case, there should be some reference to that document 
from http://gcc.gnu.org/onlinedocs/gfortran/Intrinsic-Modules.html 
(fortran/intrinsic.texi)




Can't you? I am not sure whether -fdump-parse-tree is needed; on the
other hand, it just clutters the *log files.

Yes, I think that should just be in the test case files that actually
need it?


I think the parse tree is never really needed - it just dumps the 
gfortran AST in a somewhat readable form to stdout. Hence, it mainly 
tests that the compiler doesn't ICE, unless one tries to do pattern 
matching.


(As -fdump-parse-tree is only rarely used, one keeps forgetting about it 
when extending the AST. Consequently, ICEs aren't that rare.)


Tobias

Re: PATCH: PR target/59605: Create jump_around_label only if it doesn't exist

[Andrew Pinski]

On Thu, Dec 26, 2013 at 6:31 PM, H.J. Lu  wrote:
> Hi Honza,
>
> r203937 may create jump_around_label earlier. But later code doesn't
> check if jump_around_label exists.  This patch fixes it.  Tested
> on Linux/x86-64.  OK to install?

This test times out when running on a simulator.  Is there a way to
reduce the MAX_LENGTH size?

Thanks,
Andrew Pinski


>
> Thanks.
>
> H.J.
> --
> gcc/
>
> 2013-12-26   H.J. Lu  
>
> PR target/59605
> * config/i386/i386.c (ix86_expand_set_or_movmem): Create
> jump_around_label only if it doesn't exist.
>
> gcc/testsuite/
>
> 2013-12-26   H.J. Lu  
>
> PR target/59605
> * gcc.dg/pr59605.c: New test.
>
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index 0cf0a9d..07f9a86 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -24015,7 +24015,8 @@ ix86_expand_set_or_movmem (rtx dst, rtx src, rtx 
> count_exp, rtx val_exp,
>else
> {
>   rtx hot_label = gen_label_rtx ();
> - jump_around_label = gen_label_rtx ();
> + if (jump_around_label == NULL_RTX)
> +   jump_around_label = gen_label_rtx ();
>   emit_cmp_and_jump_insns (count_exp, GEN_INT (dynamic_check - 1),
>LEU, 0, GET_MODE (count_exp), 1, 
> hot_label);
>   predict_jump (REG_BR_PROB_BASE * 90 / 100);
> diff --git a/gcc/testsuite/gcc.dg/pr59605.c b/gcc/testsuite/gcc.dg/pr59605.c
> new file mode 100644
> index 000..4556843
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/pr59605.c
> @@ -0,0 +1,55 @@
> +/* { dg-do run } */
> +/* { dg-options "-O2" } */
> +/* { dg-additional-options "-minline-stringops-dynamically" { target { 
> i?86-*-* x86_64-*-* } } } */
> +
> +extern void abort (void);
> +
> +#define MAX_OFFSET (sizeof (long long))
> +#define MAX_COPY (1024 + 8192)
> +#define MAX_EXTRA (sizeof (long long))
> +
> +#define MAX_LENGTH (MAX_OFFSET + MAX_COPY + MAX_EXTRA)
> +
> +static union {
> +  char buf[MAX_LENGTH];
> +  long long align_int;
> +  long double align_fp;
> +} u;
> +
> +char A[MAX_LENGTH];
> +
> +int
> +main ()
> +{
> +  int off, len, i;
> +  char *p, *q;
> +
> +  for (i = 0; i < MAX_LENGTH; i++)
> +A[i] = 'A';
> +
> +  for (off = 0; off < MAX_OFFSET; off++)
> +for (len = 1; len < MAX_COPY; len++)
> +  {
> +   for (i = 0; i < MAX_LENGTH; i++)
> + u.buf[i] = 'a';
> +
> +   p = __builtin_memcpy (u.buf + off, A, len);
> +   if (p != u.buf + off)
> + abort ();
> +
> +   q = u.buf;
> +   for (i = 0; i < off; i++, q++)
> + if (*q != 'a')
> +   abort ();
> +
> +   for (i = 0; i < len; i++, q++)
> + if (*q != 'A')
> +   abort ();
> +
> +   for (i = 0; i < MAX_EXTRA; i++, q++)
> + if (*q != 'a')
> +   abort ();
> +  }
> +
> +  return 0;
> +}

[RFA] [PATCH] [rtl-optimization/60131] Fix rtl-checking failure in REE

[Jeff Law]

As mentioned in the BZ, we have the following insns:



(insn 24 23 25 6 (set (reg:DI 0 ax [orig:100 D.2269 ] [100])
(zero_extend:DI (reg/v:SI 0 ax [orig:91 v ] [91]))) j.c:22 133 
{*zero_extendsidi2}

 (nil))
$13 = void
(gdb) p debug_rtx (curr_insn)
(insn 33 32 35 7 (set (reg/v:SI 0 ax [orig:91 v ] [91])
(sign_extend:SI (reg:HI 0 ax [orig:88 D.2271 ] [88]))) j.c:19 
146 {extendhisi2}

 (nil))


We eliminate insn 24 by changing insn 33 into:


(insn 33 32 35 7 (set (reg:DI 0 ax)
(zero_extend:DI (sign_extend:SI (reg:HI 0 ax [orig:88 D.2271 ] 
[88] j.c:19 -1

 (nil))


Later we call combine_reaching_defs to see if we can eliminate insn 33. 
 Unfortunately the tests for the srcreg != destreg case assume that 
there are no nested extensions and we run afoul of RTL checking.


There's two cases to consider with nested extensions.  When the two 
registers are the same, we want to do nothing as the old code handles 
that case correctly.  When the registers are different, we want to avoid 
the optimization simply because not all the code for handling the srcreg 
!= destreg case has been vetted for nested extensions.


So clearly the way to go is to fix the test in combine_reaching_defs not 
to barf on nested extensions.  When the srcreg != destreg we still go 
into the true arm which will always return false if there was a nested 
extension (only way to get nested extensions at this point in code will 
be if state->modified != EXT_MODIFIED_NONE).  When srcreg == destreg we 
fall-thru to the original ree code which does the right thing.


A similar test in find_and_remove_re needs updating as well.  It's 
simpler because we're simply disallowing srcreg != destreg with nested 
extensions.  We don't need to find the regno, just check if we have 
(extend (reg)) or not.


Bootstrapped and regression tested (rtl checking enabled) on 
x86_64-unknown-linux-gnu.  OK for the trunk?


Thanks,
Jeff
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index a5ad4fa..ee2165c 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,12 @@
+2014-02-10  Jeff Law  
+
+   PR rtl-optimization/60131
+   * ree.c (get_extended_src_reg): New function.
+   (combine_reaching_defs): Use it rather than assuming location
+   of REG.
+   (find_and_remove_re): Verify first operand of extension is
+   a REG before adding the insns to the copy list.
+
 2014-02-10  Bernd Edlinger  
 
PR middle-end/60080
diff --git a/gcc/ree.c b/gcc/ree.c
index 421eb6c..fcde9a0 100644
--- a/gcc/ree.c
+++ b/gcc/ree.c
@@ -670,6 +670,18 @@ merge_def_and_ext (ext_cand *cand, rtx def_insn, ext_state 
*state)
   return false;
 }
 
+/* Given SRC, which should be one or more extensions of a REG, strip
+   away the extensions and return the REG.  */
+
+static inline rtx
+get_extended_src_reg (rtx src)
+{
+  while (GET_CODE (src) == SIGN_EXTEND || GET_CODE (src) == ZERO_EXTEND)
+src = XEXP (src, 0);
+  gcc_assert (REG_P (src));
+  return src;
+}
+
 /* This function goes through all reaching defs of the source
of the candidate for elimination (CAND) and tries to combine
the extension with the definition instruction.  The changes
@@ -698,17 +710,23 @@ combine_reaching_defs (ext_cand *cand, const_rtx set_pat, 
ext_state *state)
 
   /* If the destination operand of the extension is a different
  register than the source operand, then additional restrictions
- are needed.  */
-  if ((REGNO (SET_DEST (PATTERN (cand->insn)))
-   != REGNO (XEXP (SET_SRC (PATTERN (cand->insn)), 0
+ are needed.  Note we have to handle cases where we have nested
+ extensions in the source operand.  */
+  if (REGNO (SET_DEST (PATTERN (cand->insn)))
+  != REGNO (get_extended_src_reg (SET_SRC (PATTERN (cand->insn)
 {
   /* In theory we could handle more than one reaching def, it
 just makes the code to update the insn stream more complex.  */
   if (state->defs_list.length () != 1)
return false;
 
-  /* We require the candidate not already be modified.  This may
-be overly conservative.  */
+  /* We require the candidate not already be modified.  It may,
+for example have been changed from a (sign_extend (reg))
+into (zero_extend (sign_extend (reg)).
+
+Handling that case shouldn't be terribly difficult, but the code
+here and the code to emit copies would need auditing.  Until
+we see a need, this is the safe thing to do.  */
   if (state->modified[INSN_UID (cand->insn)].kind != EXT_MODIFIED_NONE)
return false;
 
@@ -999,8 +1017,13 @@ find_and_remove_re (void)
   if (dump_file)
 fprintf (dump_file, "Eliminated the extension.\n");
   num_realized++;
- if (REGNO (SET_DEST (PATTERN (curr_cand->insn)))
- != REGNO (XEXP (SET_SRC (PATTERN (curr_cand->insn)), 0)))
+ /* If the RHS of the current candidate is not (extend (reg)), then
+we do not a

[jit] Add the ability to get int types by size/signedness.

[David Malcolm]

Committed to branch dmalcolm/jit:

Provide a way to get a N-byte int with a given signedness.
Also, use template tricks in the C++ wrapper API so that one can
map types by writing e.g.

  gccjit::type index_t_gcc = ctxt.get_int_type  ();

and having the compiler figure out the details of the type and
call into libgccjit accordingly.

gcc/jit/
* libgccjit.h (gcc_jit_context_get_int_type): New.
* libgccjit.map (gcc_jit_context_get_int_type): New.
* libgccjit.c (gcc_jit_context_get_int_type): New.

* internal-api.h (gcc::jit::recording::context::get_int_type): New.
(gcc::jit::recording::context::get_int_type): New template.
* internal-api.c (gcc::jit::recording::context::get_int_type): New.

* libgccjit++.h: Include  so we can use std::numeric_limits.
(gccjit::context::get_int_type): New.
(gccjit::context::get_int_type): New.

gcc/testsuite/
* jit.dg/test-types.c (struct zoo): Add field m_sized_int_type,
to be populated by...
(create_code): Use gcc_jit_context_get_int_type.
(verify_code): Verify that type from gcc_jit_context_get_int_type
works properly.
* jit.dg/test-operator-overloading.cc (make_types): Use the
template form of get_int_type.
* jit.dg/test-quadratic.cc (make_types): Likewise.
---
 gcc/jit/ChangeLog.jit | 14 +
 gcc/jit/internal-api.c| 37 +++
 gcc/jit/internal-api.h|  3 ++
 gcc/jit/libgccjit++.h | 23 ++
 gcc/jit/libgccjit.c   | 10 ++
 gcc/jit/libgccjit.h   |  4 +++
 gcc/jit/libgccjit.map |  1 +
 gcc/testsuite/ChangeLog.jit   | 11 +++
 gcc/testsuite/jit.dg/test-operator-overloading.cc |  2 +-
 gcc/testsuite/jit.dg/test-quadratic.cc|  2 +-
 gcc/testsuite/jit.dg/test-types.c | 18 +++
 11 files changed, 123 insertions(+), 2 deletions(-)

diff --git a/gcc/jit/ChangeLog.jit b/gcc/jit/ChangeLog.jit
index 001cefb..68c38db 100644
--- a/gcc/jit/ChangeLog.jit
+++ b/gcc/jit/ChangeLog.jit
@@ -1,5 +1,19 @@
 2014-02-10  David Malcolm  
 
+   * libgccjit.h (gcc_jit_context_get_int_type): New.
+   * libgccjit.map (gcc_jit_context_get_int_type): New.
+   * libgccjit.c (gcc_jit_context_get_int_type): New.
+
+   * internal-api.h (gcc::jit::recording::context::get_int_type): New.
+   (gcc::jit::recording::context::get_int_type): New template.
+   * internal-api.c (gcc::jit::recording::context::get_int_type): New.
+
+   * libgccjit++.h: Include  so we can use std::numeric_limits.
+   (gccjit::context::get_int_type): New.
+   (gccjit::context::get_int_type): New.
+
+2014-02-10  David Malcolm  
+
* libgccjit.h (gcc_jit_function_get_param): New.
* libgccjit.map (gcc_jit_function_get_param): New.
* libgccjit.c (gcc_jit_function_get_param): New.
diff --git a/gcc/jit/internal-api.c b/gcc/jit/internal-api.c
index 85d8fd1..9ff0eb8 100644
--- a/gcc/jit/internal-api.c
+++ b/gcc/jit/internal-api.c
@@ -215,6 +215,43 @@ recording::context::get_type (enum gcc_jit_types kind)
 }
 
 recording::type *
+recording::context::get_int_type (int num_bytes, int is_signed)
+{
+  /* We can't use a switch here since some of the values are macros affected
+ by options; e.g. i386.h has
+   #define LONG_TYPE_SIZE (TARGET_X32 ? 32 : BITS_PER_WORD)
+ Compare with tree.c's make_or_reuse_type.  Note that the _SIZE macros
+ are in bits, rather than bytes.
+  */
+  const int num_bits = num_bytes * 8;
+  if (num_bits == INT_TYPE_SIZE)
+return get_type (is_signed
+? GCC_JIT_TYPE_INT
+: GCC_JIT_TYPE_UNSIGNED_INT);
+  if (num_bits == CHAR_TYPE_SIZE)
+return get_type (is_signed
+? GCC_JIT_TYPE_SIGNED_CHAR
+: GCC_JIT_TYPE_UNSIGNED_CHAR);
+  if (num_bits == SHORT_TYPE_SIZE)
+return get_type (is_signed
+? GCC_JIT_TYPE_SHORT
+: GCC_JIT_TYPE_UNSIGNED_SHORT);
+  if (num_bits == LONG_TYPE_SIZE)
+return get_type (is_signed
+? GCC_JIT_TYPE_LONG
+: GCC_JIT_TYPE_UNSIGNED_LONG);
+  if (num_bits == LONG_LONG_TYPE_SIZE)
+return get_type (is_signed
+? GCC_JIT_TYPE_LONG_LONG
+: GCC_JIT_TYPE_UNSIGNED_LONG_LONG);
+
+  /* Some other size, not corresponding to the C int types.  */
+  /* To be written: support arbitrary other sizes, sharing by
+ memoizing at the recording::context level?  */
+  gcc_unreachable ();
+}
+
+recording::type *
 recording::context::new_array_type (recording::location *loc,
recording::type *element_type,
int num_elements)
diff --git a/gcc/jit/internal-api.h 

[RS6000] power8 internal compiler errors

[Alan Modra]

Since reload may make multiple passes through insns, rtl seen during
reload can look a little messy.  On the second and subsequent passes
you get to see any transformations made on previous passes.  The rtl
sanity checks in rs6000_secondary_reload_inner didn't take this fact
into account, leading to these PRs..

So, sanity check the rtl as it will be after reload.  It is also
correct for any insn emitted in rs6000_secondary_reload_inner to use
the final rtl too.  Bootstrapped and regression tested
powerpc64-linux.  OK to apply?

PR target/58675
PR target/57935
* config/rs6000/rs6000.c (rs6000_secondary_reload_inner): Use
find_replacement on parts of insn rtl that might be reloaded.

Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 207649)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -16170,7 +16170,7 @@
 rs6000_secondary_reload_fail (__LINE__, reg, mem, scratch, store_p);
 
   rclass = REGNO_REG_CLASS (regno);
-  addr = XEXP (mem, 0);
+  addr = find_replacement (&XEXP (mem, 0));
 
   switch (rclass)
 {
@@ -16181,7 +16181,7 @@
   if (GET_CODE (addr) == AND)
{
  and_op2 = XEXP (addr, 1);
- addr = XEXP (addr, 0);
+ addr = find_replacement (&XEXP (addr, 0));
}
 
   if (GET_CODE (addr) == PRE_MODIFY)
@@ -16190,10 +16190,9 @@
  if (!REG_P (scratch_or_premodify))
rs6000_secondary_reload_fail (__LINE__, reg, mem, scratch, store_p);
 
- if (GET_CODE (XEXP (addr, 1)) != PLUS)
-   rs6000_secondary_reload_fail (__LINE__, reg, mem, scratch, store_p);
-
  addr = XEXP (addr, 1);
+ if (GET_CODE (addr) != PLUS)
+   rs6000_secondary_reload_fail (__LINE__, reg, mem, scratch, store_p);
}
 
   if (GET_CODE (addr) == PLUS
@@ -16201,7 +16200,7 @@
  || !rs6000_legitimate_offset_address_p (PTImode, addr,
  false, true)))
{
- addr_op1 = XEXP (addr, 0);
+ addr_op1 = find_replacement (&XEXP (addr, 0));
  addr_op2 = XEXP (addr, 1);
  if (!legitimate_indirect_address_p (addr_op1, false))
rs6000_secondary_reload_fail (__LINE__, reg, mem, scratch, store_p);
@@ -16276,7 +16275,7 @@
  || !VECTOR_MEM_ALTIVEC_P (mode)))
{
  and_op2 = XEXP (addr, 1);
- addr = XEXP (addr, 0);
+ addr = find_replacement (&XEXP (addr, 0));
}
 
   /* If we aren't using a VSX load, save the PRE_MODIFY register and use it
@@ -16292,10 +16291,9 @@
  if (!legitimate_indirect_address_p (scratch_or_premodify, false))
rs6000_secondary_reload_fail (__LINE__, reg, mem, scratch, store_p);
 
- if (GET_CODE (XEXP (addr, 1)) != PLUS)
-   rs6000_secondary_reload_fail (__LINE__, reg, mem, scratch, store_p);
-
  addr = XEXP (addr, 1);
+ if (GET_CODE (addr) != PLUS)
+   rs6000_secondary_reload_fail (__LINE__, reg, mem, scratch, store_p);
}
 
   if (legitimate_indirect_address_p (addr, false)  /* reg */
@@ -16310,7 +16308,7 @@
 
   else if (GET_CODE (addr) == PLUS)
{
- addr_op1 = XEXP (addr, 0);
+ addr_op1 = find_replacement (&XEXP (addr, 0));
  addr_op2 = XEXP (addr, 1);
  if (!REG_P (addr_op1))
rs6000_secondary_reload_fail (__LINE__, reg, mem, scratch, store_p);

-- 
Alan Modra
Australia Development Lab, IBM

[PATCH] Handle more COMDAT profiling issues

[Teresa Johnson]

This patch attempts to address the lost profile issue for COMDATs in
more circumstances, exposed by function splitting.

My earlier patch handled the case where the comdat had 0 counts since
the linker kept the copy in a different module. In that case we
prevent the guessed frequencies on 0-count functions from being
dropped by counts_to_freq, and then later mark any reached via
non-zero callgraph edges as guessed. Finally, when one such 0-count
comdat is inlined the call count is propagated to the callee blocks
using the guessed probabilities.

However, in this case, there was a comdat that had a very small
non-zero count, that was being inlined to a much hotter callsite. This
could happen when there was a copy that was ipa-inlined
in the profile gen compile, so the copy in that module gets some
non-zero counts from the ipa inlined instance, but when the out of
line copy was eliminated by the linker (selected from a different
module). In this case the inliner was scaling the bb counts up quite a
lot when inlining. The problem is that you most likely can't trust
that the 0 count bbs in such a case are really not executed by the
callsite it is being into, since the counts are very small and
correspond to a different callsite. In some internal C++ applications
I am seeing that we execute out of the split cold portion of COMDATs
for this reason.

This problem is more complicated to address than the 0-count instance,
because we need the cgraph to determine which functions to drop the
profile on, and at that point the estimated frequencies have already
been overwritten by counts_to_freqs. To handle this broader case, I
have changed the drop_profile routine to simply re-estimate the
probabilities/frequencies (and translate these into counts scaled from
the incoming call edge counts). This unfortunately necessitates
rebuilding the cgraph, to propagate the new synthesized counts and
avoid checking failures downstream. But it will only be rebuilt if we
dropped any profiles. With this solution, some of the older approach
can be removed (e.g. propagating counts using the guessed
probabilities during inlining).

Patch is below. Bootstrapped and tested on x86-64-unknown-linux-gnu.
Also tested on
a profile-use build of SPEC cpu2006. Ok for trunk when stage 1 reopens?

Thanks,
Teresa

2014-02-10  Teresa Johnson  

* graphite.c (graphite_finalize): Pass new parameter.
* params.def (PARAM_MIN_CALLER_REESTIMATE_RATIO): New.
* predict.c (tree_estimate_probability): New parameter.
(tree_estimate_probability_worker): Renamed from
tree_estimate_probability_driver.
(tree_reestimate_probability): New function.
(tree_estimate_probability_driver): Invoke
tree_estimate_probability_worker.
(freqs_to_counts): Move from tree-inline.c.
(drop_profile): Re-estimated profiles when dropping counts.
(handle_missing_profiles): Drop for some non-zero functions as well.
(counts_to_freqs): Remove code obviated by reestimation.
* predict.h (handle_missing_profiles): Update declartion.
(tree_estimate_probability): Ditto.
* tree-inline.c (freqs_to_counts): Move to predict.c.
(copy_cfg_body): Remove code obviated by reestimation.
* tree-profile.c (gimple_gen_ior_profiler):
(rebuild_cgraph): Code extracted from tree_profiling to rebuild cgraph.
(tree_profiling): Invoke rebuild_cgraph as needed.

Index: graphite.c
===
--- graphite.c  (revision 207436)
+++ graphite.c  (working copy)
@@ -247,7 +247,7 @@ graphite_finalize (bool need_cfg_cleanup_p)
   cleanup_tree_cfg ();
   profile_status_for_fn (cfun) = PROFILE_ABSENT;
   release_recorded_exits ();
-  tree_estimate_probability ();
+  tree_estimate_probability (false);
 }

   cloog_state_free (cloog_state);
Index: params.def
===
--- params.def  (revision 207436)
+++ params.def  (working copy)
@@ -44,6 +44,12 @@ DEFPARAM (PARAM_PREDICTABLE_BRANCH_OUTCOME,
  "Maximal estimated outcome of branch considered predictable",
  2, 0, 50)

+DEFPARAM (PARAM_MIN_CALLER_REESTIMATE_RATIO,
+ "min-caller-reestimate-ratio",
+ "Minimum caller-to-callee node count ratio to force
reestimated branch "
+  "probabilities in callee (where 0 means only when callee
count is 0)",
+ 10, 0, 0)
+
 DEFPARAM (PARAM_INLINE_MIN_SPEEDUP,
  "inline-min-speedup",
  "The minimal estimated speedup allowing inliner to ignore
inline-insns-single and inline-isnsns-auto",
Index: predict.c
===
--- predict.c   (revision 207436)
+++ predict.c   (working copy)
@@ -2379,10 +2379,12 @@ tree_estimate_probability_bb (basic_block bb)

 /* Predict branch probabilities and estimate profile of the tree CFG.
This function can be ca

Re: [google gcc-4_8][patch] Thunk section names

[Teresa Johnson]

Looks good. Thanks, Teresa

On Thu, Feb 6, 2014 at 2:19 PM, Sriraman Tallam  wrote:
> Patch attached.
>
>
>
>
>
> On Thu, Feb 6, 2014 at 2:18 PM, Sriraman Tallam  wrote:
>> I sent the following patch for review for trunk commit here. Details here:
>> http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00328.html
>>
>> This is important for function layout for the following reason.
>> Without this patch, the thunk's section name is the same as the original
>> function's section name for which the thunk is created.  This affects 
>> function
>> layout as it is not possible to figure out the thunk section from the name
>> alone.  With this patch, the thunk's section name is suffixed with the 
>> mangled
>> name of the thunk and this solves the problem.
>>
>> Is this patch ok for google/gcc-4_8?
>>
>> Sri



-- 
Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413

Re: [google gcc-4_8] unify int and fp scaling in gcov-tool

[Rong Xu]

Yes. They were the bug I mentioned. This patch fixed that.

-Rong

On Mon, Feb 10, 2014 at 10:40 AM, Teresa Johnson  wrote:
> Looks good to me.
>
> A couple questions:
>
>>  static void
>> -__gcov_scale_icall_topn (gcov_type *counters, unsigned n_counters, double f)
>> +__gcov_icall_topn_op (gcov_type *counters, unsigned n_counters,
>> +  counter_op_fn fn, void *data1, void *data2)
>>  {
>>unsigned i;
>>
>> @@ -950,41 +949,65 @@ static void
>>gcov_type *value_array = &counters[i + 1];
>>
>>for (j = 0; j < GCOV_ICALL_TOPN_NCOUNTS - 1; j += 2)
>> -value_array[1] *= f;
>
> Was the above a bug (always updating index 1)?
>
>> +value_array[j + 1] = fn (value_array[j + 1], data1, data2);
>>  }
>>  }
>>
>>  static void
>> -__gcov_scale_dc (gcov_type *counters, unsigned n_counters, double f)
>> +__gcov_dc_op (gcov_type *counters, unsigned n_counters,
>> +  counter_op_fn fn, void *data1, void *data2)
>>  {
>>unsigned i;
>>
>>gcc_assert (!(n_counters % 2));
>>for (i = 0; i < n_counters; i += 2)
>> -counters[1] *= f;
>
> Same question here
>
>> +counters[i + 1] = fn (counters[i + 1], data1, data2);
>>  }
>
> Teresa
>
> On Tue, Feb 4, 2014 at 3:54 PM, Rong Xu  wrote:
>> Hi,
>>
>> The attached patch uses a callback function to unify the integer and
>> floating-point scaling in gcov-tool. (Also fix a bug in fp scaling of
>> ic and dc counters in earlier code).
>>
>> Tested with spec2006 profiles.
>>
>> OK for checking in?
>>
>> Thanks,
>>
>> -Rong
>
>
>
> --
> Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413

RFA: XFAIL gcc.dg/vect/pr56787.c if vect_no_align

[Richard Sandiford]

Not 100% sure whether this is the preferred fix, but gcc.dg/vect/pr56787.c
has lots of float * parameters that point who-knows-where and so is only
vectorised if the target supports misaligned vector accesses:

void
foo (unsigned long n, const float *__restrict u0,
 const float *__restrict u1, const float *__restrict u2,
 const float *__restrict u3, const float *__restrict u4,
 const float *__restrict s0, const float *__restrict s1,
 const float *__restrict s2, float *__restrict t3,
 float *__restrict t4)
{
  unsigned long i;
  for (i = 0; i < n; i++)
{
  float u[5], f[3][5];
  u[0] = u0[i]; u[1] = u1[i]; u[2] = u2[i]; u[3] = u3[i]; u[4] = u4[i];
  bar (u, f);
  t3[i] = s0[i] * f[0][3] + s1[i] * f[1][3] + s2[i] * f[2][3];
}
}

MIPS paired-single doesn't have any form of vector misalignment.
I suppose it would be technically possible to use misaligned
integer accesses and an FPR<->GPR move, but that can be expensive.
I also don't have any hardware to benchmark it on.

So this patch adds an xfail for vect_no_align.  Tested on mipsisa64-sde-elf.
OK to install?

Thanks,
Richard


gcc/testsuite/
* gcc.dg/vect/pr56787.c: Mark as xfail for vect_no_align.

Index: gcc/testsuite/gcc.dg/vect/pr56787.c
===
--- gcc/testsuite/gcc.dg/vect/pr56787.c 2014-02-10 20:26:03.870867802 +
+++ gcc/testsuite/gcc.dg/vect/pr56787.c 2014-02-10 20:36:42.072279177 +
@@ -31,5 +31,5 @@ foo (unsigned long n, const float *__res
 }
 }
 
-/* { dg-final { scan-tree-dump "vectorized 1 loops" "vect" } } */
+/* { dg-final { scan-tree-dump "vectorized 1 loops" "vect" { xfail 
vect_no_align } } } */
 /* { dg-final { cleanup-tree-dump "vect" } } */

[committed] Add some missing vect_ints

[Richard Sandiford]

Add /* { dg-require-effective-target vect_int } */ to some tests that
require integer vectorisation.  pr57741-3.c is mostly a float test but
also has a char array (r) that needs to be vectorised.  The others are
pure integer tests.

Tested on mipsisa64-sde-elf and applied as obvious.

Thanks,
Richard


gcc/testsuite/
* gcc.dg/vect/pr57741-3.c: Require vect_int.
* gcc.dg/vect/pr60012.c: Likewise.
* gcc.dg/vect/vect-119.c: Likewise.
* gcc.dg/vect/vect-outer-4c-big-array.c: Likewise.
* gcc.dg/vect/vect-outer-4c.c: Likewise.

Index: gcc/testsuite/gcc.dg/vect/pr57741-3.c
===
--- gcc/testsuite/gcc.dg/vect/pr57741-3.c   2014-02-10 20:26:03.870867802 
+
+++ gcc/testsuite/gcc.dg/vect/pr57741-3.c   2014-02-10 20:26:36.497145630 
+
@@ -1,6 +1,7 @@
 /* PR tree-optimization/57741 */
 /* { dg-do run } */
 /* { dg-require-effective-target vect_float } */
+/* { dg-require-effective-target vect_int } */
 /* { dg-additional-options "-ffast-math" } */
 
 #include "tree-vect.h"
Index: gcc/testsuite/gcc.dg/vect/pr60012.c
===
--- gcc/testsuite/gcc.dg/vect/pr60012.c 2014-02-10 20:26:03.870867802 +
+++ gcc/testsuite/gcc.dg/vect/pr60012.c 2014-02-10 20:26:36.498145638 +
@@ -1,4 +1,5 @@
 /* { dg-do compile } */
+/* { dg-require-effective-target vect_int } */
 /* { dg-additional-options "--param vect-max-version-for-alias-checks=0" } */
 
 typedef struct
Index: gcc/testsuite/gcc.dg/vect/vect-119.c
===
--- gcc/testsuite/gcc.dg/vect/vect-119.c2014-02-10 20:26:03.870867802 
+
+++ gcc/testsuite/gcc.dg/vect/vect-119.c2014-02-10 20:26:36.498145638 
+
@@ -1,4 +1,5 @@
 /* { dg-do compile } */
+/* { dg-require-effective-target vect_int } */
 
 #define OUTER 32
 #define INNER 40
Index: gcc/testsuite/gcc.dg/vect/vect-outer-4c-big-array.c
===
--- gcc/testsuite/gcc.dg/vect/vect-outer-4c-big-array.c 2014-02-10 
20:26:03.870867802 +
+++ gcc/testsuite/gcc.dg/vect/vect-outer-4c-big-array.c 2014-02-10 
20:26:36.498145638 +
@@ -1,4 +1,5 @@
 /* { dg-do compile } */
+/* { dg-require-effective-target vect_int } */
 
 #define N 320
 #define M 1024
Index: gcc/testsuite/gcc.dg/vect/vect-outer-4c.c
===
--- gcc/testsuite/gcc.dg/vect/vect-outer-4c.c   2014-02-10 20:26:03.870867802 
+
+++ gcc/testsuite/gcc.dg/vect/vect-outer-4c.c   2014-02-10 20:26:36.498145638 
+
@@ -1,4 +1,5 @@
 /* { dg-do compile } */
+/* { dg-require-effective-target vect_int } */
 
 #define N 40
 #define M 128

Re: Ping: PR target/59605: Create jump_around_label only if it doesn't exist

[H.J. Lu]

On Mon, Feb 10, 2014 at 11:54 AM, Richard Sandiford
 wrote:
> "H.J. Lu"  writes:
>> On Sat, Feb 1, 2014 at 2:28 AM, Richard Sandiford
>>  wrote:
>>> "H.J. Lu"  writes:
 On Thu, Jan 30, 2014 at 10:43 AM, Richard Sandiford
  wrote:
> Hi H.J.,
>
> "H.J. Lu"  writes:
>> diff --git a/gcc/testsuite/gcc.dg/pr59605.c
>> b/gcc/testsuite/gcc.dg/pr59605.c
>> new file mode 100644
>> index 000..4556843
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.dg/pr59605.c
>> @@ -0,0 +1,55 @@
>> +/* { dg-do run } */
>> +/* { dg-options "-O2" } */
>> +/* { dg-additional-options "-minline-stringops-dynamically" { target
>> { i?86-*-* x86_64-*-* } } } */
>> +
>> +extern void abort (void);
>> +
>> +#define MAX_OFFSET (sizeof (long long))
>> +#define MAX_COPY (1024 + 8192)
>> +#define MAX_EXTRA (sizeof (long long))
>> +
>> +#define MAX_LENGTH (MAX_OFFSET + MAX_COPY + MAX_EXTRA)
>> +
>> +static union {
>> +  char buf[MAX_LENGTH];
>> +  long long align_int;
>> +  long double align_fp;
>> +} u;
>> +
>> +char A[MAX_LENGTH];
>> +
>> +int
>> +main ()
>> +{
>> +  int off, len, i;
>> +  char *p, *q;
>> +
>> +  for (i = 0; i < MAX_LENGTH; i++)
>> +A[i] = 'A';
>> +
>> +  for (off = 0; off < MAX_OFFSET; off++)
>> +for (len = 1; len < MAX_COPY; len++)
>> +  {
>> + for (i = 0; i < MAX_LENGTH; i++)
>> +   u.buf[i] = 'a';
>> +
>> + p = __builtin_memcpy (u.buf + off, A, len);
>> + if (p != u.buf + off)
>> +   abort ();
>> +
>> + q = u.buf;
>> + for (i = 0; i < off; i++, q++)
>> +   if (*q != 'a')
>> + abort ();
>> +
>> + for (i = 0; i < len; i++, q++)
>> +   if (*q != 'A')
>> + abort ();
>> +
>> + for (i = 0; i < MAX_EXTRA; i++, q++)
>> +   if (*q != 'a')
>> + abort ();
>> +  }
>> +
>> +  return 0;
>> +}
>
> The innermost loop bodies are executed over 6x10⁸ times on most targets
> and so the test times out for me when using the GDB MIPS simulator.
> I'm not sure what the best fix is though.  E.g.:
>
> 1. It looks like the PR was for a compile-time failure rather than a
> run-time
>failure, so one option might be to drop it to dg-do compile.  That'd 
> lose
>a nice executable conformance test though.  I don't like this option.
>
> 2. We could drop it to dg-do compile for simulator targets only.
> That's still
>lose some conformance testing for simulator targets.
>
> 3. We could use a smaller MAX_COPY for simulator targets, which is 
> typically
>how check_effective_target_simulator is used.  I'm not sure
> whether having
>a smaller MAX_COPY would defeat the original ICE test though.
>
> 4. We could split the test into two, a dg-do compile one and a dg-do
> run one.
>We could then do (3) on the run one.
>
> But there are probably other alternatives too.
>
> I'm willing to do the patch, but has anyone got any suggestions for
> what would be best?
>

 Can you reduce the loop count and still trigger the bug without
 the fix?
>>>
>>> Not by much.  AFAICT the lowest MAX_COPY for which the ICE still triggers
>>> is 8194, which only reduces the 6x10⁸ to something over 5.38x10⁸.
>>>
>>> So I think it's a choice between (2) and (4).  How about the patch below?
>>> Tested on mipsisa64-sde-elf and x86_64-linux-gnu.  Both tests failed before
>>> the i386.c fix.
>>>
>>> Thanks,
>>> Richard
>>>
>>>
>>> gcc/testsuite/
>>> * gcc.dg/pr59605.c: Convert to a compile test.  Protect MAX_COPY
>>> definition with an ifdef.
>>> * gcc.dg/pr59605-2.c: New test.
>>>
>>> Index: gcc/testsuite/gcc.dg/pr59605-2.c
>>> ===
>>> --- /dev/null   2014-01-30 08:06:21.701666182 +
>>> +++ gcc/testsuite/gcc.dg/pr59605-2.c2014-02-01 10:25:08.674430391 +
>>> @@ -0,0 +1,6 @@
>>> +/* { dg-do run } */
>>> +/* { dg-options "-O2" } */
>>> +/* { dg-additional-options "-DMAX_COPY=1025" { target simulator } } */
>>> +/* { dg-additional-options "-minline-stringops-dynamically" { target { 
>>> i?86-*-* x86_64-*-* } } } */
>>> +
>>> +#include "pr59605.c"
>>> Index: gcc/testsuite/gcc.dg/pr59605.c
>>> ===
>>> --- gcc/testsuite/gcc.dg/pr59605.c  2014-02-01 10:13:26.176018090 +
>>> +++ gcc/testsuite/gcc.dg/pr59605.c  2014-02-01 10:24:22.713003808 +
>>> @@ -1,11 +1,13 @@
>>> -/* { dg-do run } */
>>> +/* { dg-do compile } */
>>>  /* { dg-options "-O2" } */
>>>  /* { dg-additional-options "-minline-stringops-dynamically" { target { 
>>> i?86-*-* x86_64-*-* } } } */
>>>
>>>  extern void abort (void);
>>>
>>>  #define MAX_OFFSET (s

[jit] Add gcc_jit_function_get_param

[David Malcolm]

Committed to branch dmalcolm/jit:

gcc/jit/
* libgccjit.h (gcc_jit_function_get_param): New.
* libgccjit.map (gcc_jit_function_get_param): New.
* libgccjit.c (gcc_jit_function_get_param): New.
* libgccjit++.h (gccjit::function::get_param): New.
---
 gcc/jit/ChangeLog.jit |  7 +++
 gcc/jit/libgccjit++.h |  9 +
 gcc/jit/libgccjit.c   | 17 +
 gcc/jit/libgccjit.h   |  3 +++
 gcc/jit/libgccjit.map |  1 +
 5 files changed, 37 insertions(+)

diff --git a/gcc/jit/ChangeLog.jit b/gcc/jit/ChangeLog.jit
index 8b3c947..001cefb 100644
--- a/gcc/jit/ChangeLog.jit
+++ b/gcc/jit/ChangeLog.jit
@@ -1,5 +1,12 @@
 2014-02-10  David Malcolm  
 
+   * libgccjit.h (gcc_jit_function_get_param): New.
+   * libgccjit.map (gcc_jit_function_get_param): New.
+   * libgccjit.c (gcc_jit_function_get_param): New.
+   * libgccjit++.h (gccjit::function::get_param): New.
+
+2014-02-10  David Malcolm  
+
* libgccjit++.h (gccjit::object::get_inner_object): Make const.
(gccjit::location::get_inner_location): Likewise.
(gccjit::field::get_inner_field): Likewise.
diff --git a/gcc/jit/libgccjit++.h b/gcc/jit/libgccjit++.h
index f3c26ee..74c02ea 100644
--- a/gcc/jit/libgccjit++.h
+++ b/gcc/jit/libgccjit++.h
@@ -259,6 +259,8 @@ namespace gccjit
 
 gcc_jit_function *get_inner_function () const;
 
+param get_param (int index);
+
 label new_forward_label ();
 label new_forward_label (const std::string &name);
 
@@ -970,6 +972,13 @@ function::get_inner_function () const
   return reinterpret_cast (get_inner_object ());
 }
 
+inline param
+function::get_param (int index)
+{
+  return param (gcc_jit_function_get_param (get_inner_function (),
+   index));
+}
+
 inline label
 function::new_forward_label ()
 {
diff --git a/gcc/jit/libgccjit.c b/gcc/jit/libgccjit.c
index 3f39984..da1afdc 100644
--- a/gcc/jit/libgccjit.c
+++ b/gcc/jit/libgccjit.c
@@ -397,6 +397,23 @@ gcc_jit_function_as_object (gcc_jit_function *func)
   return static_cast  (func->as_object ());
 }
 
+gcc_jit_param *
+gcc_jit_function_get_param (gcc_jit_function *func, int index)
+{
+  RETURN_NULL_IF_FAIL (func, NULL, "NULL function");
+  gcc::jit::recording::context *ctxt = func->m_ctxt;
+  RETURN_NULL_IF_FAIL (index >= 0, ctxt, "negative index");
+  int num_params = func->get_params ().length ();
+  RETURN_NULL_IF_FAIL_PRINTF3 (index < num_params,
+  ctxt,
+  "index of %d is too large (%s has %d params)",
+  index,
+  func->get_debug_string (),
+  num_params);
+
+  return static_cast  (func->get_param (index));
+}
+
 gcc_jit_label*
 gcc_jit_function_new_forward_label (gcc_jit_function *func,
const char *name)
diff --git a/gcc/jit/libgccjit.h b/gcc/jit/libgccjit.h
index e0161ba..03e9ff8 100644
--- a/gcc/jit/libgccjit.h
+++ b/gcc/jit/libgccjit.h
@@ -435,6 +435,9 @@ gcc_jit_context_new_function (gcc_jit_context *ctxt,
 extern gcc_jit_object *
 gcc_jit_function_as_object (gcc_jit_function *func);
 
+extern gcc_jit_param *
+gcc_jit_function_get_param (gcc_jit_function *func, int index);
+
 /* Create a label, to be placed later.
 
The name can be NULL, or you can give it a meaningful name, which
diff --git a/gcc/jit/libgccjit.map b/gcc/jit/libgccjit.map
index 6dc700d..45b2a2f 100644
--- a/gcc/jit/libgccjit.map
+++ b/gcc/jit/libgccjit.map
@@ -39,6 +39,7 @@
 gcc_jit_function_add_label;
 gcc_jit_function_add_return;
 gcc_jit_function_as_object;
+gcc_jit_function_get_param;
 gcc_jit_function_new_forward_label;
 gcc_jit_function_new_local;
 gcc_jit_function_new_loop;
-- 
1.7.11.7

Ping: PR target/59605: Create jump_around_label only if it doesn't exist

[Richard Sandiford]

"H.J. Lu"  writes:
> On Sat, Feb 1, 2014 at 2:28 AM, Richard Sandiford
>  wrote:
>> "H.J. Lu"  writes:
>>> On Thu, Jan 30, 2014 at 10:43 AM, Richard Sandiford
>>>  wrote:
 Hi H.J.,

 "H.J. Lu"  writes:
> diff --git a/gcc/testsuite/gcc.dg/pr59605.c
> b/gcc/testsuite/gcc.dg/pr59605.c
> new file mode 100644
> index 000..4556843
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/pr59605.c
> @@ -0,0 +1,55 @@
> +/* { dg-do run } */
> +/* { dg-options "-O2" } */
> +/* { dg-additional-options "-minline-stringops-dynamically" { target
> { i?86-*-* x86_64-*-* } } } */
> +
> +extern void abort (void);
> +
> +#define MAX_OFFSET (sizeof (long long))
> +#define MAX_COPY (1024 + 8192)
> +#define MAX_EXTRA (sizeof (long long))
> +
> +#define MAX_LENGTH (MAX_OFFSET + MAX_COPY + MAX_EXTRA)
> +
> +static union {
> +  char buf[MAX_LENGTH];
> +  long long align_int;
> +  long double align_fp;
> +} u;
> +
> +char A[MAX_LENGTH];
> +
> +int
> +main ()
> +{
> +  int off, len, i;
> +  char *p, *q;
> +
> +  for (i = 0; i < MAX_LENGTH; i++)
> +A[i] = 'A';
> +
> +  for (off = 0; off < MAX_OFFSET; off++)
> +for (len = 1; len < MAX_COPY; len++)
> +  {
> + for (i = 0; i < MAX_LENGTH; i++)
> +   u.buf[i] = 'a';
> +
> + p = __builtin_memcpy (u.buf + off, A, len);
> + if (p != u.buf + off)
> +   abort ();
> +
> + q = u.buf;
> + for (i = 0; i < off; i++, q++)
> +   if (*q != 'a')
> + abort ();
> +
> + for (i = 0; i < len; i++, q++)
> +   if (*q != 'A')
> + abort ();
> +
> + for (i = 0; i < MAX_EXTRA; i++, q++)
> +   if (*q != 'a')
> + abort ();
> +  }
> +
> +  return 0;
> +}

 The innermost loop bodies are executed over 6x10⁸ times on most targets
 and so the test times out for me when using the GDB MIPS simulator.
 I'm not sure what the best fix is though.  E.g.:

 1. It looks like the PR was for a compile-time failure rather than a
 run-time
failure, so one option might be to drop it to dg-do compile.  That'd 
 lose
a nice executable conformance test though.  I don't like this option.

 2. We could drop it to dg-do compile for simulator targets only.
 That's still
lose some conformance testing for simulator targets.

 3. We could use a smaller MAX_COPY for simulator targets, which is 
 typically
how check_effective_target_simulator is used.  I'm not sure
 whether having
a smaller MAX_COPY would defeat the original ICE test though.

 4. We could split the test into two, a dg-do compile one and a dg-do
 run one.
We could then do (3) on the run one.

 But there are probably other alternatives too.

 I'm willing to do the patch, but has anyone got any suggestions for
 what would be best?

>>>
>>> Can you reduce the loop count and still trigger the bug without
>>> the fix?
>>
>> Not by much.  AFAICT the lowest MAX_COPY for which the ICE still triggers
>> is 8194, which only reduces the 6x10⁸ to something over 5.38x10⁸.
>>
>> So I think it's a choice between (2) and (4).  How about the patch below?
>> Tested on mipsisa64-sde-elf and x86_64-linux-gnu.  Both tests failed before
>> the i386.c fix.
>>
>> Thanks,
>> Richard
>>
>>
>> gcc/testsuite/
>> * gcc.dg/pr59605.c: Convert to a compile test.  Protect MAX_COPY
>> definition with an ifdef.
>> * gcc.dg/pr59605-2.c: New test.
>>
>> Index: gcc/testsuite/gcc.dg/pr59605-2.c
>> ===
>> --- /dev/null   2014-01-30 08:06:21.701666182 +
>> +++ gcc/testsuite/gcc.dg/pr59605-2.c2014-02-01 10:25:08.674430391 +
>> @@ -0,0 +1,6 @@
>> +/* { dg-do run } */
>> +/* { dg-options "-O2" } */
>> +/* { dg-additional-options "-DMAX_COPY=1025" { target simulator } } */
>> +/* { dg-additional-options "-minline-stringops-dynamically" { target { 
>> i?86-*-* x86_64-*-* } } } */
>> +
>> +#include "pr59605.c"
>> Index: gcc/testsuite/gcc.dg/pr59605.c
>> ===
>> --- gcc/testsuite/gcc.dg/pr59605.c  2014-02-01 10:13:26.176018090 +
>> +++ gcc/testsuite/gcc.dg/pr59605.c  2014-02-01 10:24:22.713003808 +
>> @@ -1,11 +1,13 @@
>> -/* { dg-do run } */
>> +/* { dg-do compile } */
>>  /* { dg-options "-O2" } */
>>  /* { dg-additional-options "-minline-stringops-dynamically" { target { 
>> i?86-*-* x86_64-*-* } } } */
>>
>>  extern void abort (void);
>>
>>  #define MAX_OFFSET (sizeof (long long))
>> +#ifndef MAX_COPY
>>  #define MAX_COPY (1024 + 8192)
>> +#endif
>>  #define MAX_EXTRA (sizeof (long long))
>>
>>  #define MAX_LENGTH (MAX_OFFSET + MAX_COPY + MAX_EXTRA)
>
> That is fine w

[jit] Mark "get_inner_" methods as const within C++ wrapper API.

[David Malcolm]

Committed to branch dmalcolm/jit:

gcc/jit/
* libgccjit++.h (gccjit::object::get_inner_object): Make const.
(gccjit::location::get_inner_location): Likewise.
(gccjit::field::get_inner_field): Likewise.
(gccjit::type::get_inner_type): Likewise.
(gccjit::function::get_inner_function): Likewise.
(gccjit::label::get_inner_label): Likewise.
(gccjit::rvalue::get_inner_rvalue): Likewise.
(gccjit::lvalue::get_inner_lvalue): Likewise.
(gccjit::param::get_inner_param): Likewise.
---
 gcc/jit/ChangeLog.jit | 12 
 gcc/jit/libgccjit++.h | 34 +-
 2 files changed, 29 insertions(+), 17 deletions(-)

diff --git a/gcc/jit/ChangeLog.jit b/gcc/jit/ChangeLog.jit
index 9b44728..8b3c947 100644
--- a/gcc/jit/ChangeLog.jit
+++ b/gcc/jit/ChangeLog.jit
@@ -1,5 +1,17 @@
 2014-02-10  David Malcolm  
 
+   * libgccjit++.h (gccjit::object::get_inner_object): Make const.
+   (gccjit::location::get_inner_location): Likewise.
+   (gccjit::field::get_inner_field): Likewise.
+   (gccjit::type::get_inner_type): Likewise.
+   (gccjit::function::get_inner_function): Likewise.
+   (gccjit::label::get_inner_label): Likewise.
+   (gccjit::rvalue::get_inner_rvalue): Likewise.
+   (gccjit::lvalue::get_inner_lvalue): Likewise.
+   (gccjit::param::get_inner_param): Likewise.
+
+2014-02-10  David Malcolm  
+
* libgccjit++.h (gccjit::object::get_context): New method.
(gccjit::function): Add overloaded operator () for various
numbers of arguments as a very terse way of creating function calls.
diff --git a/gcc/jit/libgccjit++.h b/gcc/jit/libgccjit++.h
index fab1a74..f3c26ee 100644
--- a/gcc/jit/libgccjit++.h
+++ b/gcc/jit/libgccjit++.h
@@ -35,7 +35,7 @@ namespace gccjit
 object ();
 object (gcc_jit_object *obj);
 
-gcc_jit_object *get_inner_object ();
+gcc_jit_object *get_inner_object () const;
 
   private:
 gcc_jit_object *m_inner_obj;
@@ -54,7 +54,7 @@ namespace gccjit
 location ();
 location (gcc_jit_location *loc);
 
-gcc_jit_location *get_inner_location ();
+gcc_jit_location *get_inner_location () const;
   };
 
   class context
@@ -236,7 +236,7 @@ namespace gccjit
 field ();
 field (gcc_jit_field *inner);
 
-gcc_jit_field *get_inner_field ();
+gcc_jit_field *get_inner_field () const;
   };
 
   class type : public object
@@ -245,7 +245,7 @@ namespace gccjit
 type ();
 type (gcc_jit_type *inner);
 
-gcc_jit_type *get_inner_type ();
+gcc_jit_type *get_inner_type () const;
 
 type get_pointer ();
 
@@ -257,7 +257,7 @@ namespace gccjit
 function ();
 function (gcc_jit_function *func);
 
-gcc_jit_function *get_inner_function ();
+gcc_jit_function *get_inner_function () const;
 
 label new_forward_label ();
 label new_forward_label (const std::string &name);
@@ -316,7 +316,7 @@ namespace gccjit
 label ();
 label (gcc_jit_label *inner);
 
-gcc_jit_label *get_inner_label ();
+gcc_jit_label *get_inner_label () const;
   };
 
   class rvalue : public object
@@ -324,7 +324,7 @@ namespace gccjit
   public:
 rvalue ();
 rvalue (gcc_jit_rvalue *inner);
-gcc_jit_rvalue *get_inner_rvalue ();
+gcc_jit_rvalue *get_inner_rvalue () const;
 
 type get_type ();
 
@@ -343,7 +343,7 @@ namespace gccjit
 lvalue ();
 lvalue (gcc_jit_lvalue *inner);
 
-gcc_jit_lvalue *get_inner_lvalue ();
+gcc_jit_lvalue *get_inner_lvalue () const;
 
 lvalue access_field (field field,
 location loc = location ());
@@ -357,7 +357,7 @@ namespace gccjit
 param ();
 param (gcc_jit_param *inner);
 
-gcc_jit_param *get_inner_param ();
+gcc_jit_param *get_inner_param () const;
   };
 
 
@@ -901,7 +901,7 @@ inline object::object () : m_inner_obj (NULL) {}
 inline object::object (gcc_jit_object *obj) : m_inner_obj (obj) {}
 
 inline gcc_jit_object *
-object::get_inner_object ()
+object::get_inner_object () const
 {
   return m_inner_obj;
 }
@@ -919,7 +919,7 @@ inline location::location (gcc_jit_location *loc)
 {}
 
 inline gcc_jit_location *
-location::get_inner_location ()
+location::get_inner_location () const
 {
   /* Manual downcast: */
   return reinterpret_cast (get_inner_object ());
@@ -932,7 +932,7 @@ inline field::field (gcc_jit_field *inner)
 {}
 
 inline gcc_jit_field *
-field::get_inner_field ()
+field::get_inner_field () const
 {
   /* Manual downcast: */
   return reinterpret_cast (get_inner_object ());
@@ -945,7 +945,7 @@ inline type::type (gcc_jit_type *inner)
 {}
 
 inline gcc_jit_type *
-type::get_inner_type ()
+type::get_inner_type () const
 {
   /* Manual downcast: */
   return reinterpret_cast (get_inner_object ());
@@ -964,7 +964,7 @@ inline function::function (gcc_jit_function *inner)
 {}
 
 inline gcc_jit_function *
-function::get_inner_function ()
+function::get_inner_function () const
 {
   /* Manual downcast: */

[jit] Add operator overloading to the C++ API.

[David Malcolm]

Committed to branch dmalcolm/jit:

gcc/jit/
* libgccjit++.h (gccjit::object::get_context): New method.
(gccjit::function): Add overloaded operator () for various
numbers of arguments as a very terse way of creating function calls.
(gccjit::rvalue::get_type): New method.

(operator-): New overloaded unary op for rvalues.
(operator~): Likewise.
(operator!): Likewise.

(operator+): New overloaded binary op for rvalues.
(operator-): Likewise.
(operator*): Likewise.
(operator/): Likewise.
(operator%): Likewise.
(operator&): Likewise.
(operator^): Likewise.
(operator|): Likewise.
(operator&&): Likewise.
(operator||): Likewise.

(operator==): New overloaded comparison for rvalues.
(operator!=): Likewise.
(operator<): Likewise.
(operator<=): Likewise.
(operator>): Likewise.
(operator>=): Likewise.

(operator*): New overloaded operator for dereferencing an
rvalue representing a pointer.

* libgccjit.c (gcc_jit_rvalue_get_type): New.
* libgccjit.h (gcc_jit_rvalue_get_type): New.
* libgccjit.map (gcc_jit_rvalue_get_type): New.

gcc/testsuite/
* jit.dg/test-operator-overloading.cc: New testcase, a
rewrite of test-quadratic.cc to use operator overloading.
---
 gcc/jit/ChangeLog.jit |  36 +++
 gcc/jit/libgccjit++.h | 173 
 gcc/jit/libgccjit.c   |   8 +
 gcc/jit/libgccjit.h   |   3 +
 gcc/jit/libgccjit.map |   1 +
 gcc/testsuite/ChangeLog.jit   |   5 +
 gcc/testsuite/jit.dg/test-operator-overloading.cc | 306 ++
 7 files changed, 532 insertions(+)
 create mode 100644 gcc/testsuite/jit.dg/test-operator-overloading.cc

diff --git a/gcc/jit/ChangeLog.jit b/gcc/jit/ChangeLog.jit
index bd209ed..9b44728 100644
--- a/gcc/jit/ChangeLog.jit
+++ b/gcc/jit/ChangeLog.jit
@@ -1,5 +1,41 @@
 2014-02-10  David Malcolm  
 
+   * libgccjit++.h (gccjit::object::get_context): New method.
+   (gccjit::function): Add overloaded operator () for various
+   numbers of arguments as a very terse way of creating function calls.
+   (gccjit::rvalue::get_type): New method.
+
+   (operator-): New overloaded unary op for rvalues.
+   (operator~): Likewise.
+   (operator!): Likewise.
+
+   (operator+): New overloaded binary op for rvalues.
+   (operator-): Likewise.
+   (operator*): Likewise.
+   (operator/): Likewise.
+   (operator%): Likewise.
+   (operator&): Likewise.
+   (operator^): Likewise.
+   (operator|): Likewise.
+   (operator&&): Likewise.
+   (operator||): Likewise.
+
+   (operator==): New overloaded comparison for rvalues.
+   (operator!=): Likewise.
+   (operator<): Likewise.
+   (operator<=): Likewise.
+   (operator>): Likewise.
+   (operator>=): Likewise.
+
+   (operator*): New overloaded operator for dereferencing an
+   rvalue representing a pointer.
+
+   * libgccjit.c (gcc_jit_rvalue_get_type): New.
+   * libgccjit.h (gcc_jit_rvalue_get_type): New.
+   * libgccjit.map (gcc_jit_rvalue_get_type): New.
+
+2014-02-10  David Malcolm  
+
* libgccjit++.h (gccjit::context::new_minus): New method,
providing a way to do a specific unary op with less typing.
(gccjit::context::new_bitwise_negate): Likewise.
diff --git a/gcc/jit/libgccjit++.h b/gcc/jit/libgccjit++.h
index ff22d1e..fab1a74 100644
--- a/gcc/jit/libgccjit++.h
+++ b/gcc/jit/libgccjit++.h
@@ -27,6 +27,8 @@ namespace gccjit
   class object
   {
   public:
+context get_context () const;
+
 std::string get_debug_string () const;
 
   protected:
@@ -296,6 +298,16 @@ namespace gccjit
 
 void add_return (rvalue rvalue,
 location loc = location ());
+
+/* A series of overloaded operator () with various numbers of arguments
+   for a very terse way of creating a call to this function.  The call
+   is created within the same context as the function itself, which may
+   not be what you want.  */
+rvalue operator() (location loc = location ());
+rvalue operator() (rvalue arg0,
+  location loc = location ());
+rvalue operator() (rvalue arg0, rvalue arg1,
+  location loc = location ());
   };
 
   class label : public object
@@ -314,6 +326,8 @@ namespace gccjit
 rvalue (gcc_jit_rvalue *inner);
 gcc_jit_rvalue *get_inner_rvalue ();
 
+type get_type ();
+
 rvalue access_field (field field,
 location loc = location ());
 
@@ -345,6 +359,42 @@ namespace gccjit
 
 gcc_jit_param *get_inner_param ();
   };
+
+
+  /* Overloaded operators, for those who want the most terse API
+ (at the possible risk

[VxWorks] Allow --enable-threads=posix

[rbmj]

Some builds of VxWorks have a pthread compatibility layer.  This patch 
allows one to compile GCC to use the pthread compatibility layer instead 
of the native vxworks threads.


I wrote this patch to get the c++11 threads to work - the vxworks native 
support don't implement all the necessary features, and it was much 
easier to use posix threads rather than add the necessary native thread 
support.


I do not have commit access, so someone would have to apply this for me.

Everything builds correctly, and users report success.

It does dirty up ghtr-posix.h a bit, but it doesn't appear to be too 
bad, and there's other platform-specific hacks in that file already.


Thanks,

R Blair Mason
>From 2cf34e06f47345884f234bb870714ed2896745a6 Mon Sep 17 00:00:00 2001
From: rbmj 
Date: Sat, 4 Jan 2014 09:11:02 -0500
Subject: [PATCH] Allowed posix as a thread option for vxworks

Note: VxWorks defines all of the _POSIX_TIMERS functions, but doesn't
define the macro.  Configure looks for the _POSIX_TIMERS macro when
checking for these functions.  This seems strange to me.  It seems like
if the try_compile can find them, then everything should be fine.
I'm not an expert though, and acinclude.m4 notes that there is a similar
situation for darwin, so I'll just let it be this way for now.
---
 gcc/config.gcc  |  1 +
 libgcc/config.host  |  8 ++
 libgcc/config/t-vxworks-pthread | 14 +++
 libgcc/gthr-posix.h | 38 -
 libstdc++-v3/config/os/vxworks/os_defines.h |  3 +++
 5 files changed, 63 insertions(+), 1 deletion(-)
 create mode 100644 libgcc/config/t-vxworks-pthread

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 92d57dd..3fd9bb5 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -804,6 +804,7 @@ case ${target} in
   case ${enable_threads} in
 no) ;;
 "" | yes | vxworks) thread_file='vxworks' ;;
+posix) thread_file='posix' ;;
 *) echo 'Unknown thread configuration for VxWorks'; exit 1 ;;
   esac
   ;;
diff --git a/libgcc/config.host b/libgcc/config.host
index 259c9a7..21471db 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -261,6 +261,14 @@ case ${host} in
   ;;
 *-*-vxworks*)
   tmake_file=t-vxworks
+  case ${target_thread_file} in
+vxworks)
+  tmake_file=t-vxworks
+  ;;
+posix)
+  tmake_file=t-vxworks-pthread
+	  ;;
+  esac
   ;;
 *-*-elf)
   extra_parts="crtbegin.o crtend.o"
diff --git a/libgcc/config/t-vxworks-pthread b/libgcc/config/t-vxworks-pthread
new file mode 100644
index 000..4e538f9
--- /dev/null
+++ b/libgcc/config/t-vxworks-pthread
@@ -0,0 +1,14 @@
+# Don't build libgcc.a with debug info
+LIBGCC2_DEBUG_CFLAGS =
+
+# No out-of line help needed
+LIB2ADD = 
+
+# This ensures that the correct target headers are used; some
+# VxWorks system headers have names that collide with GCC's
+# internal (host) headers, e.g. regs.h.
+LIBGCC2_INCLUDES = -nostdinc -I \
+  `case "/$$(MULTIDIR)" in \
+ */mrtp*) echo $(WIND_USR)/h ;; \
+ *) echo $(WIND_BASE)/target/h ;; \
+   esac`
diff --git a/libgcc/gthr-posix.h b/libgcc/gthr-posix.h
index f0d8cd7..b6a6069 100644
--- a/libgcc/gthr-posix.h
+++ b/libgcc/gthr-posix.h
@@ -33,6 +33,10 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 #define __GTHREADS_CXX0X 1
 
 #include 
+/* For timespec, in case pthread.h doesn't include this */
+#include 
+/* For sched_yield, in case pthread.h doesn't include this */
+#include 
 
 #if ((defined(_LIBOBJC) || defined(_LIBOBJC_WEAK)) \
  || !defined(_GTHREAD_USE_MUTEX_TIMEDLOCK))
@@ -130,10 +134,42 @@ __gthrw(pthread_cond_destroy)
 
 __gthrw(pthread_key_create)
 __gthrw(pthread_key_delete)
+
 __gthrw(pthread_mutexattr_init)
-__gthrw(pthread_mutexattr_settype)
 __gthrw(pthread_mutexattr_destroy)
 
+/* VxWorks does not define pthread_mutexattr_settype itself, and we need
+   the constants and a prototype to be defined somewhere so the rest of 
+   this file will compile (they will be ignored) */
+#ifdef __VXWORKS__
+
+#define ATTRIBUTE_UNUSED __attribute__((unused))
+
+static inline int
+__gthrw_pthread_mutexattr_settype (pthread_mutexattr_t *a ATTRIBUTE_UNUSED, int t ATTRIBUTE_UNUSED)
+{
+  /* TODO:  It might be possible to override the mutex machinery to
+ simulate non-recursive mutexes, but this doesn't seem to be
+ necessary because all vxworks mutexes are recursive, and recursive
+ mutexes cover the most general case. */
+  return 0;
+}
+
+#undef ATTRIBUTE_UNUSED
+
+#define PTHREAD_MUTEX_NORMAL 0
+#define PTHREAD_MUTEX_ERRORCHECK 0
+#define PTHREAD_MUTEX_RECURSIVE 0
+#define PTHREAD_MUTEX_DEFAULT 0
+
+#else
+
+__gthrw(pthread_mutexattr_settype)
+
+#endif 
+
+
+
 
 #if defined(_LIBOBJC) || defined(_LIBOBJC_WEAK)
 /* Objective-C.  */
diff --git a/libstdc++-v3/config/os/vxworks/os_defines.h b/libstdc++-v3/config/os/vxworks/os_defines.h
index de2522e..edb6693 100644
--- a/libstdc++-v3/config/os/vxworks/os_defines.h
+

Re: [google gcc-4_8] unify int and fp scaling in gcov-tool

[Teresa Johnson]

Looks good to me.

A couple questions:

>  static void
> -__gcov_scale_icall_topn (gcov_type *counters, unsigned n_counters, double f)
> +__gcov_icall_topn_op (gcov_type *counters, unsigned n_counters,
> +  counter_op_fn fn, void *data1, void *data2)
>  {
>unsigned i;
>
> @@ -950,41 +949,65 @@ static void
>gcov_type *value_array = &counters[i + 1];
>
>for (j = 0; j < GCOV_ICALL_TOPN_NCOUNTS - 1; j += 2)
> -value_array[1] *= f;

Was the above a bug (always updating index 1)?

> +value_array[j + 1] = fn (value_array[j + 1], data1, data2);
>  }
>  }
>
>  static void
> -__gcov_scale_dc (gcov_type *counters, unsigned n_counters, double f)
> +__gcov_dc_op (gcov_type *counters, unsigned n_counters,
> +  counter_op_fn fn, void *data1, void *data2)
>  {
>unsigned i;
>
>gcc_assert (!(n_counters % 2));
>for (i = 0; i < n_counters; i += 2)
> -counters[1] *= f;

Same question here

> +counters[i + 1] = fn (counters[i + 1], data1, data2);
>  }

Teresa

On Tue, Feb 4, 2014 at 3:54 PM, Rong Xu  wrote:
> Hi,
>
> The attached patch uses a callback function to unify the integer and
> floating-point scaling in gcov-tool. (Also fix a bug in fp scaling of
> ic and dc counters in earlier code).
>
> Tested with spec2006 profiles.
>
> OK for checking in?
>
> Thanks,
>
> -Rong



-- 
Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413

[jit] Provide a more terse C++ wrapper API.

[David Malcolm]

Committed to branch dmalcolm/jit:

Add some more methods to the C++ wrapper API to reduce the amount of
typing needed when performing specific operations, albeit it without going
all the way to using operator overloading, since the latter is often too
"magical" for some people's taste, and may make it impossible to specify
the context within which the resulting object lives.

We retain the more general wrapper APIs, since having both generic and
specialized methods seems to be useful (based on my ongoing experiments
porting GNU Octave's existing JIT compiler to libgccjit).

gcc/jit/
* libgccjit++.h (gccjit::context::new_minus): New method,
providing a way to do a specific unary op with less typing.
(gccjit::context::new_bitwise_negate): Likewise.
(gccjit::context::new_logical_negate): Likewise.

(gccjit::context::new_plus): Likewise, for binary op.
(gccjit::context::new_minus): Likewise.
(gccjit::context::new_mult): Likewise.
(gccjit::context::new_divide): Likewise.
(gccjit::context::new_modulo): Likewise.
(gccjit::context::new_bitwise_and): Likewise.
(gccjit::context::new_bitwise_xor): Likewise.
(gccjit::context::new_bitwise_or): Likewise.
(gccjit::context::new_logical_and): Likewise.
(gccjit::context::new_logical_or): Likewise.

(gccjit::context::new_eq): Likewise, for comparison.
(gccjit::context::new_ne): Likewise.
(gccjit::context::new_lt): Likewise.
(gccjit::context::new_le): Likewise.
(gccjit::context::gccjit::context::new_gt): Likewise.
(gccjit::context::gccjit::context::new_ge): Likewise.

(gccjit::context::new_call): Add a series of overloaded methods
for specific numbers of args (from 0 - 6), to avoid the need for
client code to manually build a std::vector (or requiring C++11).

gcc/testsuite/
* jit.dg/test-quadratic.cc (make_calc_discriminant): Make use of
new methods of the C++ wrapper API to shorten the example code.
(make_test_quadratic): Likewise.
---
 gcc/jit/ChangeLog.jit  |  29 +++
 gcc/jit/libgccjit++.h  | 316 +
 gcc/testsuite/ChangeLog.jit|   6 +
 gcc/testsuite/jit.dg/test-quadratic.cc |  51 ++
 4 files changed, 366 insertions(+), 36 deletions(-)

diff --git a/gcc/jit/ChangeLog.jit b/gcc/jit/ChangeLog.jit
index 8f1083a..bd209ed 100644
--- a/gcc/jit/ChangeLog.jit
+++ b/gcc/jit/ChangeLog.jit
@@ -1,5 +1,34 @@
 2014-02-10  David Malcolm  
 
+   * libgccjit++.h (gccjit::context::new_minus): New method,
+   providing a way to do a specific unary op with less typing.
+   (gccjit::context::new_bitwise_negate): Likewise.
+   (gccjit::context::new_logical_negate): Likewise.
+
+   (gccjit::context::new_plus): Likewise, for binary op.
+   (gccjit::context::new_minus): Likewise.
+   (gccjit::context::new_mult): Likewise.
+   (gccjit::context::new_divide): Likewise.
+   (gccjit::context::new_modulo): Likewise.
+   (gccjit::context::new_bitwise_and): Likewise.
+   (gccjit::context::new_bitwise_xor): Likewise.
+   (gccjit::context::new_bitwise_or): Likewise.
+   (gccjit::context::new_logical_and): Likewise.
+   (gccjit::context::new_logical_or): Likewise.
+
+   (gccjit::context::new_eq): Likewise, for comparison.
+   (gccjit::context::new_ne): Likewise.
+   (gccjit::context::new_lt): Likewise.
+   (gccjit::context::new_le): Likewise.
+   (gccjit::context::gccjit::context::new_gt): Likewise.
+   (gccjit::context::gccjit::context::new_ge): Likewise.
+
+   (gccjit::context::new_call): Add a series of overloaded methods
+   for specific numbers of args (from 0 - 6), to avoid the need for
+   client code to manually build a std::vector (or requiring C++11).
+
+2014-02-10  David Malcolm  
+
* libgccjit++.h (gccjit::context::new_struct_type): Pass std::vector
"fields" argument by reference rather than by value.
(gccjit::context::new_function): Likewise, for "params" arg.
diff --git a/gcc/jit/libgccjit++.h b/gcc/jit/libgccjit++.h
index ae55058..ff22d1e 100644
--- a/gcc/jit/libgccjit++.h
+++ b/gcc/jit/libgccjit++.h
@@ -112,24 +112,114 @@ namespace gccjit
   void *value);
 rvalue new_rvalue (const std::string &value);
 
+/* Generic unary operations...  */
 rvalue new_unary_op (enum gcc_jit_unary_op op,
 type result_type,
 rvalue a,
 location loc = location ());
 
+/* ...and shorter ways to spell the various specific kinds of
+   unary op.  */
+rvalue new_minus (type result_type,
+ rvalue a,
+ location loc = location ());
+rvalue new_bitwise_negate (type result_type,
+  rvalue a,
+  location loc = locat

Re: [C PATCH] Improve column info of initializers (PR c/60114)

[Jakub Jelinek]

On Mon, Feb 10, 2014 at 10:45:24AM -0700, Jeff Law wrote:
> >2014-02-10  Marek Polacek  
> >
> > PR c/60114
> >c/
> > * c-parser.c (c_parser_initelt): Pass input_location to
> > process_init_element.
> > (c_parser_initval): Pass loc to process_init_element.
> > * c-tree.h (process_init_element): Adjust declaration.
> > * c-typeck.c (push_init_level): Pass input_location to
> > process_init_element.
> > (pop_init_level): Likewise.
> > (set_designator): Likewise.
> > (output_init_element): Add location_t parameter.  Pass loc to
> > digest_init.
> > (output_pending_init_elements): Pass input_location to
> > output_init_element.
> > (process_init_element): Add location_t parameter.  Pass loc to
> > output_init_element.
> >testsuite/
> > * gcc.dg/pr60114.c: New test.
> I'd think this probably should queue for the next stage1.  We're
> probably just ~6wks away at this point anyway.

Yeah, agreed, please queue it up for 5.0.

Jakub

Re: [PING] [PATCH] _Cilk_for for C and C++

[Jakub Jelinek]

On Fri, Feb 07, 2014 at 10:14:21PM +, Iyer, Balaji V wrote:
>   Attached, please find a fixed patch. Along with it, I have also
> added 2 changelog files for C and C++ respectively.

Have you even looked at the second testcase I've posted?
gimplification ICEs on it with your latest patch, because firstprivate
clause is added for the same variable multiple times, and it seems parallel
still isn't around _Cilk_for.

Jakub

Re: CALL_INSN_FUNCTION_USAGE fix, PR52773

[Andreas Schwab]

Bernd Schmidt  writes:

> This is bug that triggers on m68k. The loop unroller creates a MULT
> expression and tries to force it into a register, which causes a libcall
> to be generated. Since args are pushed we create a
>   (use (mem (plus virtual_outgoing_args scratch)))
> in CALL_INSN_FUNCTION_USAGE. Since we're past vregs, the
> virtual_outgoing_args rtx survives to reload, which blows up.
>
> Fixed by just using stack_pointer_rtx, since we use a scratch anyway
> rather than a known offset. I also noticed that we actually add two of
> these USEs, so I've fixed that as well.
>
> Bootstrapped and tested on x86_64-linux, ok?

Any news on this?

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [C PATCH] Improve column info of initializers (PR c/60114)

[Jeff Law]

On 02/10/14 06:44, Marek Polacek wrote:

This patch improves location information in a bunch of various
initializers; see the testcase.  Main issue was that digest_init
was getting only input_location.

Regtested/bootstrapped on x86_64-linux, ok for trunk at this stage
or should I queue it for 5.0?

2014-02-10  Marek Polacek  

PR c/60114
c/
* c-parser.c (c_parser_initelt): Pass input_location to
process_init_element.
(c_parser_initval): Pass loc to process_init_element.
* c-tree.h (process_init_element): Adjust declaration.
* c-typeck.c (push_init_level): Pass input_location to
process_init_element.
(pop_init_level): Likewise.
(set_designator): Likewise.
(output_init_element): Add location_t parameter.  Pass loc to
digest_init.
(output_pending_init_elements): Pass input_location to
output_init_element.
(process_init_element): Add location_t parameter.  Pass loc to
output_init_element.
testsuite/
* gcc.dg/pr60114.c: New test.
I'd think this probably should queue for the next stage1.  We're 
probably just ~6wks away at this point anyway.



jeff

Re: {GRAPHITE] Replacement of isl_int by isl_val

[Albert Cohen]

Le 10/02/2014 16:48, Albert Cohen a écrit :
> Le 10/02/2014 10:12, Richard Biener a écrit :
>> Btw, Mircea - do you have a copyright assignment on file with the FSF
>> covering work on GCC?
> 
> Yes, Mircea is covered by an INRIA-wide copyright assignment, signed on
> May 15, 2007 by T. Brown.

After double-checking, I have to say that the assignment is *not*
INRIA-wide, but it covers the research team Mircea is working in.

Albert

Re: [PATCH] fix for PR 59691

[Jeff Law]

On 02/06/14 15:21, Iyer, Balaji V wrote:

Hello Everyone,
Attached, please find a patch that will fix the issue in PR 59691. The 
main issue was that the Cilk library (libcilkrts) was not checking if the 
target has SSE support before emitting SSE instruction. This patch should fix 
that.

Here is the ChangeLog entries:
libcilkrts/ChangeLog
2014-02-06  Balaji V. Iyer  

 * runtime/config/x86/os-unix-sysdep.c (__builtin_cpu_supports): New
 function.
 (restore_x86_fp_state): Added a check if the cpu supports the
 instruction before emitting it.
 (sysdep_save_fp_ctrl_state): Likewise.



Is this Ok to install?

Yes, this is fine.

jeff

Re: [PATCH] Fix for PR60080

[Jeff Law]

On 02/07/14 04:00, Bernd Edlinger wrote:

Hi,

there has been a ICE on solaris 9 and 10 when dumping ASM_INPUT objects
without valid source loation at print-rtl.c.

print_rtx did not check for this, and tried to print NULL with printf format %s.
This happens to be handled by glibc's printf to print "(null)" but not on 
solaris.

Attached is my proposed patch for this: Firstly attaching the source location to
ASM_INPUT objects, that should not hurt, and secondly check for
UNKNOWN_LOCATION in print-rtl.c for ASM_INPUT and ASM_OPERANDS.

Boot-Strapped and Regression-tested on X86_64-linux-gnu.


Thanks
Bernd.  


changelog-pr60080.txt


2014-02-06  Bernd Edlinger

PR middle-end/60080
* cfgexpand.c (expand_asm_operands): Attach source location to
ASM_INPUT rtx objects.
* print-rtl.c (print_rtx): Check for UNKNOWN_LOCATION.

This is fine.  Please install.

Thanks,
Jeff

Re: Unreviewed testsuite patch

[Jeff Law]

On 02/10/14 09:28, Rainer Orth wrote:

The following patch has remained unreviewed for a week:

[testsuite] Don't xfail gcc.dg/binop-xor1.c
 http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00147.html

OK.
Jeff

Re: [RFA] [middle-end/54041] Convert modes as needed from expand_expr

[Jeff Law]

On 02/07/14 02:17, Richard Biener wrote:

+2014-02-05  Jeff Law  
+
+   PR middle-end/54041
+   * expr.c (expand_expr_addr_1): Handle expand_expr returning an
+   object with an undesirable mode.
+
  2014-02-05  Bill Schmidt  

 * config/rs6000/rs6000.c (altivec_expand_vec_perm_const): Change
diff --git a/gcc/expr.c b/gcc/expr.c
index 878a51b..9609c45 100644
--- a/gcc/expr.c
+++ b/gcc/expr.c
@@ -7708,6 +7708,11 @@ expand_expr_addr_expr_1 (tree exp, rtx target, enum
machine_mode tmode,
  modifier == EXPAND_INITIALIZER
   ? EXPAND_INITIALIZER : EXPAND_NORMAL);

+  /* expand_expr is allowed to return an object in a mode other
+than TMODE.  If it did, we need to convert.  */
+  if (tmode != GET_MODE (tmp))
+   tmp = convert_modes (tmode, GET_MODE (tmp),
+tmp, TYPE_UNSIGNED (TREE_TYPE (offset)));


What about CONSTANT_P tmp?  Don't you need to use
TYPE_MODE (TREE_TYPE (offset)) in that case?


As I mentioned last week, we want to pass VOIDmode objects (constants) 
down to convert_memory_address_addr_space unchange.  c_m_a_a_s will 
handle those correctly.


This patch fixes that oversight and the function name in the ChangeLog 
entry.


I've verified this version still fixes the original bug report and 
included it in an x86_64-unknown-linux-gnu bootstrap & test for sanity's 
sake.


OK for the trunk?

Thanks,
Jeff


diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 2dbab72..eca3e2f 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,9 @@
+2014-02-05  Jeff Law  
+
+   PR middle-end/54041
+   * expr.c (expand_expr_addr_expr_1): Handle expand_expr returning an
+   object with an undesirable mode.
+
 2014-02-05  Bill Schmidt  
 
* config/rs6000/rs6000.c (altivec_expand_vec_perm_const): Change
diff --git a/gcc/expr.c b/gcc/expr.c
index 878a51b..42a451d 100644
--- a/gcc/expr.c
+++ b/gcc/expr.c
@@ -7708,6 +7708,11 @@ expand_expr_addr_expr_1 (tree exp, rtx target, enum 
machine_mode tmode,
 modifier == EXPAND_INITIALIZER
  ? EXPAND_INITIALIZER : EXPAND_NORMAL);
 
+  /* expand_expr is allowed to return an object in a mode other
+than TMODE.  If it did, we need to convert.  */
+  if (GET_MODE (tmp) != VOIDmode && tmode != GET_MODE (tmp))
+   tmp = convert_modes (tmode, GET_MODE (tmp),
+tmp, TYPE_UNSIGNED (TREE_TYPE (offset)));
   result = convert_memory_address_addr_space (tmode, result, as);
   tmp = convert_memory_address_addr_space (tmode, tmp, as);
 
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index c81a00d..283912d 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2014-02-05  Jeff Law  
+
+   PR middle-end/54041
+   * gcc.target/m68k/pr54041.c: New test.
+
 2014-02-05  Bill Schmidt  
 
* gcc.dg/vmx/sum2s.c: New.
diff --git a/gcc/testsuite/gcc.target/m68k/pr54041.c 
b/gcc/testsuite/gcc.target/m68k/pr54041.c
new file mode 100644
index 000..645cb6d
--- /dev/null
+++ b/gcc/testsuite/gcc.target/m68k/pr54041.c
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-options "-O -mshort" } */
+
+extern int r[];
+
+int *fn(int i)
+{
+   return &r[i];
+}
+

Re: [PATCH] Set correct probability for ORDER/UNORDER jumps

[Dehao Chen]

ping...

Dehao

On Fri, Jan 24, 2014 at 1:54 PM, Dehao Chen  wrote:
> Thanks, test updated:
>
> Index: gcc/testsuite/gcc.dg/predict-8.c
> ===
> --- gcc/testsuite/gcc.dg/predict-8.c (revision 0)
> +++ gcc/testsuite/gcc.dg/predict-8.c (revision 0)
> @@ -0,0 +1,12 @@
> +/* { dg-do compile { target { i?86-*-* x86_64-*-* } } } */
> +/* { dg-options "-O2 -fdump-rtl-expand" } */
> +
> +int foo(float a, float b) {
> +  if (a == b)
> +return 1;
> +  else
> +return 2;
> +}
> +
> +/* { dg-final { scan-rtl-dump-times "REG_BR_PROB 100" 1 "expand"} } */
> +/* { dg-final { cleanup-rtl-dump "expand" } } */
>
> On Fri, Jan 24, 2014 at 11:38 AM, H.J. Lu  wrote:
>> On Fri, Jan 24, 2014 at 10:57 AM, Jakub Jelinek  wrote:
>>> On Fri, Jan 24, 2014 at 10:20:53AM -0800, Dehao Chen wrote:
 --- gcc/testsuite/gcc.dg/predict-8.c (revision 0)
 +++ gcc/testsuite/gcc.dg/predict-8.c (revision 0)
 @@ -0,0 +1,12 @@
 +/* { dg-do compile { target { x86_64-*-* } } } */
>>>
>>> If you want it for x86_64 64-bit, then
>>> /* { dg-do compile { target { { i?86-*-* x86_64-*-* } && lp64 } } } */
>>>
>>
>> It should be "! { ia32 }" instead of "lp64" unless it doesn't work
>> for x32.
>>
>> --
>> H.J.

Unreviewed testsuite patch

[Rainer Orth]

The following patch has remained unreviewed for a week:

[testsuite] Don't xfail gcc.dg/binop-xor1.c
http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00147.html

Rainer

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

Re: [PATCH, fortran/52879] RANDOM_SEED revisited

[Steve Kargl]

On Mon, Feb 10, 2014 at 05:23:39PM +0200, Janne Blomqvist wrote:
> On Sun, Feb 9, 2014 at 2:40 AM, Steve Kargl
>  wrote:
> > All,
> >
> > Here is a potentially contentious patch for PR fortran/52879.
> >
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52879
> >
> > As demonstrated in that PR, it is possible to provide RANDOM_SEED
> > with sets of seeds that result in a very poor sequences of PRN.
> > Gfortran's RANDOM_NUMBER uses 3 independent KISS PRNG to generate
> > the bits of the significands of the real PRN.  Each KISS PRNG
> > requires 4 seeds.  This patch removes the need for a user to
> > specify 12 seeds.  It uses a Lehmer linear congruent generator
> > to generate the 12 KISS seeds.  This LCG requires a single seed.
> > I have selected to have seed(1)=0 correspond to the current
> > default set of KISS seeds.  Internally, the LCG declares the
> > seed as a GFC_UINTEGER_8 (ie., uint64_t) type, so for gfortran's
> > default integer kind one has 2**31-1 possible seeds and if one
> > use -fdefault-integer-8 then one has 2**32 possible seeds.
> 
> I like this approach, as it would make the seeding a bit more
> fool-proof and easier to use. Per se, loss of the ability to retrieve
> or update parts of the internal state of the RNG seems not terribly
> relevant, after all users who might be interested in that are most
> likely not going to be satisfied with the black box RNG provided by
> the language anyway.
> 
> That being said, I wonder whether this conforms to the standard. From N1830:
> 
> "The pseudorandom number generator used by RANDOM NUMBER maintains a
> seed that is updated during the execution of RANDOM NUMBER and that
> may be specified or returned by RANDOM SEED."
> 
> and
> 
> "
> For example, after execution of the statements
> 
>  CALL RANDOM_SEED (PUT=SEED1)
>  CALL RANDOM_SEED (GET=SEED2)
>  CALL RANDOM_NUMBER (X1)
>  CALL RANDOM_SEED (PUT=SEED2)
>  CALL RANDOM_NUMBER (X2)
> 
> X2 equals X1.
> "
> 
> That would imply that GET= and PUT= save/restore the complete internal
> state of the PRNG, which seems incompatible with using the simple LCG
> to generate the seed (if I understood this correctly, I agree with
> Nick that the interface is badly designed, but what can you do..).

I suppose at one time I knew about the above requirement.  The
simple approach I proposed won't work as is.  A possible work-around
(and it is ugly) would be to keep an internal count of the number
of times that a random number is drawn.  Call this count CNT.  Then,
on reseeding, random_seed would burn CNT draws and reset CNT to zero.
In thinking about it, we could make seed(1)= and seed(2)=CNT.
This would restrict CNT to 2**31-1 before rolling over.  If CNT is
internal to random_seed(), it can be a uint64_t giving 2**64 before
rolling over.  This certainly has some performance impact on any code
that calls random_seed numerous times.

> Or maybe it would be possible to get around this requirement by
> requiring the 12 seeds, but then calculate some kind of entropy value
> of them, and if the entropy is too low (say, all values are the same,
> or only the first value is non-zero) then use the Lehmer LCG,
> otherwise set the state directly? Sounds brittle, though..

Interesting idea.  I can't remember.  Is it possible to issue
a runtime warning from within libgfortran?  Is so, we could do

   seed2 = [1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
   call random_seed(put=seed2)

Runtime Warning: poor quality seeds detected in random_seed().
Seeds reset to PUT=[].

I'll think about a possible algorithm.

-- 
Steve

[jit] Pass std::vector by reference within the C++ wrapper API

[David Malcolm]

Committed to branch dmalcolm/jit:

gcc/jit/
* libgccjit++.h (gccjit::context::new_struct_type): Pass std::vector
"fields" argument by reference rather than by value.
(gccjit::context::new_function): Likewise, for "params" arg.
(gccjit::context::new_call): Likewise, for "args" arg.

gcc/testsuite/
* jit.dg/test-quadratic.cc (make_test_quadratic): Update for
change to gccjit::context::new_call to pass args by reference
rather than by value.
---
 gcc/jit/ChangeLog.jit  |  7 +++
 gcc/jit/libgccjit++.h  | 12 ++--
 gcc/testsuite/ChangeLog.jit|  6 ++
 gcc/testsuite/jit.dg/test-quadratic.cc |  3 ++-
 4 files changed, 21 insertions(+), 7 deletions(-)

diff --git a/gcc/jit/ChangeLog.jit b/gcc/jit/ChangeLog.jit
index e1e908f..8f1083a 100644
--- a/gcc/jit/ChangeLog.jit
+++ b/gcc/jit/ChangeLog.jit
@@ -1,5 +1,12 @@
 2014-02-10  David Malcolm  
 
+   * libgccjit++.h (gccjit::context::new_struct_type): Pass std::vector
+   "fields" argument by reference rather than by value.
+   (gccjit::context::new_function): Likewise, for "params" arg.
+   (gccjit::context::new_call): Likewise, for "args" arg.
+
+2014-02-10  David Malcolm  
+
* libgccjit++.h (gccjit::context::new_location): Update filename
arg from a const char * to a const std::string &.
(gccjit::context::new_field): Likewise for "name" arg.
diff --git a/gcc/jit/libgccjit++.h b/gcc/jit/libgccjit++.h
index 1579979..ae55058 100644
--- a/gcc/jit/libgccjit++.h
+++ b/gcc/jit/libgccjit++.h
@@ -88,7 +88,7 @@ namespace gccjit
 location loc = location ());
 
 type new_struct_type (const std::string &name,
- std::vector fields,
+ std::vector &fields,
  location loc = location ());
 
 param new_param (type type_,
@@ -98,7 +98,7 @@ namespace gccjit
 function new_function (enum gcc_jit_function_kind kind,
   type return_type,
   const std::string &name,
-  std::vector params,
+  std::vector ¶ms,
   int is_variadic,
   location loc = location ());
 
@@ -127,7 +127,7 @@ namespace gccjit
   location loc = location ());
 
 rvalue new_call (function func,
-std::vector args,
+std::vector &args,
 location loc = location ());
 
 lvalue new_array_access (rvalue ptr,
@@ -343,7 +343,7 @@ context::new_field (type type_, const std::string &name, 
location loc)
 
 inline type
 context::new_struct_type (const std::string &name,
- std::vector fields,
+ std::vector &fields,
  location loc)
 {
   /* Treat std::vector as an array, relying on it not being resized: */
@@ -376,7 +376,7 @@ inline function
 context::new_function (enum gcc_jit_function_kind kind,
   type return_type,
   const std::string &name,
-  std::vector params,
+  std::vector ¶ms,
   int is_variadic,
   location loc)
 {
@@ -490,7 +490,7 @@ context::new_comparison (enum gcc_jit_comparison op,
 
 inline rvalue
 context::new_call (function func,
-  std::vector args,
+  std::vector &args,
   location loc)
 {
   /* Treat std::vector as an array, relying on it not being resized: */
diff --git a/gcc/testsuite/ChangeLog.jit b/gcc/testsuite/ChangeLog.jit
index 3db5cf5..79d2096 100644
--- a/gcc/testsuite/ChangeLog.jit
+++ b/gcc/testsuite/ChangeLog.jit
@@ -1,3 +1,9 @@
+2014-02-10  David Malcolm  
+
+   * jit.dg/test-quadratic.cc (make_test_quadratic): Update for
+   change to gccjit::context::new_call to pass args by reference
+   rather than by value.
+
 2014-02-03  David Malcolm  
 
* jit.dg/harness.h (check_string_value): Add a forward declaration,
diff --git a/gcc/testsuite/jit.dg/test-quadratic.cc 
b/gcc/testsuite/jit.dg/test-quadratic.cc
index 52ae92e..75725c0 100644
--- a/gcc/testsuite/jit.dg/test-quadratic.cc
+++ b/gcc/testsuite/jit.dg/test-quadratic.cc
@@ -247,11 +247,12 @@ make_test_quadratic (quadratic_test &testcase)
   /* double s = sqrt (q.discriminant); */
   gccjit::lvalue s = test_quadratic.new_local (testcase.numeric_type, "s");
   gccjit::rvalue discriminant_of_q = q.access_field (testcase.discriminant);
+  std::vector args_to_sqrt_call (1, discriminant_of_q);
   test_quadratic.add_assignment (
 s,
 testcase.ctxt.new_call (
   testcase.sqrt,
-  std::vector (1, discriminant_of_q)));
+  args_to_sqrt_call));
 
   gccjit::rvalue minus_b =
 testcase.ctxt.new_unary_op (
-- 
1.7.11.7

Re: [testsuite, i386] Compile g++.dg/ext/vector26.C with -mmmx

[Uros Bizjak]

On Mon, Feb 10, 2014 at 5:14 PM, Rainer Orth
 wrote:
> On both Solaris 9/x86 and 32-bit Linux/x86, g++.dg/ext/vector26.C FAILs
> like this:
>
> FAIL: g++.dg/ext/vector26.C -std=c++11 (test for excess errors)
> Excess errors:
> /vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/ext/vector26.C:6:13: 
> warning: M
> MX vector argument without MMX enabled changes the ABI [enabled by default]
>
> Like vector2.C, this can be avoided by compiling with -mmmx for 32-bit
> x86.  The following patch does just that.
>
> Tested with the appropriate runtest invocations on i386-pc-solaris2.9,
> i386-pc-solaris2.10, i686-unknown-linux-gnu, and
> x86_64-unknown-linux-gnu.  Ok for mainline?
>
> Rainer
>
>
> 2014-02-10  Rainer Orth  
>
> * g++.dg/ext/vector26.C: Use -mmmx for 32-bit x86.

OK.

Thanks,
Uros.

[testsuite, i386] Compile g++.dg/ext/vector26.C with -mmmx

[Rainer Orth]

On both Solaris 9/x86 and 32-bit Linux/x86, g++.dg/ext/vector26.C FAILs
like this:

FAIL: g++.dg/ext/vector26.C -std=c++11 (test for excess errors)
Excess errors:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/ext/vector26.C:6:13: warning: M
MX vector argument without MMX enabled changes the ABI [enabled by default]

Like vector2.C, this can be avoided by compiling with -mmmx for 32-bit
x86.  The following patch does just that.

Tested with the appropriate runtest invocations on i386-pc-solaris2.9,
i386-pc-solaris2.10, i686-unknown-linux-gnu, and
x86_64-unknown-linux-gnu.  Ok for mainline?

Rainer


2014-02-10  Rainer Orth  

* g++.dg/ext/vector26.C: Use -mmmx for 32-bit x86.


# HG changeset patch
# Parent 19cc283c20f548cc9da82a7acbcba6936ee53ef7
Compile g++.dg/ext/vector26.C with -mmmx

diff --git a/gcc/testsuite/g++.dg/ext/vector26.C b/gcc/testsuite/g++.dg/ext/vector26.C
--- a/gcc/testsuite/g++.dg/ext/vector26.C
+++ b/gcc/testsuite/g++.dg/ext/vector26.C
@@ -1,6 +1,7 @@
 // PR c++/59633
 // In C++98, the definition of bar is an error.  In C++11, bar implicitly
 // gets internal linkage.
+// { dg-options "-mmmx" { target { { i?86-*-* x86_64-*-* } && ilp32 } } } */
 
 typedef enum { e } T __attribute__((vector_size(8)));
 static void foo(T t) {}

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

Re: [v3] Don't xfail 22_locale/num_put/put/char/14220.cc etc. on Solaris 9/x86

[Paolo Carlini]

Hi,

On 02/10/2014 04:59 PM, Rainer Orth wrote:

Two libstdc++ testcases have been XPASSing on Solaris 9/x86 since
ca. 20130522:

XPASS: 22_locale/num_put/put/char/14220.cc execution test
XPASS: 22_locale/num_put/put/wchar_t/14220.cc execution test

Therefore I'd like to remove the xfails since the issue documented there
doesn't seem to trigger anymore.

Bootstrapped without regressions on i386-pc-solaris2.{9, 10, 11}.  Ok
for mainline?

Yes, thanks.

Paolo.

[jit] Use std::string rather than const char * in C++ wrapper API.

[David Malcolm]

Committed to branch dmalcolm/jit:

gcc/jit/
* libgccjit++.h (gccjit::context::new_location): Update filename
arg from a const char * to a const std::string &.
(gccjit::context::new_field): Likewise for "name" arg.
(gccjit::context::new_struct_type): Likewise.
(gccjit::context::new_param): Likewise.
(gccjit::context::new_function): Likewise.
(gccjit::function::new_local): Likewise.
(gccjit::context::new_rvalue): Likewise for "value" arg.
(gccjit::function::add_comment): Likewise for "text" arg.
(gccjit::function::new_forward_label): Likewise for "name" arg; add
variant taking no args for anonymous labels.
(gccjit::function::add_label): Likewise.
---
 gcc/jit/ChangeLog.jit | 15 ++
 gcc/jit/libgccjit++.h | 77 +++
 2 files changed, 62 insertions(+), 30 deletions(-)

diff --git a/gcc/jit/ChangeLog.jit b/gcc/jit/ChangeLog.jit
index 714bee7..e1e908f 100644
--- a/gcc/jit/ChangeLog.jit
+++ b/gcc/jit/ChangeLog.jit
@@ -1,5 +1,20 @@
 2014-02-10  David Malcolm  
 
+   * libgccjit++.h (gccjit::context::new_location): Update filename
+   arg from a const char * to a const std::string &.
+   (gccjit::context::new_field): Likewise for "name" arg.
+   (gccjit::context::new_struct_type): Likewise.
+   (gccjit::context::new_param): Likewise.
+   (gccjit::context::new_function): Likewise.
+   (gccjit::function::new_local): Likewise.
+   (gccjit::context::new_rvalue): Likewise for "value" arg.
+   (gccjit::function::add_comment): Likewise for "text" arg.
+   (gccjit::function::new_forward_label): Likewise for "name" arg; add
+   variant taking no args for anonymous labels.
+   (gccjit::function::add_label): Likewise.
+
+2014-02-10  David Malcolm  
+
* libgccjit++.h (gccjit::object, gccjit::location): Move
these declarations to before that of gccjit::context so that
the various methods of context taking a location can have a
diff --git a/gcc/jit/libgccjit++.h b/gcc/jit/libgccjit++.h
index b57dae2..1579979 100644
--- a/gcc/jit/libgccjit++.h
+++ b/gcc/jit/libgccjit++.h
@@ -75,7 +75,7 @@ namespace gccjit
  int value);
 
 location
-new_location (const char *filename,
+new_location (const std::string &filename,
  int line,
  int column);
 
@@ -84,20 +84,20 @@ namespace gccjit
 type new_array_type (type element_type, int num_elements,
 location loc = location ());
 
-field new_field (type type_, const char *name,
+field new_field (type type_, const std::string &name,
 location loc = location ());
 
-type new_struct_type (const char *name,
+type new_struct_type (const std::string &name,
  std::vector fields,
  location loc = location ());
 
 param new_param (type type_,
-const char *name,
+const std::string &name,
 location loc = location ());
 
 function new_function (enum gcc_jit_function_kind kind,
   type return_type,
-  const char *name,
+  const std::string &name,
   std::vector params,
   int is_variadic,
   location loc = location ());
@@ -110,7 +110,7 @@ namespace gccjit
   double value);
 rvalue new_rvalue (type pointer_type,
   void *value);
-rvalue new_rvalue (const char *value);
+rvalue new_rvalue (const std::string &value);
 
 rvalue new_unary_op (enum gcc_jit_unary_op op,
 type result_type,
@@ -167,10 +167,11 @@ namespace gccjit
 
 gcc_jit_function *get_inner_function ();
 
-label new_forward_label (const char *name);
+label new_forward_label ();
+label new_forward_label (const std::string &name);
 
 lvalue new_local (type type_,
- const char *name,
+ const std::string &name,
  location loc = location ());
 
 void add_eval (rvalue rvalue,
@@ -185,7 +186,7 @@ namespace gccjit
rvalue rvalue,
location loc = location ());
 
-void add_comment (const char *text,
+void add_comment (const std::string &text,
  location loc = location ());
 
 void add_conditional (rvalue boolval,
@@ -193,8 +194,9 @@ namespace gccjit
  label on_false,
  location loc = location ());
 
-label add_label (const char *name,
+label add_label (const std::string &name,
 location loc = location ());
+label add_label (location loc = location ());
 
 void place_forward_label (label lab,
  location 

[v3] Don't xfail 22_locale/num_put/put/char/14220.cc etc. on Solaris 9/x86

[Rainer Orth]

Two libstdc++ testcases have been XPASSing on Solaris 9/x86 since
ca. 20130522:

XPASS: 22_locale/num_put/put/char/14220.cc execution test
XPASS: 22_locale/num_put/put/wchar_t/14220.cc execution test

Therefore I'd like to remove the xfails since the issue documented there
doesn't seem to trigger anymore.

Bootstrapped without regressions on i386-pc-solaris2.{9, 10, 11}.  Ok
for mainline?

Rainer


2014-02-05  Rainer Orth  

* testsuite/22_locale/num_put/put/char/14220.cc: Don't xfail
execution on i?86-*-solaris2.9, remove comment.
* testsuite/22_locale/num_put/put/wchar_t/14220.cc: Likewise.

# HG changeset patch
# Parent 0f6d9b9bde5e7eee20486c180ceec28d5043bec7
Don't xfail 22_locale/num_put/put/char/14220.cc etc. on Solaris 9/x86

diff --git a/libstdc++-v3/testsuite/22_locale/num_put/put/char/14220.cc b/libstdc++-v3/testsuite/22_locale/num_put/put/char/14220.cc
--- a/libstdc++-v3/testsuite/22_locale/num_put/put/char/14220.cc
+++ b/libstdc++-v3/testsuite/22_locale/num_put/put/char/14220.cc
@@ -19,12 +19,6 @@
 
 // 22.2.2.2.1  num_put members
 
-// On Solaris 9/x86 and 32-bit Solaris 10/x86 before update 10, this test
-// crashes in libc.  Inside libstdc++, we call sprintf like so:
-//   sprintf (buffer, "%.*f", 1000, 1.0)
-// which crashes.
-// { dg-xfail-run-if "" i?86-*-solaris2.9 }
-
 #include 
 #include 
 #include 
diff --git a/libstdc++-v3/testsuite/22_locale/num_put/put/wchar_t/14220.cc b/libstdc++-v3/testsuite/22_locale/num_put/put/wchar_t/14220.cc
--- a/libstdc++-v3/testsuite/22_locale/num_put/put/wchar_t/14220.cc
+++ b/libstdc++-v3/testsuite/22_locale/num_put/put/wchar_t/14220.cc
@@ -23,12 +23,6 @@
 #include 
 #include 
 
-// On Solaris 9 and 32-bit Solaris 10/x86 before update 10, this test crashes
-// in libc.  Inside libstdc++, we call sprintf like so:
-//   sprintf (buffer, "%.*f", 1000, 1.0)
-// which crashes.
-// { dg-do run { xfail { i?86-*-solaris2.9 } } } 
-
 // libstdc++/14220
 void test01()
 {

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

Re: {GRAPHITE] Replacement of isl_int by isl_val

[Albert Cohen]

Le 10/02/2014 10:12, Richard Biener a écrit :
> Btw, Mircea - do you have a copyright assignment on file with the FSF
> covering work on GCC?

Yes, Mircea is covered by an INRIA-wide copyright assignment, signed on
May 15, 2007 by T. Brown.

Thanks,
Albert

[jit] Use default arguments to eliminate half of the methods in the C++ wrapper API.

[David Malcolm]

Committed to branch dmalcolm/jit:

Consolidate the with/without source location pairs of methods in the
C++ wrapper API into individual methods.  This should all compile down to
just the equivalent of supplying a NULL (gcc_jit_location *) where the
client code doesn't provide a gccjit::location.

gcc/jit/
* libgccjit++.h (gccjit::object, gccjit::location): Move
these declarations to before that of gccjit::context so that
the various methods of context taking a location can have a
default location value.
(gccjit::context::new_array_type): Consolidate two methods,
one accepting a gccjit::location, the other without, by
providing a default argument (which thus has to be moved to the
end of the argument list).
(gccjit::context::new_field): Likewise.
(gccjit::context::new_struct_type): Likewise.
(gccjit::context::new_param): Likewise.
(gccjit::context::new_function): Likewise.
(gccjit::context::new_unary_op): Likewise.
(gccjit::context::new_binary_op): Likewise.
(gccjit::context::new_comparison): Likewise.
(gccjit::context::new_call): Likewise.
(gccjit::context::new_array_access): Likewise.
(gccjit::function::new_local): Likewise.
(gccjit::function::add_eval): Likewise.
(gccjit::function::add_assignment): Likewise.
(gccjit::function::add_assignment_op): Likewise.
(gccjit::function::add_comment): Likewise.
(gccjit::function::add_conditional): Likewise.
(gccjit::function::add_label): Likewise.
(gccjit::function::place_forward_label): Likewise.
(gccjit::function::add_jump): Likewise.
(gccjit::function::add_return): Likewise.
(gccjit::rvalue::access_field): Likewise.
(gccjit::rvalue::dereference_field): Likewise.
(gccjit::rvalue::dereference): Likewise.
(gccjit::lvalue::access_field): Likewise.
(gccjit::lvalue::get_address): Likewise.
---
 gcc/jit/ChangeLog.jit |  35 
 gcc/jit/libgccjit++.h | 460 +-
 2 files changed, 157 insertions(+), 338 deletions(-)

diff --git a/gcc/jit/ChangeLog.jit b/gcc/jit/ChangeLog.jit
index 253f239..714bee7 100644
--- a/gcc/jit/ChangeLog.jit
+++ b/gcc/jit/ChangeLog.jit
@@ -1,5 +1,40 @@
 2014-02-10  David Malcolm  
 
+   * libgccjit++.h (gccjit::object, gccjit::location): Move
+   these declarations to before that of gccjit::context so that
+   the various methods of context taking a location can have a
+   default location value.
+   (gccjit::context::new_array_type): Consolidate two methods,
+   one accepting a gccjit::location, the other without, by
+   providing a default argument (which thus has to be moved to the
+   end of the argument list).
+   (gccjit::context::new_field): Likewise.
+   (gccjit::context::new_struct_type): Likewise.
+   (gccjit::context::new_param): Likewise.
+   (gccjit::context::new_function): Likewise.
+   (gccjit::context::new_unary_op): Likewise.
+   (gccjit::context::new_binary_op): Likewise.
+   (gccjit::context::new_comparison): Likewise.
+   (gccjit::context::new_call): Likewise.
+   (gccjit::context::new_array_access): Likewise.
+   (gccjit::function::new_local): Likewise.
+   (gccjit::function::add_eval): Likewise.
+   (gccjit::function::add_assignment): Likewise.
+   (gccjit::function::add_assignment_op): Likewise.
+   (gccjit::function::add_comment): Likewise.
+   (gccjit::function::add_conditional): Likewise.
+   (gccjit::function::add_label): Likewise.
+   (gccjit::function::place_forward_label): Likewise.
+   (gccjit::function::add_jump): Likewise.
+   (gccjit::function::add_return): Likewise.
+   (gccjit::rvalue::access_field): Likewise.
+   (gccjit::rvalue::dereference_field): Likewise.
+   (gccjit::rvalue::dereference): Likewise.
+   (gccjit::lvalue::access_field): Likewise.
+   (gccjit::lvalue::get_address): Likewise.
+
+2014-02-10  David Malcolm  
+
* TODO.rst: Update.
 
 2014-02-06  David Malcolm  
diff --git a/gcc/jit/libgccjit++.h b/gcc/jit/libgccjit++.h
index b7f5d4b..b57dae2 100644
--- a/gcc/jit/libgccjit++.h
+++ b/gcc/jit/libgccjit++.h
@@ -24,6 +24,37 @@ namespace gccjit
   class rvalue;
   class lvalue;
 
+  class object
+  {
+  public:
+std::string get_debug_string () const;
+
+  protected:
+object ();
+object (gcc_jit_object *obj);
+
+gcc_jit_object *get_inner_object ();
+
+  private:
+gcc_jit_object *m_inner_obj;
+  };
+
+  inline std::ostream& operator << (std::ostream& stream, const object &obj);
+
+  /* Some client code will want to supply source code locations, others
+ won't.  To avoid doubling the number of entrypoints, everything
+ accepting a location also has a default argument.  To do this, the
+ other classes need to see that "location" has a default const

Re: [PATCH, fortran/52879] RANDOM_SEED revisited

[Janne Blomqvist]

On Sun, Feb 9, 2014 at 2:40 AM, Steve Kargl
 wrote:
> All,
>
> Here is a potentially contentious patch for PR fortran/52879.
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52879
>
> As demonstrated in that PR, it is possible to provide RANDOM_SEED
> with sets of seeds that result in a very poor sequences of PRN.
> Gfortran's RANDOM_NUMBER uses 3 independent KISS PRNG to generate
> the bits of the significands of the real PRN.  Each KISS PRNG
> requires 4 seeds.  This patch removes the need for a user to
> specify 12 seeds.  It uses a Lehmer linear congruent generator
> to generate the 12 KISS seeds.  This LCG requires a single seed.
> I have selected to have seed(1)=0 correspond to the current
> default set of KISS seeds.  Internally, the LCG declares the
> seed as a GFC_UINTEGER_8 (ie., uint64_t) type, so for gfortran's
> default integer kind one has 2**31-1 possible seeds and if one
> use -fdefault-integer-8 then one has 2**32 possible seeds.

I like this approach, as it would make the seeding a bit more
fool-proof and easier to use. Per se, loss of the ability to retrieve
or update parts of the internal state of the RNG seems not terribly
relevant, after all users who might be interested in that are most
likely not going to be satisfied with the black box RNG provided by
the language anyway.

That being said, I wonder whether this conforms to the standard. From N1830:

"The pseudorandom number generator used by RANDOM NUMBER maintains a
seed that is updated during the execution of RANDOM NUMBER and that
may be specified or returned by RANDOM SEED."

and

"
For example, after execution of the statements

 CALL RANDOM_SEED (PUT=SEED1)
 CALL RANDOM_SEED (GET=SEED2)
 CALL RANDOM_NUMBER (X1)
 CALL RANDOM_SEED (PUT=SEED2)
 CALL RANDOM_NUMBER (X2)

X2 equals X1.
"

That would imply that GET= and PUT= save/restore the complete internal
state of the PRNG, which seems incompatible with using the simple LCG
to generate the seed (if I understood this correctly, I agree with
Nick that the interface is badly designed, but what can you do..).

Or maybe it would be possible to get around this requirement by
requiring the 12 seeds, but then calculate some kind of entropy value
of them, and if the entropy is too low (say, all values are the same,
or only the first value is non-zero) then use the Lehmer LCG,
otherwise set the state directly? Sounds brittle, though..

> It is possible to extend the patch to allow a skip count such that
> for example seed(2)=10 would use every tenth value in the LCG
> sequence. I haven't pursued this as it appears to be an unneeded
> complication.

Yes, this seems unnecessary.


-- 
Janne Blomqvist

[jit] Update TODO.rst

[David Malcolm]

Committed to branch dmalcolm/jit:

gcc/jit/
* TODO.rst: Update.
---
 gcc/jit/ChangeLog.jit |  4 +++
 gcc/jit/TODO.rst  | 69 +--
 2 files changed, 55 insertions(+), 18 deletions(-)

diff --git a/gcc/jit/ChangeLog.jit b/gcc/jit/ChangeLog.jit
index 6950b13..253f239 100644
--- a/gcc/jit/ChangeLog.jit
+++ b/gcc/jit/ChangeLog.jit
@@ -1,3 +1,7 @@
+2014-02-10  David Malcolm  
+
+   * TODO.rst: Update.
+
 2014-02-06  David Malcolm  
 
* libgccjit++.h: Include  rather than , since
diff --git a/gcc/jit/TODO.rst b/gcc/jit/TODO.rst
index 0572b78..c149dde 100644
--- a/gcc/jit/TODO.rst
+++ b/gcc/jit/TODO.rst
@@ -18,9 +18,27 @@ Initial Release
   * more types:
 * unions
 * function ptrs
+* explicitly opaque structs, perhaps:
 
-* how do you encode "x[5]=y;"?  should gcc_jit_context_new_array_lookup()
-  return an lvalue rather than an rvalue?
+extern gcc_jit_type *
+gcc_jit_context_new_opaque_struct (gcc_jit_context *ctxt,
+   const char *name);
+
+* ability to create self-referential structs, or cycles in the graph:
+
+ struct foo { struct bar *m_bar; }
+ struct bar { struct foo *m_foo; }
+
+* get int type with given number of either bits or bytes:
+
+extern gcc_jit_type *
+gcc_jit_context_get_int_type (gcc_jit_context *ctxt,
+  int num_bytes,
+  int is_signed);
+
+  * ability to bind a pre-existing global variable
+
+* expose the statements in the API? (mostly so they can be stringified?)
 
 * explicit casts::
 
@@ -53,13 +71,6 @@ Initial Release
 
   and, indeed, clarify all of the other operations.
 
-* array types, in case they're needed for structs::
-
-extern gcc_jit_type *
-gcc_jit_context_new_array_type (gcc_jit_context *ctxt,
-gcc_jit_type *type,
-int num_elements);
-
 * expressing branch probabilies (like __builtin_expect)::
 
 extern gcc_jit_rvalue *
@@ -74,22 +85,16 @@ Initial Release
 
   be better?  (for expressing how hot the current location is)
 
+* ability to give contexts names, for ease of debugging?
+
 * can we call into GCC builtins?  What might people need?
 
 * docs
 
-* fixing all the state issues
-
-* make the dirty dirty hacks less egregious...
-
-* pkgconfig .pc file
-
 * add a SONAME to the library (and potentially version the symbols?)
 
 * add myself as maintainer
 
-* valgrind; fix memory leaks
-
 * do we need alternative forms of division (floor vs rounding)?
 
 * are we missing any ops?
@@ -104,7 +109,10 @@ Initial Release
 
 * gcc_jit_context_new_rvalue_from_int: must be a numeric type
 
-* gcc_jit_context_zero: must be a numeric type
+* gcc_jit_context_zero: must be a numeric type.  If we do this should
+  we introduce a gcc_jit_context_null for pointer types?  (you can do
+  this via gcc_jit_context_new_rvalue_from_ptr, but having an explicit
+  hook is friendlier).
 
 * gcc_jit_context_one: must be a numeric type
 
@@ -133,10 +141,35 @@ Initial Release
 
 * gcc_jit_loop_end: verify that loops are validly nested?
 
+Bugs
+
+* INTERNAL functions don't seem to work (see e.g. test-quadratic, on trying
+  to make calc_disc be internal leads to:
+/tmp/libgccjit-4FZm6B/fake.so: undefined symbol: calc_discriminant
+  works at -O3 (because it inlines away the call); fails at -O0
+
+* fixing all the state issues: make it work repeatedly with optimization
+  turned up to full.
+
+* make the dirty dirty hacks less egregious...
+
+* pkgconfig .pc file
+
+* test under valgrind; fix memory leaks
+
+* re-architect gcc so we don't have to reinitialize everything every time
+  a context is compiled
+
 Test suite
 ==
 * get DejaGnu to build and run C++ testcases
 
+* add a multi-threaded test (perhaps based on test-combination.c, with a
+  thread pool working through multiple instances of the various underlying
+  tests, each thread having a separate gcc_jit_context)
+
+* verify that nested loops work OK
+
 Future milestones
 =
 * try porting llvmpipe to gcc
-- 
1.7.11.7

Re: [RFA][middle-end/52306] Fix reload from creating invalid RTL

[Ulrich Weigand]

Jeff Law wrote:

> Anyway, we're processing the input reload for insn 73.  We see that insn 
> 71's SET_DEST is the same as the input reload.  The input reload's 
> reloadreg is a0.  Replacing (reg:SI 48) with a0 in insn 71 produces an 
> insn which is recognized and which satisfies its constraints.  However, 
> we have a0 used within an increment addressing mode and elsewhere in the 
> same insn, which is invalid RTL.  Eventually we blow up in cselib due to 
> the invalid RTL.

I see, this analysis makes sense to me, and the fix looks straightforward.
Thanks for looking into this!

>   PR middle-end/52306
>   * reload1.c (emit_input_reload_insns): Do not create invalid RTL
>   when changing the SET_DEST of a prior insn to avoid an input
>   reload.

This is OK.

Thanks,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  ulrich.weig...@de.ibm.com

Re: RFA: patch for PR59535

[Richard Earnshaw]

On 07/02/14 22:06, Jeff Law wrote:
> On 02/07/14 11:20, Vladimir Makarov wrote:
>>The following patch improves code size for ARM.  Before the patch
>> CSiBE size generated by GCC configured --with-arch=armv7-a
>> --with-fpu=vfpv3-d16 --with-float=hard (with -mthumb) was
>>
>> 2414926
>>
>> After the patch the size is
>>
>> 2396798
>>
>> For comparison, when the reload pass is used the size is
>>
>> 2400154
>>
>> The change in arm.h is to prevent reloading sp as an address by LRA.
>> Reload has no such problem as it uses legitimate address hook and LRA
>> mostly relies on base_reg_class.
>>
>> Richard, is this part ok to commit to the trunk?
> I think so.  It's fixing a P1 regression, that makes it "in scope" as 
> far as I'm concerned.
> 

While this is a useful fix for Thumb2 (which had regressed slightly),
the PR is for Thumb1.  I tried this patch when compiling CSiBE with
-mthumb -mcpu=arm7tdmi -Os.  Sadly it made no difference at all to the
numbers there.

So this does not resolve PR59535.

R.

> 
>>
>> The change in lra-constraints.c is for correct alternative choice in
>> move patterns when pseudo is of class of general reg and one alternative
>> contains lo regs and another one contains hi regs.
>>
>> The patch was bootstrapped on x86/x86-64 and arm.
>>
>> 2014-02-07  Vladimir Makarov  
>>
>>  PR rtl-optimization/59535
>>  * lra-constraints.c (process_alt_operands): Encourage alternative
>>  when unassigned pseudo class is superset of the alternative class.
>>  * config/arm/arm.h (MODE_BASE_REG_CLASS): Return CORE_REGS for
>>  Thumb2 for LRA.
> Just one nit in the comment in lra-constraints.c
> s/stil/still/
> Jeff
> 
> 
> 

[PING]Re: [PATCH][AARCH64]Resolves testsuite/gcc.target/aarch64/aapcs64/ret-func-1.c regression

[Renlin Li]

On 03/02/14 10:02, Renlin Li wrote:

On 02/02/14 19:02, Renlin Li wrote:

Hi all,

This is a simple patch which resolves 
testsuite/gcc.target/aarch64/aapcs64/ret-func-1.c regression.


Basically, no special operations are needed for vector type i32in128 
or f32in64 in big-endian mode any more due the aarch64 back-end change.


Okay for trunk?

Kind regards,
Renlin Li


Hi all,

I forgot to attach the ChangeLog. Sorry for this additional annoying 
email.


Kind regards,
Renlin Li

gcc/testsuite/ChangeLog:

2014-02-03  Renlin Li  

* gcc.target/aarch64/aapcs64/validate_memory.h: move f32in64 and 
i32in128 cases

outside special big-endian processing block.

Hi all,

Could somebody help me to review this patch?
Thanks!

Kind regards,
Renlin Li

[PING]Re: [PATCH][ARM]fix potential testsuite/gcc.target/arm/fixed_float_conversion.c regression

[Renlin Li]

On 03/02/14 15:56, Renlin Li wrote:

Hi all,

This patch will ensure 
testsuite/gcc.target/arm/fixed_float_conversion.c is checked only when 
"-mfpu=vfp3 -mfloat-abi=softfp" is applicable for the target.


Accordingly, two procs (check_effective_target_arm_vfp3_ok and 
add_options_for_arm_vfp3) are added into 
gcc/testsuite/lib/target-supports.exp.


I have also update related documentation.

Okay for trunk?

Kind regards,
Renlin Li


gcc/testsuite/ChangeLog:

2014-02-03  Renlin Li  

* gcc.target/arm/fixed_float_conversion.c: Add arm_vfp3 option to 
the test case.

* lib/target-supports.exp: check_effective_target_arm_vfp3_ok: New.
add_options_for_arm_vfp3: New.


gcc/ChangeLog:

2014-02-03  Renlin Li  

* doc/sourcebuild.texi: Document 
check_effective_target_arm_vfp3_ok and

add_options_for_arm_vfp3


Hi,

Anybody help me to review this patch?

Thanks!

Kind regards,
Renlin Li

[C PATCH] Improve column info of initializers (PR c/60114)

[Marek Polacek]

This patch improves location information in a bunch of various
initializers; see the testcase.  Main issue was that digest_init
was getting only input_location.

Regtested/bootstrapped on x86_64-linux, ok for trunk at this stage
or should I queue it for 5.0?

2014-02-10  Marek Polacek  

PR c/60114
c/
* c-parser.c (c_parser_initelt): Pass input_location to
process_init_element.
(c_parser_initval): Pass loc to process_init_element.
* c-tree.h (process_init_element): Adjust declaration.
* c-typeck.c (push_init_level): Pass input_location to
process_init_element.
(pop_init_level): Likewise.
(set_designator): Likewise.
(output_init_element): Add location_t parameter.  Pass loc to
digest_init.
(output_pending_init_elements): Pass input_location to
output_init_element.
(process_init_element): Add location_t parameter.  Pass loc to
output_init_element.
testsuite/
* gcc.dg/pr60114.c: New test.

diff --git gcc/c/c-parser.c gcc/c/c-parser.c
index 66625aa..75ce935 100644
--- gcc/c/c-parser.c
+++ gcc/c/c-parser.c
@@ -4219,7 +4219,8 @@ c_parser_initelt (c_parser *parser, struct obstack * 
braced_init_obstack)
  init.original_type = NULL;
  c_parser_error (parser, "expected identifier");
  c_parser_skip_until_found (parser, CPP_COMMA, NULL);
- process_init_element (init, false, braced_init_obstack);
+ process_init_element (input_location, init, false,
+   braced_init_obstack);
  return;
}
}
@@ -4351,7 +4352,8 @@ c_parser_initelt (c_parser *parser, struct obstack * 
braced_init_obstack)
  init.original_type = NULL;
  c_parser_error (parser, "expected %<=%>");
  c_parser_skip_until_found (parser, CPP_COMMA, NULL);
- process_init_element (init, false, braced_init_obstack);
+ process_init_element (input_location, init, false,
+   braced_init_obstack);
  return;
}
}
@@ -4372,18 +4374,19 @@ c_parser_initval (c_parser *parser, struct c_expr 
*after,
 {
   struct c_expr init;
   gcc_assert (!after || c_dialect_objc ());
+  location_t loc = c_parser_peek_token (parser)->location;
+
   if (c_parser_next_token_is (parser, CPP_OPEN_BRACE) && !after)
 init = c_parser_braced_init (parser, NULL_TREE, true);
   else
 {
-  location_t loc = c_parser_peek_token (parser)->location;
   init = c_parser_expr_no_commas (parser, after);
   if (init.value != NULL_TREE
  && TREE_CODE (init.value) != STRING_CST
  && TREE_CODE (init.value) != COMPOUND_LITERAL_EXPR)
init = convert_lvalue_to_rvalue (loc, init, true, true);
 }
-  process_init_element (init, false, braced_init_obstack);
+  process_init_element (loc, init, false, braced_init_obstack);
 }
 
 /* Parse a compound statement (possibly a function body) (C90 6.6.2,
diff --git gcc/c/c-tree.h gcc/c/c-tree.h
index 84d5e0b..ec1fa92 100644
--- gcc/c/c-tree.h
+++ gcc/c/c-tree.h
@@ -612,7 +612,8 @@ extern void push_init_level (int, struct obstack *);
 extern struct c_expr pop_init_level (int, struct obstack *);
 extern void set_init_index (tree, tree, struct obstack *);
 extern void set_init_label (tree, struct obstack *);
-extern void process_init_element (struct c_expr, bool, struct obstack *);
+extern void process_init_element (location_t, struct c_expr, bool,
+ struct obstack *);
 extern tree build_compound_literal (location_t, tree, tree, bool);
 extern void check_compound_literal_type (location_t, struct c_type_name *);
 extern tree c_start_case (location_t, location_t, tree);
diff --git gcc/c/c-typeck.c gcc/c/c-typeck.c
index da6a6fc..6953881 100644
--- gcc/c/c-typeck.c
+++ gcc/c/c-typeck.c
@@ -102,8 +102,8 @@ static int spelling_length (void);
 static char *print_spelling (char *);
 static void warning_init (int, const char *);
 static tree digest_init (location_t, tree, tree, tree, bool, bool, int);
-static void output_init_element (tree, tree, bool, tree, tree, int, bool,
-struct obstack *);
+static void output_init_element (location_t, tree, tree, bool, tree, tree, int,
+bool, struct obstack *);
 static void output_pending_init_elements (int, struct obstack *);
 static int set_designator (int, struct obstack *);
 static void push_range_stack (tree, struct obstack *);
@@ -7161,13 +7161,15 @@ push_init_level (int implicit, struct obstack * 
braced_init_obstack)
  if ((TREE_CODE (constructor_type) == RECORD_TYPE
   || TREE_CODE (constructor_type) == UNION_TYPE)
  && constructor_fields == 0)
-   process_init_element (pop_init_level (1, braced_init_obstack),
+   proc

Re: {GRAPHITE] Replacement of isl_int by isl_val

[Tobias Grosser]

On 02/10/2014 04:12 AM, Richard Biener wrote:

On Sun, Feb 9, 2014 at 9:19 PM, Tobias Grosser  wrote:

On 02/09/2014 04:47 PM, Mircea Namolaru wrote:


Patch for replacement of the isl_int (obsolete) by isl_val.

No regressions for c/c++/fortran on x86-64 Linux.



Hi Mircae,

thanks a lot for looking into this.

Just for people not aware of the idea of this patch. Cloog recently upgraded
to the latest version of isl (isl-0.12.2) and with this
release isl deprecated the isl_int interface in favor of the isl_val
interface.


It seems that neither ISL 0.10 nor 0.11 or 0.11.1 has isl_val though, so
this patch would need to adjust the ISL version check in the toplevel
configure.

Which also makes this patch not suitable for this stage but it has to
wait for stage1.


That's what I thought. Thanks for clarifying.


Btw, Mircea - do you have a copyright assignment on file with the FSF
covering work on GCC?


Good point. I will be verifying this with Mircae.

Cheers,
Tobias

Re: [PATCH] Fix PR60115

[Jakub Jelinek]

On Mon, Feb 10, 2014 at 02:22:44PM +0100, Richard Biener wrote:
> 
> This fixes PR60115 where the issue is that tree_could_trap_p does
> not evaluate MEM_REFs for possibly out-of-bound accesses (in case
> the access is lowered from an ARRAY_REF where the code does that).
> 
> I've unified TARGET_MEM_REF and MEM_REF handling and made the
> order of checking for trapping base and !TREE_THIS_NOTRAP match
> the (non-obvious?) way ARRAY_REF handling works.
> 
> Testing for an overlap of at least on byte (thus not considering
> the size of the access) should be ok IMHO as alignment constraints
> or outer component refs should impose enough constraints that
> the source should be invalid if that's not enough.
> 
> Bootstrapped and tested on x86_64-unknown-linux-gnu.
> 
> Does this look sane?

LGTM.

> 2014-02-10  Richard Biener  
> 
>   PR tree-optimization/60115
>   * tree-eh.c (tree_could_trap_p): Unify TARGET_MEM_REF and
>   MEM_REF handling.  Properly verify that the accesses are not
>   out of the objects bound.
> 
>   * gcc.dg/torture/pr60115.c: New testcase.

Jakub

[PATCH] Fix PR60115

[Richard Biener]

This fixes PR60115 where the issue is that tree_could_trap_p does
not evaluate MEM_REFs for possibly out-of-bound accesses (in case
the access is lowered from an ARRAY_REF where the code does that).

I've unified TARGET_MEM_REF and MEM_REF handling and made the
order of checking for trapping base and !TREE_THIS_NOTRAP match
the (non-obvious?) way ARRAY_REF handling works.

Testing for an overlap of at least on byte (thus not considering
the size of the access) should be ok IMHO as alignment constraints
or outer component refs should impose enough constraints that
the source should be invalid if that's not enough.

Bootstrapped and tested on x86_64-unknown-linux-gnu.

Does this look sane?

Thanks,
Richard.

2014-02-10  Richard Biener  

PR tree-optimization/60115
* tree-eh.c (tree_could_trap_p): Unify TARGET_MEM_REF and
MEM_REF handling.  Properly verify that the accesses are not
out of the objects bound.

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

Index: gcc/tree-eh.c
===
*** gcc/tree-eh.c   (revision 207649)
--- gcc/tree-eh.c   (working copy)
*** tree_could_trap_p (tree expr)
*** 2610,2621 
   restart:
switch (code)
  {
- case TARGET_MEM_REF:
-   if (TREE_CODE (TMR_BASE (expr)) == ADDR_EXPR
- && !TMR_INDEX (expr) && !TMR_INDEX2 (expr))
-   return false;
-   return !TREE_THIS_NOTRAP (expr);
- 
  case COMPONENT_REF:
  case REALPART_EXPR:
  case IMAGPART_EXPR:
--- 2610,2615 
*** tree_could_trap_p (tree expr)
*** 2642,2651 
return false;
return !in_array_bounds_p (expr);
  
  case MEM_REF:
!   if (TREE_CODE (TREE_OPERAND (expr, 0)) == ADDR_EXPR)
return false;
!   /* Fallthru.  */
  case INDIRECT_REF:
return !TREE_THIS_NOTRAP (expr);
  
--- 2636,2671 
return false;
return !in_array_bounds_p (expr);
  
+ case TARGET_MEM_REF:
  case MEM_REF:
!   if (TREE_CODE (TREE_OPERAND (expr, 0)) == ADDR_EXPR
! && tree_could_trap_p (TREE_OPERAND (TREE_OPERAND (expr, 0), 0)))
!   return true;
!   if (TREE_THIS_NOTRAP (expr))
return false;
!   /* We cannot prove that the access is in-bounds when we have
!  variable-index TARGET_MEM_REFs.  */
!   if (code == TARGET_MEM_REF
! && (TMR_INDEX (expr) || TMR_INDEX2 (expr)))
!   return true;
!   if (TREE_CODE (TREE_OPERAND (expr, 0)) == ADDR_EXPR)
!   {
! tree base = TREE_OPERAND (TREE_OPERAND (expr, 0), 0);
! double_int off = mem_ref_offset (expr);
! if (off.is_negative ())
!   return true;
! if (TREE_CODE (base) == STRING_CST)
!   return double_int::from_uhwi (TREE_STRING_LENGTH (base)).ule (off);
! else if (DECL_SIZE_UNIT (base) == NULL_TREE
!  || TREE_CODE (DECL_SIZE_UNIT (base)) != INTEGER_CST
!  || tree_to_double_int (DECL_SIZE_UNIT (base)).ule (off))
!   return true;
! /* Now we are sure the first byte of the access is inside
!the object.  */
! return false;
!   }
!   return true;
! 
  case INDIRECT_REF:
return !TREE_THIS_NOTRAP (expr);
  
Index: gcc/testsuite/gcc.dg/torture/pr60115.c
===
*** gcc/testsuite/gcc.dg/torture/pr60115.c  (revision 0)
--- gcc/testsuite/gcc.dg/torture/pr60115.c  (working copy)
***
*** 0 
--- 1,14 
+ /* { dg-do run } */
+ 
+ int a, b[2];
+ 
+ int
+ main ()
+ {
+ lbl:
+   for (; a; a--)
+ if (b[1])
+   goto lbl;
+ 
+   return 0;
+ }

[PATCH][AArch64][committed] Fix typo in aarch64.c

[Kyrill Tkachov]

Hi all,

I've committed the attached typo fix as obvious as r207654.

Cheers,
Kyrill

2014-02-10  Kyrylo Tkachov  

* config/aarch64/aarch64.c (aarch64_override_options): Fix typo from
coretex to cortex.diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 16c51a8..784bfa3 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -5244,7 +5244,7 @@ aarch64_override_options (void)
 
   /* If the user did not specify a processor, choose the default
  one for them.  This will be the CPU set during configuration using
- --with-cpu, otherwise it is "coretex-a53".  */
+ --with-cpu, otherwise it is "cortex-a53".  */
   if (!selected_cpu)
 {
   selected_cpu = &all_cores[TARGET_CPU_DEFAULT & 0x3f];

Minor fixes in ipa-devirt.c

[Eric Botcazou]

get_polymorphic_call_info_from_invariant is declared as returning bool but 
actually returns NULL_TREE in several places, and there are several lines in 
possible_polymorphic_call_targets with dozens(!) of trailing spaces.

Tested on x86-64/Linux, applied on the mainline as obvious.


2014-02-10  Eric Botcazou  

* ipa-devirt.c (get_polymorphic_call_info_from_invariant): Return
proper constants and fix formatting.
(possible_polymorphic_call_targets): Fix formatting.


-- 
Eric BotcazouIndex: ipa-devirt.c
===
--- ipa-devirt.c	(revision 207641)
+++ ipa-devirt.c	(working copy)
@@ -1102,23 +1102,19 @@ get_polymorphic_call_info_from_invariant
   tree base;
 
   if (TREE_CODE (cst) != ADDR_EXPR)
-return NULL_TREE;
+return false;
 
   cst = TREE_OPERAND (cst, 0);
   base = get_ref_base_and_extent (cst, &offset2, &size, &max_size);
-  if (!DECL_P (base)
-  || max_size == -1
-  || max_size != size)
-return NULL_TREE;
+  if (!DECL_P (base) || max_size == -1 || max_size != size)
+return false;
 
   /* Only type inconsistent programs can have otr_type that is
  not part of outer type.  */
-  if (!contains_type_p (TREE_TYPE (base),
-			offset, otr_type))
-return NULL_TREE;
+  if (!contains_type_p (TREE_TYPE (base), offset, otr_type))
+return false;
 
-  get_polymorphic_call_info_for_decl (context,
- base, offset);
+  get_polymorphic_call_info_for_decl (context, base, offset);
   return true;
 }
 
@@ -1383,12 +1379,12 @@ possible_polymorphic_call_targets (tree
   tree binfo, target;
   bool final;
 
-  if (!odr_hash.is_created ())
-{ 
-  if (completep)  
-	*completep = false;
-  return nodes;   
-} 
+  if (!odr_hash.is_created ())
+{
+  if (completep)
+	*completep = false;
+  return nodes;
+}
 
   type = get_odr_type (otr_type, true);
 
@@ -1396,7 +1392,7 @@ possible_polymorphic_call_targets (tree
   if (context.outer_type)
 get_class_context (&context, otr_type);
 
-  /* We now canonicalize our query, so we do not need extra hashtable entries.  */
+  /* We canonicalize our query, so we do not need extra hashtable entries.  */
 
   /* Without outer type, we have no use for offset.  Just do the
  basic search from innter type  */
@@ -1457,7 +1453,6 @@ possible_polymorphic_call_targets (tree
   matched_vtables = pointer_set_create ();
 
   /* First see virtual method of type itself.  */
-
   binfo = get_binfo_at_offset (TYPE_BINFO (outer_type->type),
 			   context.offset, otr_type);
   target = gimple_get_virt_method_for_binfo (otr_token, binfo);
@@ -1474,6 +1469,7 @@ possible_polymorphic_call_targets (tree
  is that it has been fully optimized out.  */
   else if (flag_ltrans || !type->anonymous_namespace)
 final = false;
+
   pointer_set_insert (matched_vtables, BINFO_VTABLE (binfo));
 
   /* Next walk bases, if asked to.  */
@@ -1492,10 +1488,12 @@ possible_polymorphic_call_targets (tree
   for (i = 0; i < outer_type->derived_types.length(); i++)
 	possible_polymorphic_call_targets_1 (nodes, inserted,
 	 matched_vtables,
-	 otr_type, outer_type->derived_types[i],
+	 otr_type,
+	 outer_type->derived_types[i],
 	 otr_token, outer_type->type,
 	 context.offset);
 }
+
   (*slot)->targets = nodes;
   (*slot)->final = final;
   if (completep)

Re: [testsuite, committed] Fix effective target for ivdep tests

[Eric Botcazou]

> The ivdep tests use int arrays but required vect_float rather than vect_int.
> 
> Tested on mipsisa64-sde-elf, where it fixes some spurious failures for
> -mips32r2/-mfp64, and on mips64-linux-gnu.  Applied as obvious.

The 3rd and 4th tests also require vect_int_mult.

Tested on x86-64/Linux and SPARC/Solaris, applied on the mainline as obvious.


2014-02-10  Eric Botcazou  

* g++.dg/vect/pr33426-ivdep-3.cc: Require vect_int_mult as well.
* g++.dg/vect/pr33426-ivdep-4.cc: Likewise.


-- 
Eric BotcazouIndex: g++.dg/vect/pr33426-ivdep-4.cc
===
--- g++.dg/vect/pr33426-ivdep-4.cc	(revision 207641)
+++ g++.dg/vect/pr33426-ivdep-4.cc	(working copy)
@@ -1,5 +1,6 @@
 /* { dg-do compile } */
 /* { dg-require-effective-target vect_int } */
+/* { dg-require-effective-target vect_int_mult } */
 /* { dg-additional-options "-std=c++11 -O3 -fopt-info-vec-optimized -fdump-tree-original -fdump-tree-gimple" } */
 
 /* PR other/33426 */
Index: g++.dg/vect/pr33426-ivdep-3.cc
===
--- g++.dg/vect/pr33426-ivdep-3.cc	(revision 207641)
+++ g++.dg/vect/pr33426-ivdep-3.cc	(working copy)
@@ -1,5 +1,6 @@
 /* { dg-do compile } */
 /* { dg-require-effective-target vect_int } */
+/* { dg-require-effective-target vect_int_mult } */
 /* { dg-additional-options "-std=c++11 -O3 -fopt-info-vec-optimized -fdump-tree-original -fdump-tree-gimple" } */
 
 /* PR other/33426 */

[PATCH][ARM] Add -mcpu=native detection for Cortex-A53, A57

[Kyrill Tkachov]

Hi all,

This patchlet adds the part numbers for the Cortex-A53 and A57 cores so that 
they can be detected when parsing /proc/cpuinfo on AArch32 Linux systems. This 
will allow the -mcpu=native machinery to detect those cores.


Tested arm-none-eabi on a model.

This is a fairly innocuous change, is it ok at this stage or for next stage 1?

Thanks,
Kyrill

2014-02-10  Kyrylo Tkachov  

* config/arm/driver-arm.c (arm_cpu_table): Add entries for Cortex-A53,
Cortex-A57.diff --git a/gcc/config/arm/driver-arm.c b/gcc/config/arm/driver-arm.c
index 6d9c417..a4a62cc 100644
--- a/gcc/config/arm/driver-arm.c
+++ b/gcc/config/arm/driver-arm.c
@@ -42,6 +42,8 @@ static struct vendor_cpu arm_cpu_table[] = {
 {"0xc09", "armv7-a", "cortex-a9"},
 {"0xc0d", "armv7ve", "cortex-a12"},
 {"0xc0f", "armv7ve", "cortex-a15"},
+{"0xd03", "armv8-a+crc", "cortex-a53"},
+{"0xd07", "armv8-a+crc", "cortex-a57"},
 {"0xc14", "armv7-r", "cortex-r4"},
 {"0xc15", "armv7-r", "cortex-r5"},
 {"0xc20", "armv6-m", "cortex-m0"},

Re: [PATCH 5/6] [GOMP4] OpenACC 1.0+ support in fortran front-end

[Thomas Schwinge]

Hi!

On Mon, 10 Feb 2014 13:44:51 +0400, Ilmir Usmanov  wrote:
> > As -fopenmp seemingly can be mixed with -fopenacc, I think it would be 
> > nice to have some test cases where !$omp and !$acc are both placed - 
> > in either order - before the same Fortran statement.
> >
> I'm going to test this, too. There are can be some compilcations while 
> using both !$omp and !$acc on single statement.

For the record, in the C front end and middle end, I'm currently refusing
any nesting of OpenACC and OpenMP directives (keeping that "fun" for
later...).  See gcc/testsuite/c-c++-common/goacc-gomp/nesting-fail-1.c
and gcc/testsuite/c-c++-common/goacc/nesting-fail-1.c in r204532,
.


Grüße,
 Thomas


pgp1P6pg8A61O.pgp
Description: PGP signature

Re: [PATCH][ARM] Adjust thumb2_movhi_insn patter

[Ramana Radhakrishnan]

On Mon, Feb 3, 2014 at 11:39 AM, Kyrill Tkachov  wrote:
> Hi all,
>
> This patch updates the thumb2_movhi_insn pattern for the -mrestrict-it
> rules. I had somehow missed it when doing the -mrestrict-it work last year,
> and it is possible to generate a deprecated IT block form in ARMv8 Thumb2
> codegen without this patch.
>
> Tested arm-none-eabi and bootstrapped on arm-none-linux-gnueabihf.
>
> Ok for trunk?

Ok if release managers don't object in 24 hours.

regards
Ramana

>
> Thanks,
> Kyrill
>
> 2014-02-03  Kyrylo Tkachov  
>
> * config/arm/thumb2.md (*thumb2_movhi_insn): Add alternatives for
> arm_restrict_it.

Re: [committed] Fix #pragma omp simd with local address taken variables (PR c/59984)

[Jakub Jelinek]

On Sun, Feb 09, 2014 at 01:09:28PM +0100, Dominique Dhumieres wrote:
> The test gcc.dg/vect/pr59984.c fails on targets using an as that does
> not support avx instructions (e.g., darwin).

I've committed this to hopefully fix that.

2014-02-10  Jakub Jelinek  

* gcc.dg/vect/pr59984.c: Require effective target
vect_simd_clones.

--- gcc/testsuite/gcc.dg/vect/pr59984.c.jj  2014-02-08 10:09:34.0 
+0100
+++ gcc/testsuite/gcc.dg/vect/pr59984.c 2014-02-10 10:51:21.611141647 +0100
@@ -1,4 +1,5 @@
 /* PR c/59984 */
+/* { dg-require-effective-target vect_simd_clones } */
 /* { dg-additional-options "-fopenmp-simd" } */
 
 #include "tree-vect.h"

Jakub

Re: [PATCH][AArch64] Wire up Cortex-A57 rtx costs

[Marcus Shawcroft]

On 30 January 2014 13:48, Kyrill Tkachov  wrote:
> Hi all,
>
> This patch wires up the aarch64 backend to use the Cortex-A57 rtx costs
> table that is proposed at
> http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01954.html

OK if release manager agrees.

/Marcus

Re: [PATCH 5/6] [GOMP4] OpenACC 1.0+ support in fortran front-end

[Ilmir Usmanov]

Hi Tobias!

Thanks a lot for your review!

I'm going to test you notes in "reference implementation" (PGI 
compiler), and then share the results.


On 10.02.2014 03:42, Tobias Burnus wrote:
Is there a reason that you don't automatically add that flag via 
goacc.exp?

Ditto. Also spaces before/after the pattern should make it more unique.
I assume that this should be indeed "fopenmp" here and not "fopenacc" 
as both share libgomp?

Yes, I'll fix this, thank you.


As -fopenmp seemingly can be mixed with -fopenacc, I think it would be 
nice to have some test cases where !$omp and !$acc are both placed - 
in either order - before the same Fortran statement.


I'm going to test this, too. There are can be some compilcations while 
using both !$omp and !$acc on single statement.


--
Ilmir.

Re: [PATCH 5/6] [GOMP4] OpenACC 1.0+ support in fortran front-end

[Ilmir Usmanov]

Hi Thomas!

On 10.02.2014 12:52, Thomas Schwinge wrote:

--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/goacc/goacc.exp
@@ -0,0 +1,36 @@
+# Load support procs.
+load_lib gfortran-dg.exp
+
+if ![check_effective_target_fopenmp] {
+  return
+}

I assume that this should be indeed "fopenmp" here and not "fopenacc" as
both share libgomp?

It should be fopenacc, because it tests whether the compiler accepts
-fopenacc.
My bad. I've missed the fact that you use 
check_effective_target_fopenacc in gcc.gd/goacc/goacc.exp.



+# Main loop.
+gfortran-dg-runtest [lsort \
+   [find $srcdir/$subdir *.\[fF\]{,90,95,03,08} ] ] " -fopenacc 
-fdump-parse-tree"

As you use -fopenacc here, you probably can get rid of it in dg-options.

Right.


Can't you? I am not sure whether -fdump-parse-tree is needed; on the
other hand, it just clutters the *log files.

Yes, I think that should just be in the test case files that actually
need it?

I've also missed this, will fix.

I think, we need GENERIC nodes checks right now since the implementation 
is "up to GENERIC". However, in future, when back-end will be 
implemented, we can remove them.


--
Regards,
Ilmir.

Re: {GRAPHITE] Replacement of isl_int by isl_val

[Richard Biener]

On Sun, Feb 9, 2014 at 9:19 PM, Tobias Grosser  wrote:
> On 02/09/2014 04:47 PM, Mircea Namolaru wrote:
>>
>>Patch for replacement of the isl_int (obsolete) by isl_val.
>>
>>No regressions for c/c++/fortran on x86-64 Linux.
>
>
> Hi Mircae,
>
> thanks a lot for looking into this.
>
> Just for people not aware of the idea of this patch. Cloog recently upgraded
> to the latest version of isl (isl-0.12.2) and with this
> release isl deprecated the isl_int interface in favor of the isl_val
> interface.

It seems that neither ISL 0.10 nor 0.11 or 0.11.1 has isl_val though, so
this patch would need to adjust the ISL version check in the toplevel
configure.

Which also makes this patch not suitable for this stage but it has to
wait for stage1.

Btw, Mircea - do you have a copyright assignment on file with the FSF
covering work on GCC?

Thanks,
Richard.

> Both are interfaces for arbitrary precision numbers. However,
> the old isl_int interface was mostly a proxy to gmp, whereas the new
> interface hides the implementation and will later allow optimizations for
> the common use case of small integers.
>
> We really want to get to the latest version of isl as the newer releases
> (and development branches) provide very useful features
> including the possibility to bound the amount of computation before
> we fall back to a more conservative solution. This feature should help us to
> fix some of the newer bugs.
>
> I have doubts if we can still push this patch to graphite at this stage of
> trunk, but at the very least we should have it ready for stage-1.
>
> Regarding your patch. It looks generally very nice. Just a couple of smaller
> comments:
>
> - Can you adapt configure to only allow isl/cloog versions that actually
> support the new interface?
>
> - Can you updated the documentation that lists the supported isl/cloog
>   versions.
>
> Besides some inline comments:
>
>
>> Index: gcc/graphite-optimize-isl.c
>> ===
>> --- gcc/graphite-optimize-isl.c (revision 207298)
>> +++ gcc/graphite-optimize-isl.c (working copy)
>> @@ -260,6 +260,7 @@
>>  DimToVectorize can be devided by VectorWidth. The default VectorWidth
>> is
>>  currently constant and not yet target specific. This function does
>> not reason
>>  about parallelism.  */
>> +
>
>
> This change looks unrelated. Can you submit a separate fix?
>
>>   static isl_map *
>>   getPrevectorMap (isl_ctx *ctx, int DimToVectorize,
>>  int ScheduleDimensions,
>> @@ -273,8 +274,9 @@
>> isl_aff *Aff;
>> int PointDimension; /* ip */
>> int TileDimension;  /* it */
>> -  isl_int VectorWidthMP;
>> +  isl_val *VectorWidthMP;
>> int i;
>> +  isl_ctx *ct;
>
>
> We normally use 'ctx' as abbreviation for context.
>
>>
>> /* assert (0 <= DimToVectorize && DimToVectorize <
>> ScheduleDimensions);*/
>>
>> @@ -304,10 +306,10 @@
>> Aff = isl_aff_zero_on_domain (LocalSpaceRange);
>> Aff = isl_aff_set_constant_si (Aff, VectorWidth);
>> Aff = isl_aff_set_coefficient_si (Aff, isl_dim_in, TileDimension, 1);
>> -  isl_int_init (VectorWidthMP);
>> -  isl_int_set_si (VectorWidthMP, VectorWidth);
>> -  Aff = isl_aff_mod (Aff, VectorWidthMP);
>> -  isl_int_clear (VectorWidthMP);
>> +
>> +  ct = isl_aff_get_ctx (Aff);
>> +  VectorWidthMP = isl_val_int_from_si (ct, VectorWidth);
>> +  Aff = isl_aff_mod_val (Aff, VectorWidthMP);
>> Modulo = isl_pw_aff_zero_set (isl_pw_aff_from_aff (Aff));
>> TilingMap = isl_map_intersect_range (TilingMap, Modulo);
>>
>> Index: gcc/graphite-sese-to-poly.c
>> ===
>> --- gcc/graphite-sese-to-poly.c (revision 207298)
>> +++ gcc/graphite-sese-to-poly.c (working copy)
>> @@ -26,8 +26,15 @@
>>   #include 
>>   #include 
>>   #include 
>> +#include 
>> +#if defined(__cplusplus)
>> +extern "C" {
>> +#endif
>> +#include 
>> +#if defined(__cplusplus)
>> +}
>
>
> We should put a comment why this is extern "C" is necessary. Or better, we
> should check if Sven can get release us an isl 0.12.3 that includes the
> extern "C" in the relevant header"
>
>> +#endif
>>   #include 
>> -#include 
>
>
> This seems to be an unrelated fix. Can you submit a separate patch?
>
>>   #include 
>>   #endif
>>
>> @@ -67,7 +74,6 @@
>>   #include "graphite-poly.h"
>>   #include "graphite-sese-to-poly.h"
>>
>> -
>
>
> This change looks unrelated. Can you submit a separate fix?
>
>>   /* Assigns to RES the value of the INTEGER_CST T.  */
>>
>>   static inline void
>> @@ -481,13 +487,11 @@
>> int i;
>> int nb_iterators = pbb_dim_iter_domain (pbb);
>> int used_scattering_dimensions = nb_iterators * 2 + 1;
>> -  isl_int val;
>> +  isl_val *val;
>> isl_space *dc, *dm;
>>
>> gcc_assert (scattering_dimensions >= used_scattering_dimensions);
>>
>> -  isl_int_init (val);
>> -
>> dc = isl_set_get_space (pbb->domain);
>> dm = isl_space_add_dims (isl_space_from_domain (dc),
>> 

Re: [PATCH 2/6] [GOMP4] OpenACC 1.0+ support in fortran front-end

[Thomas Schwinge]

Hi!

On Mon, 10 Feb 2014 00:10:26 +0100, Tobias Burnus  wrote:
> Ilmir Usmanov wrote:
> > OpenACC 1.0 fortran FE support -- matching and resolving.

> > +static void
> > +resolve_oacc_cache (gfc_code *)
> > +{
> > +   //TODO: resolve subarrays
> > +}
> 
> ;-)

Just to clarify: I'm fine with incomplete changes being committed to the
gomp-4_0-branch, which is a development branch, as long as such changes
don't largely break the existing (working) code, as determined by the
testsuite for example.  Occasional "small" breakage should be fine, if it
is understood, and will be fixed later, like in the case where a recent
merge that I did from trunk into gomp-4_0-branch caused a regression in
one C++ OpenMP test case, which I could pinpoint to one
gomp-4_0-branch-specific patch, which Ilya Tocar by now has fixed
(pending commit).

What I'd generally like to see added are markers à la:

/* TODO: resolve subarrays */
gcc_unreachable ();

This makes it obvious both to the reader/reviewer and user of GCC ;-)
that this code path has not yet been implemented.  This is of course not
acceptable for released versions of GCC, but I think it's fine for the
gomp-4_0-branch, in this early OpenACC development stage.


Grüße,
 Thomas


pgp1UsgK6EtuJ.pgp
Description: PGP signature

Re: Use "[warning enabled by default]" for default warnings

[Richard Biener]

On Sun, Feb 9, 2014 at 9:30 PM, Robert Dewar  wrote:
> On 2/9/2014 3:23 PM, Richard Sandiford wrote:
>
>>> can't we just reword the one warning where there is an ambiguity to
>>> avoid the confusion, rather than creating such an earthquake, which
>>> as Arno says, really has zero advantages to Ada programmers, and clear
>>> disadvantages .. to me [enabled by default] is already awfully long!
>>
>>
>> Well, since the Ada part has been rejected I think we just need to
>> consider this from the non-Ada perspective.  And IMO there's zero
>> chance that each new warning will be audited for whether the
>> "[enabled by default]" will be unambiguous.  The fact that this
>> particular warning caused confusion and someone actually reported
>> it doesn't mean that there are no other warnings like that.  E.g.:
>>
>>-fprefetch-loop-arrays is not supported with -Os [enabled by default]
>>
>> could also be misunderstood, especially if working on an existing codebase
>> with an existing makefile.  And the effect for:
>>
>>pragma simd ignored because -fcilkplus is not enabled [enabled by
>> default]
>>
>> is a bit unfortunate.  Those were just two examples -- I'm sure I could
>> pick more.
>
>
> Indeed, worrisome examples,
>
> a shorter substitute would be [default warning]
>
> ???

Or print nothing at all?  After all [...] was supposed to tell people how
to disable the warning!  If there isn't a way to do that ... maybe instead
print [-w]?  hmm, all existing [...] are positive so we'd have to print
-no-w which doesn't exist.  Bah.  So there isn't a way to "negate" -w
on the commandline to only get default warnings enabled again.

Richard.

>>
>>
>> Thanks,
>> Richard
>>
>

Re: Avoid unnnecesary copying of ipa-prop's expressions

[Richard Biener]

On Fri, 7 Feb 2014, Jan Hubicka wrote:

> > On Thu, 6 Feb 2014, Jan Hubicka wrote:
> > 
> > > Hi,
> > > at WPA we currently read trees accessed by jump functions and then copy 
> > > them
> > > to remove location that is already known to be UNKNOWN and then keep 
> > > copying
> > > them for every inline clone introduced (and there are many for firefox)
> > > 
> > > This patch makes us to copy only when expression really has an location 
> > > in it.
> > > 
> > > Bootstrapped/regtested x86_64-linux, OK?
> > 
> > Hmm, I think you either can use just
> > 
> > if (EXPR_P (expr))
> >   walk_tree (&expr, prune_expr_location, NULL, NULL);
> > 
> > or you miss unsharing and create invalid shared trees when
> > the expr does not contain locations.
> > 
> > I fear it's the latter, given how ipa_set_jf_* is used.
> 
> Well, ipa-prop analysis takes random operands from GIMPLE bodies and 
> stores them into jump function. Then it streams in/out, propagates and 
> eventually uses them as a replacements for bodies.
> 
> We use unshare_without_location primarily to prevent LTO from need to stream
> stale BLOCK expressions and to avoid  inserting wrong blocks into clones
> http://gcc.gnu.org/ml/gcc-patches/2012-12/msg01176.html
> http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01343.html

I know.

> Calling prine_expr_location would kill locations in the original 
> function body they are taken from. For constant JF, they are IP 

Ah, true.

> invariants, so I do not think they need unsharing. THe arithmetic is 
> never inserted back to GIMPLE code.

Well.  Our sharing indeed allows is_gimple_min_invariant nodes to
be shared (tree-cfg.c:tree_node_can_be_shared).

So your original patch looks ok.

Thanks,
Richard.

> I can also just add no_unshare parameter to jump functions to avoid the 
> unsharing during stream-in, possibly.

Re: [PATCH 5/6] [GOMP4] OpenACC 1.0+ support in fortran front-end

[Thomas Schwinge]

Hi!

On Mon, 10 Feb 2014 00:42:54 +0100, Tobias Burnus  wrote:
> Some general questions to the patch set:

Thanks for helping review!


> * I miss "-fopenacc". Is the support already in the branch? I assume 
> that part is then in c-family/c.opt fortran/lang.opt?
> 
> * Documentation: Do you also need to update fortran/gfortran.texi and/or 
> fortran/invoke.texi? (I assume that -fopenacc is already documented in 
> docs/invoke.texi) [Search for openmp to find possible spots.]
> 
> * Intrinsic module "openacc" and "openacc_lib.h": I assume that those 
> will be created as follow up - or do they already exist? If so, do you 
> need to document something in fortran/intrinsic.texi? Or in libgomp.texi?

Please see

and following for the patch submissions including Fortran bits, and/or
something like the following for reviewing the existing set of changes on
gomp-4_0-branch:

$ svn log svn://gcc.gnu.org/svn/gcc/branches/gomp-4_0-branch | sed -n 
'/^svn merge/ { p; q; }'
svn merge -r205223:206958 svn+ssh://gcc.gnu.org/svn/gcc/trunk
$ svn diff svn://gcc.gnu.org/svn/gcc/trunk@206958 
svn://gcc.gnu.org/svn/gcc/branches/gomp-4_0-branch > diff

..., or the equivalent Git invocation (which is orders of magnitudes
faster):

$ git log origin/gomp-4_0-branch | sed -n '/svn merge/ { p; q; }'
svn merge -r205223:206958 svn+ssh://gcc.gnu.org/svn/gcc/trunk
$ git svn find-rev r206958 origin/trunk
765faa80eda3bb75aa044ad015e2e5214bf02c6d
$ git diff --stat 765faa80eda3bb75aa044ad015e2e5214bf02c6d 
origin/gomp-4_0-branch | grep -v ChangeLog
 gcc/Makefile.in|3 +-
 gcc/builtins.def   |   10 +
 gcc/c-family/c-cppbuiltin.c|3 +
 gcc/c-family/c-omp.c   |1 +
 gcc/c-family/c-pragma.c|   23 +
 gcc/c-family/c-pragma.h|   13 +-
 gcc/c-family/c.opt |4 +
 gcc/c/c-parser.c   |  278 -
 gcc/c/c-tree.h |1 +
 gcc/c/c-typeck.c   |   23 +-
 gcc/cgraph.h   |5 +
 gcc/cgraphbuild.c  |   14 +-
 gcc/cgraphunit.c   |   15 +-
 gcc/config/arc/arc.h   |2 +-
 gcc/config/darwin.h|2 +-
 gcc/config/i386/mingw32.h  |2 +-
 gcc/config/ia64/hpux.h |2 +-
 gcc/config/pa/pa-hpux11.h  |4 +-
 gcc/config/pa/pa64-hpux.h  |   24 +-
 gcc/cp/parser.c|2 +-
 gcc/doc/generic.texi   |5 +
 gcc/doc/gimple.texi|8 +
 gcc/doc/invoke.texi|   14 +-
 gcc/doc/sourcebuild.texi   |3 +
 gcc/fortran/cpp.c  |3 +
 gcc/fortran/f95-lang.c |   10 +
 gcc/fortran/gfortran.h |1 +
 gcc/fortran/invoke.texi|7 +-
 gcc/fortran/lang.opt   |4 +
 gcc/fortran/options.c  |5 +
 gcc/gcc.c  |5 +-
 gcc/gimple-low.c   |1 +
 gcc/gimple-pretty-print.c  |   58 +
 gcc/gimple-walk.c  |   16 +
 gcc/gimple.c   |   20 +
 gcc/gimple.def |   10 +-
 gcc/gimple.h   |  127 ++-
 gcc/gimplify.c |  144 ++-
 gcc/ipa-inline-analysis.c  |2 +-
 gcc/lto-cgraph.c   |   14 +
 gcc/lto-streamer.c |5 +-
 gcc/lto-streamer.h |6 +
 gcc/lto/lto-partition.c|3 +
 gcc/oacc-builtins.def  |   31 +
 gcc/omp-low.c  | 1081 
++
 gcc/passes.c   |6 +-
 gcc/testsuite/c-c++-common/cpp/openacc-define-1.c  |6 +
 gcc/testsuite/c-c++-common/cpp/openacc-define-2.c  |7 +
 gcc/testsuite/c-c++-common/cpp/openacc-define-3.c  |   11 +
 .../c-c++-common/goacc-gomp/nesting-fail-1.c   |  121 ++
 .../c-c

Re: [PATCH] New optimize(0) versioning fix (PR target/60026, take 2)

[Richard Biener]

On Fri, 7 Feb 2014, Jan Hubicka wrote:

> > On Fri, Feb 07, 2014 at 12:50:22AM +0100, Jan Hubicka wrote:
> > > Don't we want to check opt_for_fn (node->decl, cp) instead and arrange 
> > > -fipa-cp
> > > to be false when !optimize?
> > 
> > I can easily imagine using
> >   !opt_for_fn (node->decl, optimize)
> >   || !opt_for_fn (node->decl, flag_ipa_cp)
> > but guaranteeing flag_ipa_cp or flag_ipa_sra is never true for optimize == 0
> > could be harder, what if something is built with -O0 -fipa-cp or
> > __attribute__((optimize (0), "fipa-cp"))) or similar?  Checking optimize
> > value is among other things about the lack of vdef/vuse for !optimize.
> 
> I always tought it would be better to inform users that -O0 -fipa-cp is
> broken combination of flags (but it seems our policy to not do that)
> or just clear -fipa-cp while processing argument as we do for some
> other contradicting combinations.

Well, we have the very same issue for other optimization passes
and -O0 (and now also -Og).  The idea that you can _enable_
random passes is simply not true.

But yes, diagnosing that a switch is ignored would be nice ...

Richard.

Re: [PATCH] Fix Cilk+ catch_exc.cc

[Richard Biener]

On Sat, 8 Feb 2014, Jakub Jelinek wrote:

> Hi!
> 
> install_builtin calls build_fn_decl, which sets TREE_NOTHROW by default.
> In most cases I think that is desirable, but __cilkrts_rethrow apparently
> conditionally throws an exception, thus marking it TREE_NOTHROW is very much
> undesirable and the fact that the testcase happened to work (except for i?86
> recently) must have been by pure accident (that the call was between two
> instructions belonging to the right EH region?).
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

Ok.

Thanks,
Richard.

> 2014-02-08  Jakub Jelinek  
> 
>   * cilk-common.c (cilk_init_builtins): Clear TREE_NOTHROW
>   flag on __cilkrts_rethrow builtin.
> 
> --- gcc/cilk-common.c.jj  2014-02-06 23:06:47.0 +0100
> +++ gcc/cilk-common.c 2014-02-07 11:11:15.253128977 +0100
> @@ -285,6 +285,7 @@ cilk_init_builtins (void)
>/* __cilkrts_rethrow (struct stack_frame *);  */
>cilk_rethrow_fndecl = install_builtin ("__cilkrts_rethrow", fptr_fun, 
>BUILT_IN_CILK_RETHROW, false);
> +  TREE_NOTHROW (cilk_rethrow_fndecl) = 0;
>  
>/* __cilkrts_save_fp_ctrl_state (__cilkrts_stack_frame *);  */
>cilk_save_fp_fndecl = install_builtin ("__cilkrts_save_fp_ctrl_state", 
> 
>   Jakub
> 

Re: [patch] Fix array overflow in gcc.dg/vect/no-vfa-vect-depend-2.c

[Jakub Jelinek]

On Tue, Feb 04, 2014 at 04:59:14PM -0800, Paul Pluzhnikov wrote:
> gcc/testsuite/ChangeLog:
> 
> 2014-02-04  Paul Pluzhnikov  
> 
>   * gcc.dg/vect/no-vfa-vect-depend-2.c (main1): Fix buffer
>   overflow.

Ok, thanks.

> --- gcc/testsuite/gcc.dg/vect/no-vfa-vect-depend-2.c  (revision 207487)
> +++ gcc/testsuite/gcc.dg/vect/no-vfa-vect-depend-2.c  (working copy)
> @@ -15,7 +15,7 @@
>int i;
>  
>/* Not vectorizable due to data dependence: dependence distance 1.  */ 
> -  for (i = N - 1; i >= 0; i--)
> +  for (i = N - 2; i >= 0; i--)
>  {
>ia[i] = ia[i+1] * 4;
>  }
> @@ -28,7 +28,7 @@
>  } 
>  
>/* Vectorizable. Dependence distance -1.  */
> -  for (i = N - 1; i >= 0; i--)
> +  for (i = N - 2; i >= 0; i--)
>  {
>ib[i+1] = ib[i] * 4;
>  }

Jakub