Re: [PATCH, ARM] Fix line number data for PIC register setup code

[Tom de Vries]

On 14/10/13 00:17, Tom de Vries wrote:
> This patch makes sure we emit insertions scheduled for the first real BB 
> before
> NOTE_INSN_FUNCTION_BEG. As a consequence, it moves the PIC register setup code
> to before the NOTE_INSN_FUNCTION_BEG. This removes the second .loc, and the
> breakpoint of main ends up at line 8.
> 
> Bootstrapped and regtested on x86_64 (ada inclusive), no issues found.
> 
> Tested gdb with target arm-none-linux-gnueabi and CFLAGS_FOR_TARGET=-fPIC. The
> patch removes 174 FAILs.
> 
> Re-testing gcc with target arm-none-linux-gnueabi atm.
> 

No issues found.

OK for trunk?

Thanks,
- Tom

RE: [PATCH] Reassociate X == CST1 || X == CST2 if popcount (CST2 - CST1) == 1 into ((X - CST1) & ~(CST2 - CST1)) == 0

[Zhenqiang Chen]

Patch and test cases are updated according to your comments.

Bootstrap and no make check regression on X86-64.

ChangeLog:
2013-10-14  Zhenqiang Chen  

* tree-ssa-reassoc.c (try_transfer_range_tests_1): New function,
extracted from optimize_range_tests
* (try_transfer_range_tests_2): New function.
* (try_transfer_range_tests): New function, extracted from
optimize_range_tests and calls try_transfer_range_tests_1 and
try_transfer_range_tests_2,
* (optimize_range_tests): Use try_transfer_range_tests.

testsuite/ChangeLog:
2013-10-14  Zhenqiang Chen  

* gcc.dg/tree-ssa/reassoc-32.c: New test case.
* gcc.dg/tree-ssa/reassoc-33.c: New test case.
* gcc.dg/tree-ssa/reassoc-34.c: New test case.
* gcc.dg/tree-ssa/reassoc-35.c: New test case.
* gcc.dg/tree-ssa/reassoc-36.c: New test case.

> -Original Message-
> From: Jakub Jelinek [mailto:ja...@redhat.com]
> Sent: Saturday, October 12, 2013 3:40 PM
> To: Zhenqiang Chen
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] Reassociate X == CST1 || X == CST2 if popcount (CST2
-
> CST1) == 1 into ((X - CST1) & ~(CST2 - CST1)) == 0
> 
> On Sat, Oct 12, 2013 at 10:08:12AM +0800, Zhenqiang Chen wrote:
> > As you had mentioned, the transition in this patch does not reduce
> > instructions. But the preexisting optimization does. So we prefer to
> > do the preexisting optimization first. E.g.
> >
> > X == 10 || X == 12 || X == 26
> 
> Ok, that makes sense.
> 
> @@ -2279,6 +2275,71 @@ optimize_range_tests (enum tree_code opcode,
>   }
>  }
> 
> +  /* Optimize X == CST1 || X == CST2
> + if popcount (CST2 - CST1) == 1 into
> + ((X - CST1) & ~(CST2 - CST1)) == 0.  */
> 
> Mention here also similarly to the other comment that it works also with
> ranges.
> 
> +  if (BRANCH_COST (optimize_function_for_speed_p (cfun), false) >= 2)
> +for (i = first; i < length; i++)
> +  {
> + tree lowi, highi, lowj, highj, type, tem1, tem2, mask;
> +
> + if (ranges[i].exp == NULL_TREE || ranges[i].in_p)
> +   continue;
> + type = TREE_TYPE (ranges[i].exp);
> + if (!INTEGRAL_TYPE_P (type))
> +   continue;
> + lowi = ranges[i].low;
> + if (lowi == NULL_TREE)
> +   continue;
> 
> The other loop has here:
>   if (lowi == NULL_TREE)
> lowi = TYPE_MIN_VALUE (type);
> instead, which is better, can you please change it?
> 
> + highi = ranges[i].high;
> + if (highi == NULL_TREE)
> +   continue;
> + for (j = i + 1; j < length && j < i + 64; j++)
> +   {
> + lowj = ranges[j].low;
> + if (lowj == NULL_TREE)
> +   continue;
> + highj = ranges[j].high;
> + if (highj == NULL_TREE)
> +   continue;
> 
> The other loop has
>   if (highj == NULL_TREE)
> highj = TYPE_MAX_VALUE (type);
> here instead.
> 
> + if (ranges[j].exp == NULL_TREE || ranges[j].in_p
> + || (ranges[i].exp != ranges[j].exp))
> +   continue;
> 
> Can you please move this test the lowj = assignment, and remove the
> ranges[j].exp == NULL_TREE test (both here and in the earlier loop)?  I
mean,
> we've checked at the beginning of for (i = first; i < length; i++) loop
that
> ranges[i].exp is not NULL_TREE, and if ranges[j].exp is NULL_TREE, it will
be
> different than ranges[i].exp.
> So
>   if (ranges[i].exp != ranges[j].exp || ranges[j].in_p)
> continue;
> (and please also collapse the two checks in the first loop, so that both
look
> similar).
> 
> + /* Check lowj > highi.  */
> + tem1 = fold_binary (GT_EXPR, boolean_type_node,
> +lowj, highi);
> + if (tem1 == NULL_TREE || !integer_onep (tem1))
> +   continue;
> + /* Check highi - lowi == highj - lowj.  */
> + tem1 = fold_binary (MINUS_EXPR, type, highi, lowi);
> + if (tem1 == NULL_TREE || TREE_CODE (tem1) != INTEGER_CST)
> +   continue;
> + tem2 = fold_binary (MINUS_EXPR, type, highj, lowj);
> + if (tem2 == NULL_TREE || TREE_CODE (tem2) != INTEGER_CST)
> +   continue;
> + if (!tree_int_cst_equal (tem1, tem2))
> +   continue;
> + /* Check popcount (lowj - lowi) == 1.  */
> + tem1 = fold_binary (MINUS_EXPR, type, lowj, lowi);
> + if (tem1 == NULL_TREE || TREE_CODE (tem1) != INTEGER_CST)
> +   continue;
> + if (tree_log2 (tem1) < 0)
> +   continue;
> + mask = fold_build1 (BIT_NOT_EXPR, type, tem1);
> + tem1 = fold_binary (MINUS_EXPR, type, ranges[i].exp, lowi);
> + tem1 = fold_build2 (BIT_AND_EXPR, type, tem1, mask);
> + lowi = build_int_cst (type, 0);
> 
> Please use lowj instead of lowi here.  Because, if update_range_test
fails, we
> continue looking for further matches in following ranges, and while lowj
will
> be computed again, lowi will be assumed to contain the low bound of the
> first range

RFA: Switch on LRA on ARM (AArch32)

[Yvan Roux]

Hi,

The status of LRA support for AArch32 is the sequel :
- there is some regressions in the testsuite (gcc/g++, libstdc++ and
fortran) in ARM mode, all due to the same neon legitimate address
issue (tested in hard and softfp mode).
- the compiler doesn't bootstrap with LRA enable for thumb (during
libgcc build).

As stage 1 will be close soon, my first question is can we add the
code to enable LRA before its ending, and fix the issues during stage
2 (according to Vladimir the legitimate address issue is mainly an LRA
bugfix). The attached patch enables LRA by default but disable it for
Thumb and let the opportunity to force LRA with -mlra, but maybe we
can just turn it off by default.

I need your help for the Thumb issue, as suggested by Vladimir I
disabled secondary reload for thumb (with the attached arm.h.diff
patch) to let LRA deal with it and break a cycle, but I now face an
issue exhibited by the attached testcase (thumb-lra.i) and the command
line:

cc1 -O2 -mthumb -mlra thumb-lra.i

Here LRA as to deal with the thumb1_movhi_insn :

(insn 11 5 14 2 (set (reg:HI 0 r0)
(const_int -1318 [0xfada])) /work/tmp/t2.i:14 206
{*thumb1_movhi_insn}
 (nil))

and creates new regs to do it :

 11: r0:HI=r114:HI
Inserting insn reload before:
 18: r115:SI=0xfada
 19: r114:HI=r115:SI#0
  REG_EQUAL 0xfada

 Choosing alt 6 in insn 18:  (0) l  (1) mi {*thumb1_movsi_insn}
 Creating newreg=116 from oldreg=115, assigning class LO_REGS to r116

 18: r116:SI=0xfada
Inserting insn reload after:
 20: r115:SI=r116:SI

Creating newreg=117, assigning class LO_REGS to scratch r117

and during this mov processing, we call gen_thumb_movhi_clobber which
ICE because the first rtx parameter is not a strict memory address but
a register, and here I'm not sure of what to do between fixing this in
the backend or in LRA, and how to do it.

Thanks,
Yvan


arm-lra.diff
Description: Binary data


arm.h.diff
Description: Binary data


thumb-lra.i
Description: Binary data

[committed] Shut up false positive warning in libgomp/env.c

[Jakub Jelinek]

Hi!

At -Og reportedly we get a false positive warning; this isn't performance
sensitive code, so initializing it doesn't hurt.

2013-10-14  Jakub Jelinek  

* env.c (parse_bind_var): Initialize value to avoid
(false positive) warning.

--- libgomp/env.c.jj2013-10-12 00:10:02.0 +0200
+++ libgomp/env.c   2013-10-14 10:23:44.753793069 +0200
@@ -309,7 +309,7 @@ parse_bind_var (const char *name, char *
char **pvalues, unsigned long *pnvalues)
 {
   char *env;
-  char value, *values = NULL;
+  char value = omp_proc_bind_false, *values = NULL;
   int i;
   static struct proc_bind_kinds
   {

Jakub

Re: [ARM] Fix register r3 wrongly used to save ip in nested APCS frame

[Eric Botcazou]

> > 2013-09-05  Eric Botcazou  
> > 
> > * config/arm/arm.c (arm_expand_prologue): In a nested APCS frame with
> > arguments to push onto the stack and no varargs, save ip into a stack
> > slot if r3 isn't available on entry.
> 
> This is all fragile code, so a testcase would be very much appreciated.

I have attached a reduced Ada testcase, compile it for arm-wrs-vxworks and 
you'll see at the beginning of p__f$1593:

.type   p__f$1593, %function
p__f$1593:
@ Nested: function declared inside another function.
@ args = 16, pretend = 4, frame = 140
@ frame_needed = 1, uses_anonymous_args = 0
sub sp, sp, #4
mov r3, ip
add ip, sp, #4
stmfd   sp!, {r4, r5, r6, r7, r8, r9, r10, fp, ip, lr, pc}
sub fp, ip, #8
mov ip, r3
@ ip needed
sub sp, sp, #140
str r0, [fp, #-64]
str r1, [fp, #-72]
str r2, [fp, #-68]
str r3, [fp, #4]

so r3 is live on function's entry but gets clobbered by the ip save.  With the 
patch, the assembly code reads:

p__f$1593:
@ Nested: function declared inside another function.
@ args = 16, pretend = 4, frame = 140
@ frame_needed = 1, uses_anonymous_args = 0
sub sp, sp, #4
str ip, [sp]
add ip, sp, #4
stmfd   sp!, {r4, r5, r6, r7, r8, r9, r10, fp, ip, lr, pc}
sub fp, ip, #8
ldr ip, [fp, #4]
@ ip needed
sub sp, sp, #140
str r0, [fp, #-64]
str r1, [fp, #-72]
str r2, [fp, #-68]
str r3, [fp, #4]

which looks correct.  FWIW we have had the patch in our tree for 4 months now.

-- 
Eric Botcazouprocedure P (I : Integer) is

  SUBTYPE S IS INTEGER RANGE 1..100;
  TYPE ARR IS ARRAY (S RANGE <>) OF INTEGER;

  A : ARR (2..9);

  FUNCTION F (AR_VAR1, AR_VAR2, AR_VAR3 : ARR) RETURN ARR IS
  BEGIN
if I = 0 then
  RETURN AR_VAR1 & AR_VAR2 & AR_VAR3;
else
  RETURN AR_VAR1;
end if;
  END;

begin
  A := (8,7,6,5,4,3,2,1);
  if F(A(2..3), A(2..4), A(2..4)) /= (8,7,8,7,6,8,7,6) then
raise Program_Error;
  end if;
end;

Re: [PATCH] Reassociate X == CST1 || X == CST2 if popcount (CST2 - CST1) == 1 into ((X - CST1) & ~(CST2 - CST1)) == 0

[Jakub Jelinek]

On Mon, Oct 14, 2013 at 03:10:12PM +0800, Zhenqiang Chen wrote:

@@ -2131,6 +2133,155 @@ update_range_test (struct range_entry *range, struct 
range_entry *otherrange,
   return true;
 }
 
+/* Optimize X == CST1 || X == CST2
+   if popcount (CST1 ^ CST2) == 1 into
+   (X & ~(CST1 ^ CST2)) == (CST1 & ~(CST1 ^ CST2)).
+   Similarly for ranges.  E.g.
+   X != 2 && X != 3 && X != 10 && X != 11
+   will be transformed by the previous optimization into
+   (X - 2U) <= 1U && (X - 10U) <= 1U
+   and this loop can transform that into
+   ((X & ~8) - 2U) <= 1U.  */
+
+static bool
+try_transfer_range_tests_1 (enum tree_code opcode, int i, int j, tree type,
+   tree lowi, tree lowj, tree highi, tree highj,
+   vec *ops,
+   struct range_entry *ranges)

The function names are bad, you aren't transfering anything, but optimizing.
Please rename try_transfer_range_tests to optimize_range_tests_1 and
try_transfer_range_tests_{1,2} to optimize_range_tests_{2,3} or perhaps
better yet to optimize_range_tests_{xor,diff}.

Also, perhaps instead of passing ranges and i and j to these two functions
you could pass struct range_entry *range1, struct range_entry *range2
(caller would pass ranges + i, ranges + j).

+/* It does some common checks for function try_transfer_range_tests_1 and
+   try_transfer_range_tests_2.

Please adjust the comment for the renaming.  Please change trans_option
to bool optimize_xor.

+ if (trans_option == 1)
+   {
+ if (try_transfer_range_tests_1 (opcode, i, j, type, lowi, lowj,
+ highi, highj, ops, ranges))
+   {
+ any_changes = true;
+ break;
+   }
+   }
+ else if (trans_option == 2)
+   {
+ if (try_transfer_range_tests_2 (opcode, i, j, type, lowi, lowj,
+ highi, highj, ops, ranges))
+   {
+ any_changes = true;
+ break;
+   }
+   }

I'd prefer
if (optimize_xor)
  any_changes
= optimize_range_tests_xor (opcode, type, lowi, lowj, highi,
highj, ops, ranges + i, ranges + j);
else
  any_changes
= optimize_range_tests_xor (opcode, type, lowi, lowj, highi,
highj, ops, ranges + i, ranges + j);
if (any_changes)
  break;

Ok with those changes.

Jakub

Re: [PATCH, PR 53001] Re: Patch to split out new warning flag for floating point conversion

[Dodji Seketeli]

Thank you Joshua for following up on this.  Please find below some
comments of mine that mostly belong to the nitpicking department.

Joshua J Cogliati  writes:

[...]

> A split out patch to make the floating conversions explicit is attached
> at the PR 53001 page, but is not included in this patch.

It'd be nice to sent that split out patch here too, as it's a
pre-requisite for this to pass bootstrap w/o warning.  Otherwise I am
afraid that patch isn't likely to get reviewed.

[...]

> == Testcases ==
>
> This patch has passes the existing -Wconversion testcases.  It modifies
> Wconversion-real.c, Wconversion-real-integer.c and pr35635.c to be more
> specific

If the patch passes existing tests, I'd be inclined to leave them
tests alone and add new ones that are specific to what this patch
changes.  You can even start from a copy of the tests you've modified
above and trim them down so that only exercise the new code paths
you've added; and of course add more cases top of these, if you can.
But I won't fight hard for this if the other maintainers think it's OK
this way.  :-)

[...]

> == Changelog ==

[...]

> * gcc/c-family/c-common.c Switching unsafe_conversion_p to
> return an enumeration with more detail, and conversion_warning
> to use this information.

The correct format for this ChangeLog entry would be:

* gcc/c-family/c-common.c (unsafe_conversion_p): 
.

Please modify the rest of the ChangeLog entries to comply with this.
Sorry if this seems nit-picky but I guess we need to keep all the
ChangeLog entries coherent.

[...]

> +++ gcc/c-family/c-common.c   (working copy)
> @@ -2517,10 +2517,10 @@ shorten_binary_op (tree result_type, tre
> Function allows conversions between types of different signedness and
> does not return true in that case.  Function can produce signedness
> warnings if PRODUCE_WARNS is true.  */
> -bool
> +enum conversion_safety
>  unsafe_conversion_p (tree type, tree expr, bool produce_warns)
>  {

As you are modifying the return type of this function, I think you
should update the comment of the function too, especially the part
that talks about the return values.

[...]

> @@ -2689,8 +2689,9 @@ conversion_warning (tree type, tree expr
>  {
>tree expr_type = TREE_TYPE (expr);
>location_t loc = EXPR_LOC_OR_HERE (expr);
> +  enum conversion_safety conversion_kind;
>  
> -  if (!warn_conversion && !warn_sign_conversion)
> +  if (!warn_conversion && !warn_sign_conversion && !warn_float_conversion)
>  return;
>  
>switch (TREE_CODE (expr))
> @@ -2717,10 +2718,19 @@ conversion_warning (tree type, tree expr
>  
>  case REAL_CST:
>  case INTEGER_CST:
> -  if (unsafe_conversion_p (type, expr, true))
> - warning_at (loc, OPT_Wconversion,
> - "conversion to %qT alters %qT constant value",
> - type, expr_type);
> +  conversion_kind = unsafe_conversion_p (type, expr, true);
> +  if(conversion_kind == UNSAFE_REAL) 
> + {
> +   warning_at (loc, OPT_Wfloat_conversion,
> +   "conversion to %qT alters %qT constant value",
> +   type, expr_type);
> + } 

You don't need the curly brackets here, so please move them.

> +  else if(conversion_kind)
> + {
> +   warning_at (loc, OPT_Wconversion,
> +   "conversion to %qT alters %qT constant value",
> +   type, expr_type);
> + }

Likewise.

[...]

>return;
>  
>  case COND_EXPR:
> @@ -2736,10 +2746,19 @@ conversion_warning (tree type, tree expr
>}
>  
>  default: /* 'expr' is not a constant.  */
> -  if (unsafe_conversion_p (type, expr, true))
> - warning_at (loc, OPT_Wconversion,
> - "conversion to %qT from %qT may alter its value",
> - type, expr_type);
> +  conversion_kind = unsafe_conversion_p (type, expr, true);
> +  if(conversion_kind == UNSAFE_REAL)
> + {
> +   warning_at (loc, OPT_Wfloat_conversion,
> +   "conversion to %qT from %qT may alter its value",
> +   type, expr_type);
> + } 

Likewise.

> +  else if(conversion_kind)
> + {
> +   warning_at (loc, OPT_Wconversion,
> +   "conversion to %qT from %qT may alter its value",
> +   type, expr_type);
> + }

Likewise.

[...]


> +++ gcc/c-family/c-common.h   (working copy)

[...]


> +/* These variables are possible types of unsafe conversions. 

I would say "These enumerators", rather than "These variables".

> +   SAFE_CONVERSION The conversion is safe
> +   UNSAFE_OTHER Another type of conversion with problems
> +   UNSAFE_SIGN Conversion between signed and unsigned integers 
> +which are all warned about immediately, so this is unused
> +   UNSAFE_REAL Conversions that reduce the precision of reals 
> +including conversions from reals to integers
> + */
> +enum conversion_safety { SAFE_CONVERSION = 0, UNSAFE_OTHER, UNSAFE_SIG

[PING] [PATCH v3] Caller instrumentation with -finstrument-calls

[Woegerer, Paul]

Ping,

The updated patch that I have sent here:
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01263.html
is still pending review/acceptance.

Jan, can you review/commit it for me?

Many Thanks,
Paul

-- 
Paul Woegerer, SW Development Engineer
Sourcery Analyzer 
Mentor Graphics, Embedded Software Division

[PATCH] Add testcase for PR58696

[Richard Biener]

Tested on x86_64-unknown-linux-gnu, applied.

Richard.

2013-10-14  Richard Biener  

PR tree-optimization/58640
* gcc.c-torture/execute/pr58640-2.c: New testcase.

Index: gcc/testsuite/gcc.c-torture/execute/pr58640-2.c
===
--- gcc/testsuite/gcc.c-torture/execute/pr58640-2.c (revision 0)
+++ gcc/testsuite/gcc.c-torture/execute/pr58640-2.c (working copy)
@@ -0,0 +1,35 @@
+extern void abort (void);
+
+int a[20], b, c; 
+
+int
+fn1 ()
+{
+  int d, e, f, g = 0; 
+
+  a[12] = 1;
+  for (e = 0; e < 3; e++)
+for (d = 0; d < 2; d++)
+  {
+   for (f = 0; f < 2; f++)
+ {
+   g ^= a[12] > 1;
+   if (g)
+ return 0;
+   if (b)
+ break;
+ }
+   for (c = 0; c < 1; c++)
+ a[d] = a[e * 3 + 9]; 
+  }
+  return 0;
+}
+
+int
+main ()
+{
+  fn1 ();
+  if (a[0] != 0)
+abort ();
+  return 0;
+}

[PATCH] Fix parts of PR58712 / PR55358

[Richard Biener]

This fixes an error in iterative_hash_canonical_type which can
end up writing into the wrong hashtable slot (as it recurses
and thus the hashtable can get re-allocated and re-hashed).

LTO bootstrapped on x86_64-unknown-linux-gnu, applied to trunk.

Probably should be backported as a bogus canonical type can
result in wrong-code generation with LTO.  I'll try to remember
to do that after 4.8.2 is out.

Richard.

2013-10-14  Richard Biener  

PR middle-end/58712
PR middle-end/55358
* gimple.c (iterative_hash_canonical_type): Make sure to
record the hash into the correct hashtable slot.

Index: gcc/gimple.c
===
--- gcc/gimple.c(revision 203409)
+++ gcc/gimple.c(working copy)
@@ -3112,8 +3112,7 @@ iterative_hash_canonical_type (tree type
   struct tree_int_map *mp, m;
 
   m.base.from = type;
-  if ((slot = htab_find_slot (canonical_type_hash_cache, &m, INSERT))
-  && *slot)
+  if ((slot = htab_find_slot (canonical_type_hash_cache, &m, NO_INSERT)))
 return iterative_hash_hashval_t (((struct tree_int_map *) *slot)->to, val);
 
   /* Combine a few common features of types so that types are grouped into
@@ -3217,6 +3216,10 @@ iterative_hash_canonical_type (tree type
   mp = ggc_alloc_cleared_tree_int_map ();
   mp->base.from = type;
   mp->to = v;
+  /* As we recurse the hashtable may expand between looking up the
+ cached value (and not finding one) and here, so we have to
+ re-lookup the slot.  */
+  slot = htab_find_slot (canonical_type_hash_cache, &m, INSERT);
   *slot = (void *) mp;
 
   return iterative_hash_hashval_t (v, val);

Re: [PATCH] Fix parts of PR58712 / PR55358

[Jakub Jelinek]

On Mon, Oct 14, 2013 at 11:23:55AM +0200, Richard Biener wrote:
> --- gcc/gimple.c  (revision 203409)
> +++ gcc/gimple.c  (working copy)
> @@ -3112,8 +3112,7 @@ iterative_hash_canonical_type (tree type
>struct tree_int_map *mp, m;
>  
>m.base.from = type;
> -  if ((slot = htab_find_slot (canonical_type_hash_cache, &m, INSERT))
> -  && *slot)
> +  if ((slot = htab_find_slot (canonical_type_hash_cache, &m, NO_INSERT)))
>  return iterative_hash_hashval_t (((struct tree_int_map *) *slot)->to, 
> val);

Why don't you use htab_find instead of htab_find_slot then?
>  
>/* Combine a few common features of types so that types are grouped into
> @@ -3217,6 +3216,10 @@ iterative_hash_canonical_type (tree type
>mp = ggc_alloc_cleared_tree_int_map ();
>mp->base.from = type;
>mp->to = v;
> +  /* As we recurse the hashtable may expand between looking up the
> + cached value (and not finding one) and here, so we have to
> + re-lookup the slot.  */
> +  slot = htab_find_slot (canonical_type_hash_cache, &m, INSERT);
>*slot = (void *) mp;
>  
>return iterative_hash_hashval_t (v, val);

Jakub

[PATCH] Fix comment in tree-prof.exp

[Paulo Matos]

Hi,

Here's a patch to fix a comment in tree-prof.exp. OK to apply?

2013-10-14  Paulo Matos  

* testsuite/gcc.dg/tree-prof/tree-prof.exp: Fix comment.

-- 

Paulo Matos




tree-prof_comment.patch
Description: tree-prof_comment.patch

RE: [PATCH] Fix comment in tree-prof.exp

[Paulo Matos]

> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On
> Behalf Of Paulo Matos
> Sent: 14 October 2013 10:31
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH] Fix comment in tree-prof.exp
> 
> Hi,
> 
> Here's a patch to fix a comment in tree-prof.exp. OK to apply?
> 
> 2013-10-14  Paulo Matos  
> 
>   * testsuite/gcc.dg/tree-prof/tree-prof.exp: Fix comment.

Just noticed a patch by Richard where his changelog didn't include the 
testsuite/ bit so it should be:

2013-10-14  Paulo Matos  

* gcc.dg/tree-prof/tree-prof.exp: Fix comment.

-- 
Paulo Matos

Re: [PATCH] FIx pr58640

[Richard Biener]

On Fri, Oct 11, 2013 at 10:31 PM, Jeff Law  wrote:
>
> The problem shown by pr58640 is the more aggressive jump threading is
> recording a jump threading opportunity that crosses through two loop
> headers.
>
> The updating code is not prepared to update the CFG and loop structures in
> that situation.  The net result is we have two latch edges for a particular
> loop.

The "proper" fix for this is to clear loop->latch (a NULL latch means that
we have multiple latches) and make sure that
LOOPS_MAY_HAVE_MULTIPLE_LATCHES is set.

It may also be that we disambiguate the multiple latches later but in
a way that makes associated loop information (like maximum number
of iterations) incorrect (for example if your threading "merges" two loops
and then disambiguation creates loops effectively swapped, attaching
the associated loop info to the wrong one).

>  This causes the full unrolling code to go a bit nuts with a
> particular block is considered unreachable and has no outgoing edges.  It is
> (of course) reachable and falling off the end of the block results in bad
> things happening.
>
> The easiest fix would be to simply cancel the jump threading request
> entirely.  However, we can do better by merely truncating the request
> immediately prior to crossing the second loop entry point.
>
> In fact, the code we generate for pr58640 is considerably better when we
> truncate the path rather than eliminating the jump threading request
> entirely.
>
> Bootstrapped and regression tested on x86_64-unknown-linux-gnu. Installed
> onto the trunk.
>
>
> commit 7aec1a83e5c18ddb0f053b28f62a1c242ab9e477
> Author: Jeff Law 
> Date:   Fri Oct 11 14:24:11 2013 -0600
>
> PR tree-optimization/58640
> * tree-ssa-threadupdate.c (mark_threaded_blocks): Truncate jump
> threading
> paths that cross over two loop entry points.
>
> * gcc.c-torture/execute/pr58640.c: New test.
>
> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> index 41e29dc..9f4e297 100644
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1,3 +1,9 @@
> +2013-10-11  Jeff Law  
> +
> +   PR tree-optimization/58640
> +   * tree-ssa-threadupdate.c (mark_threaded_blocks): Truncate jump
> threading
> +   paths that cross over two loop entry points.
> +
>  2013-10-11  Bill Schmidt  
>
> * config/rs6000/vsx.md (*vsx_le_perm_load_v2di): Generalize to
> diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
> index 87ff2a7..bb2ede4 100644
> --- a/gcc/testsuite/ChangeLog
> +++ b/gcc/testsuite/ChangeLog
> @@ -1,3 +1,7 @@
> +2013-10-11  Jeff Law  
> +
> +   * gcc.c-torture/execute/pr58640.c: New test.
> +
>  2013-10-11  Paolo Carlini  
>
> PR c++/58633
> diff --git a/gcc/testsuite/gcc.c-torture/execute/pr58640.c
> b/gcc/testsuite/gcc.c-torture/execute/pr58640.c
> new file mode 100644
> index 000..7786b8d
> --- /dev/null
> +++ b/gcc/testsuite/gcc.c-torture/execute/pr58640.c
> @@ -0,0 +1,32 @@
> +int a, b, c, d = 1, e;
> +
> +static signed char
> +foo ()
> +{
> +  int f, g = a;
> +
> +  for (f = 1; f < 3; f++)
> +for (; b < 1; b++)
> +  {
> +if (d)
> +  for (c = 0; c < 4; c++)
> +for (f = 0; f < 3; f++)
> +  {
> +for (e = 0; e < 1; e++)
> +  a = g;
> +if (f)
> +  break;
> +  }
> +else if (f)
> +  continue;
> +return 0;
> +  }
> +  return 0;
> +}
> +
> +int
> +main ()
> +{
> +  foo ();
> +  exit (0);
> +}
> diff --git a/gcc/tree-ssa-threadupdate.c b/gcc/tree-ssa-threadupdate.c
> index 2adea1b..3e34567 100644
> --- a/gcc/tree-ssa-threadupdate.c
> +++ b/gcc/tree-ssa-threadupdate.c
> @@ -1354,6 +1354,68 @@ mark_threaded_blocks (bitmap threaded_blocks)
>else
>  bitmap_copy (threaded_blocks, tmp);
>
> +  /* Look for jump threading paths which cross multiple loop headers.
> +
> + The code to thread through loop headers will change the CFG in ways
> + that break assumptions made by the loop optimization code.
> +
> + We don't want to blindly cancel the requests.  We can instead do
> better
> + by trimming off the end of the jump thread path.  */
> +  EXECUTE_IF_SET_IN_BITMAP (tmp, 0, i, bi)
> +{
> +  basic_block bb = BASIC_BLOCK (i);
> +  FOR_EACH_EDGE (e, ei, bb->preds)
> +   {
> + if (e->aux)
> +   {
> + vec *path = THREAD_PATH (e);
> +
> + /* Basically we're looking for a situation where we can see
> +3 or more loop structures on a jump threading path.  */
> +
> + struct loop *first_father = (*path)[0]->e->src->loop_father;
> + struct loop *second_father = NULL;
> + for (unsigned int i = 0; i < path->length (); i++)
> +   {
> + /* See if this is a loop father we have not seen before.
> */
> + if ((*path)[i]->e->dest->loop_father != first_father
> + && (*path)[i]->e->dest->loo

Re: RFA: Remove alias usage from libgcc/sync.c

[Richard Biener]

On Fri, Oct 11, 2013 at 3:27 PM, Richard Sandiford
 wrote:
> Richard Biener  writes:
>> On Fri, Oct 11, 2013 at 12:48 PM, Richard Sandiford
>>  wrote:
>>> Richard Biener  writes:
 On Fri, Oct 11, 2013 at 11:43 AM, Richard Sandiford
  wrote:
> Jakub Jelinek  writes:
>> On Fri, Oct 11, 2013 at 10:17:41AM +0200, Richard Biener wrote:
>>> asm(".alias __sync_synchronize sync_synchronize");
>>
>> It is .set, but not everywhere.
>> /* The MIPS assembler has different syntax for .set. We set it to
>>.dummy to trap any errors.  */
>> #undef SET_ASM_OP
>> #define SET_ASM_OP "\t.dummy\t"
>> But perhaps it would require fewer variants than providing inline asm
>> of the __sync_* builtin by hand for all the targets that need it.
>
> Yeah, that's why I prefer the sed approach.  GCC knows how to do exactly
> what we want, and what syntax to use.  We just need to take its output and
> change the function name.
>
> And like Richard says, parsing top-level asms would be fair game,
> especially if GCC and binutils ever were integrated (for libgccjit.so).
> So using top-level asms seems like putting off the inevitable
> (albeit putting it off further than __asm renaming).
>
> Do either of you object to the sed thing?

 Well, ideally there would be a way to not lie about symbol names to GCC.
 That is, have a "native" way of telling GCC what to do here (which is
 as far as I understand to emit the code for the builtin-handled $SYM
 in a function with $SYM - provide the out-of-line copy for a builtin).

 For the __sync functions it's unfortunate that the library function has
 the same 'name' as the builtin and the builtin doesn't have an alternate
 spelling.  So - can't we just add __builtin__sync_... spellings and use

 __sync_synchronize ()
 {
   __builtin_sync_syncronize ();
 }

 ?  (what if __builtin_sync_syncronize expands to a libcall?  if it can't,
 what's the point of the library function?)
>>>
>>> It can't expand to a libcall in nomips16 mode.  It always expands to a
>>> libcall in mips16 mode.  The point is to provide out-of-line nomips16
>>> functions that the mips16 code can call.
>>>
 Why does a simple

 __sync_synchronize ()
 {
   __sync_synchronize ();
 }

 not work?  On x86_64 I get from that:

 __sync_synchronize:
 .LFB0:
 .cfi_startproc
 mfence
 ret
 .cfi_endproc

 (similar to how you can have a definition of memcpy () and have
 another memcpy inside it inline-expanded)
>>>
>>> Is that with optimisation enabled?  -O2 gives me:
>>>
>>> __sync_synchronize:
>>> .LFB0:
>>> .cfi_startproc
>>> .p2align 4,,10
>>> .p2align 3
>>> .L2:
>>> jmp .L2
>>> .cfi_endproc
>>> .LFE0:
>>>
>>> We do want to compile this stuff with optimisation enabled.
>>
>> I compiled with -O1 only.  Yes, at -O2 I get the infinite loop.
>>
>> Eventually we should simply not build cgraph edges _from_ calls
>> to builtins?  Or disable tail recursion for builtin calls (tail-recursion
>> is what does this optimization).
>>
>> Honza?  For tailr this boils down to symtab_semantically_equivalent_p ().
>> I suppose we don't want to change that but eventually special case
>> builtins in tailr, thus
>>
>> Index: gcc/tree-tailcall.c
>> ===
>> --- gcc/tree-tailcall.c (revision 203409)
>> +++ gcc/tree-tailcall.c (working copy)
>> @@ -446,7 +446,9 @@ find_tail_calls (basic_block bb, struct
>>/* We found the call, check whether it is suitable.  */
>>tail_recursion = false;
>>func = gimple_call_fndecl (call);
>> -  if (func && recursive_call_p (current_function_decl, func))
>> +  if (func
>> +  && ! DECL_BUILT_IN (func)
>> +  && recursive_call_p (current_function_decl, func))
>>  {
>>tree arg;
>>
>> which makes -O2 not turn it into an infinite loop (possibly also applies
>> to the original code with the alias declaration?)
>
> If that's OK then I'm certainly happy with it :-)

I'm happy with the tailcall change (if you can do the testing ... ;))

>  FWIW, the alias case
> was first optimised from __sync_synchronize->sync_synchronize, before it
> got converted into a tail call.  That happened very early in the pipeline
> and I suppose would stop the built-in expansion from kicking in,
> even with tail calls disabled.  But if we say that:
>
> foo () { foo (); }
>
> is a supported way of defining out-of-line versions of built-in foo,
> then that's much more convenient than the aliases anyway.

Btw, if it is supported then we should add a testcase that makes sure
we don't regress for this.  (I wouldn't say we should document this
"feature" just in case we want to decide it's not the way we want it
in the future).

Richard.

Re: [PATCH] Transaction fix: New target hook special_function_flags

[Richard Biener]

On Fri, Oct 11, 2013 at 7:02 PM, Andreas Krebbel
 wrote:
> Hi,
>
> the attached patch introduces a new target hook
> (targetm.calls.special_function_flags) which can be used by a backend
> to add specific call properties to builtins.
>
> On S/390 this is used for the *tbegin* and *tabort builtins whose
> control flow otherwise is not modelled correctly.
>
> On S/390 this leads to problems since our TX intructions do not save
> and restore the floating point registers.  On RTL level we deal with
> this by adding FPR clobbers to the tbegin instruction pattern.
> However, there are several optimizations taking place on tree level
> which need to know about the special characteristics of tbegin as
> well.
>
> So e.g. constant copy propagation misoptimizes the following example
> by propagating f = 77.0f into the f != 88.0f comparison:
>
> int foo ()
> {
>   float f = 77.0f;
>   if (__builtin_tbegin (0) == 0)
> {
>   f = 88.0f;
>   __builtin_tabort (256);
>   return 2;
> }
>   if (f != 88.0f)
> return 3;
>   return 4;
> }
>
> Fixed with the attached patch.
>
> Another side effect of the patch is that the "return 2" statement is
> now optimized away due to __builtin_tabort being "noreturn".
>
> Bootstrapped and regtested on s390 and s390x with --with-arch=zEC12.
>
> htm-nofloat-2.c fails with that patch.  The returns-twice flag on
> tbegin prevents several optimizations on the cfg and basically
> disables the TX optimization in s390_optimize_nonescaping_tx that way.
> I'll try to address this with a follow-on patch.
>
> Ok for mainline and 4.8?

I don't see what's special about s390 so that the attributes are only
required there.  In fact they look valid generally, so no need for the
new target hook.

Richard.

> Bye,
>
> -Andreas-
>
>
> 2013-10-11  Andreas Krebbel  
>
> * calls.c (special_function_p): Call
> targetm.calls.special_function_flags.
> * target.def (special_function_flags): Add new target hook.
> * targhooks.c (default_get_reg_raw_mode): New function.
> * targhooks.h (default_get_reg_raw_mode): Add prototype.
> * doc/tm.texi.in: Add doc placeholder.
> * doc/tm.texi: Update.
>
> * config/s390/s390.c (s390_special_function_flags): Implement the
> new target hook for S/390.
> (TARGET_SPECIAL_FUNCTION_FLAGS): Define new target hook for S/390.
>
>
> 2013-10-11  Andreas Krebbel  
>
> * gcc.target/s390/htm-1.c: Move __builtin_tabort invokations into
> separate functions.
>
>
> ---
>  gcc/calls.c   |3 +
>  gcc/config/s390/s390.c|   24 +++
>  gcc/doc/tm.texi   |4 ++
>  gcc/doc/tm.texi.in|2 +
>  gcc/target.def|   10 ++
>  gcc/targhooks.c   |8 +
>  gcc/targhooks.h   |1
>  gcc/testsuite/gcc.target/s390/htm-1.c |   52 
> ++
>  8 files changed, 92 insertions(+), 12 modifications(!)
>
> Index: gcc/calls.c
> ===
> *** gcc/calls.c.orig
> --- gcc/calls.c
> *** special_function_p (const_tree fndecl, i
> *** 562,567 
> --- 562,570 
> else if (tname[0] == 'l' && tname[1] == 'o'
>&& ! strcmp (tname, "longjmp"))
> flags |= ECF_NORETURN;
> +
> +   /* Apply target specific flags.  */
> +   flags |= targetm.calls.special_function_flags (name);
>   }
>
> return flags;
> Index: gcc/config/s390/s390.c
> ===
> *** gcc/config/s390/s390.c.orig
> --- gcc/config/s390/s390.c
> *** s390_expand_builtin (tree exp, rtx targe
> *** 10065,10070 
> --- 10065,10091 
>   return const0_rtx;
>   }
>
> + /* Return call flags to be added for target specific functions.  */
> +
> + static int
> + s390_special_function_flags (const char *name)
> + {
> +   int flags = 0;
> +
> +   if (!TARGET_HTM)
> + return 0;
> +
> +   if (strcmp (name, "__builtin_tbegin") == 0
> +   || strcmp (name, "__builtin_tbegin_nofloat") == 0
> +   || strcmp (name, "__builtin_tbegin_retry") == 0
> +   || strcmp (name, "__builtin_tbegin_retry_nofloat") == 0)
> + flags |= ECF_RETURNS_TWICE;
> +
> +   if (strcmp (name, "__builtin_tabort") == 0)
> + flags |= ECF_NORETURN;
> +
> +   return flags;
> + }
>
>   /* Output assembly code for the trampoline template to
>  stdio stream FILE.
> *** s390_loop_unroll_adjust (unsigned nunrol
> *** 11833,11838 
> --- 11854,11862 
>   #undef TARGET_LIBCALL_VALUE
>   #define TARGET_LIBCALL_VALUE s390_libcall_value
>
> + #undef TARGET_SPECIAL_FUNCTION_FLAGS
> + #define TARGET_SPECIAL_FUNCTION_FLAGS s390_special_function_flags
> +
>   #undef TARGET_FIXED_CONDITION_CODE_REGS
>   #define TARGET_FIXED_CONDITION_CODE_REGS s390_fixed_condition_code_regs
>
> I

Re: [PATCH] Introduce gcc::dump_manager class

[Richard Biener]

On Sat, Oct 12, 2013 at 3:31 AM, David Malcolm  wrote:
> When repeatedly compiling within one process, the dumpfile numbering
> doesn't reset, leading to dumpfiles after the initial ones having
> unpredictable numbers like here (-fdump-tree-all at -O0):
>
>   fake.c.000i.cgraph
>   fake.c.004t.gimple
>   fake.c.1477t.omplower
>   fake.c.1478t.lower
>   (etc)
>
> Note the large (and increasing) leap in the numbering from the base
> dumpfiles which get consistent numbering (000, 004 here) to the
> autonumbered ones (1477 in this example).  This was due to this implicit
> state within dump_register:
>
>   static int next_dump = FIRST_AUTO_NUMBERED_DUMP;
>   int num = next_dump++;
>
> messing up the numbering on subsequent in-process creation of passes.
>
> This patch introduces a new gcc::dump_manager class to hold such state,
> with a singleton owned by the gcc::context, fixing the inconsistent
> dumpfile numbering.
>
> Specifically, the following variables from dumpfile.c are moved from
> being statically allocated to being fields of gcc::dump_manager (gaining
> "m_" prefixes):
>
>   * next_dump
>   * extra_dump_files
>   * extra_dump_files_in_use
>   * extra_dump_files_alloced
>
> Potentially other aspects of dumping could be moved here, but this
> seemed like a logically self-contained change.
>
> Successfully bootstrapped and regtested on x86_64-unknown-linux.
>
> OK for trunk?

Why can't we have the dump numbering determined at the same time
we build up the pass pipeline?  That is, why are gcc:dump_manager
and gcc:pass_manager separate at all?

That said, the patch is a trivial re-org and thus ok.

Thanks,
Richard.

> (I've already applied this to the "dmalcolm/jit" branch as commits
> 190e9835a3ad4f43abf68aa7e400597d992525be
> 6c1464cdf7c9644383796b0ff5f1756d5279d6cb
> c07d4be4d6e3e732ba36a5ac7b69cce461c44c79)
>
> gcc/
> * dumpfile.h (gcc::dump_manager): New class, to hold state
> relating to dumpfile management.
> (get_dump_file_name): Remove in favor of method of dump_manager.
> (dump_initialized_p): Likewise.
> (dump_start): Likewise.
> (dump_finish): Likewise.
> (dump_switch_p): Likewise.
> (dump_register): Likewise.
> (get_dump_file_info): Likewise.
> * context.c (gcc::context::context): Construct the dump_manager
> instance.
> * context.h (gcc::context::get_dumps): New.
> (gcc::context::m_dumps): New.
> * coverage.c (coverage_init): Port to dump_manager API.
> * dumpfile.c (extra_dump_files): Convert to field of
> gcc::dump_manager.
> (extra_dump_files_in_use): Likewise.
> (extra_dump_files_alloced): Likewise.
> (gcc::dump_manager::dump_manager): New.
> (dump_register): Convert to...
> (gcc::dump_manager::dump_register): ...method, replacing
> function-static next_dump with m_next_dump field.
> (get_dump_file_info): Convert to...
> (gcc::dump_manager::get_dump_file_info): ...method.
> (get_dump_file_name): Convert to...
> (gcc::dump_manager::get_dump_file_name): ...method.
> (dump_start): Convert to...
> (gcc::dump_manager::dump_start): ...method.
> (dump_finish): Convert to...
> (gcc::dump_manager::dump_finish): ...method.
> (dump_begin): Replace body with...
> (gcc::dump_manager::dump_begin): ...new method.
> (dump_phase_enabled_p): Convert to...
> (gcc::dump_manager::dump_phase_enabled_p): ...method.
> (dump_phase_enabled_p): Convert to...
> (gcc::dump_manager::dump_phase_enabled_p): ...method.
> (dump_initialized_p):  Convert to...
> (gcc::dump_manager::dump_initialized_p): ...method.
> (dump_flag_name): Replace body with...
> (gcc::dump_manager::dump_flag_name): ...new method.
> (dump_enable_all): Convert to...
> (gcc::dump_manager::dump_enable_all): ...new method.
> (opt_info_enable_passes): Convert to...
> (gcc::dump_manager::opt_info_enable_passes): ...new method.
> (dump_switch_p_1): Convert to...
> (gcc::dump_manager::dump_switch_p_1): ...new method.
> (dump_switch_p):  Convert to...
> (gcc::dump_manager::dump_switch_p): ...new method.
> (opt_info_switch_p): Port to dump_manager API.
> (enable_rtl_dump_file): Likewise.
> * opts-global.c (handle_common_deferred_options): Port to new
> dump_manager API.
> * passes.c (pass_manager::finish_optimization_passes): Likewise.
> (pass_manager::register_one_dump_file): Likewise.
> (pass_manager::register_pass): Likewise.
> (pass_init_dump_file): Likewise.
> (pass_fini_dump_file): Likewise.
> * statistics.c (statistics_early_init): Likewise.
>
> gcc/java/
> * lang.c (java_handle_option): Update for introduction of
> gcc::dump_manager.

Fix PR bootstrap/58509 (take 2)

[Eric Botcazou]

Hi,

this fixes the ICE during the build of the Ada runtime on the SPARC, a fallout 
of the recent inliner changes:
  http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01033.html

The ICE is triggered because the ldd peephole merges an MEM with MEM_NOTRAP_P 
and a contiguous MEM without MEM_NOTRAP_P, keeping the MEM_NOTRAP_P flag on 
the result.  As a consequence, an EH edge is eliminated and a BB is orphaned.

Fixed by "merging" the flag as well.  Not very elegant, but we already do that 
for similar generic optimizations in the RTL pipeline.

Tested on SPARC/Solaris, applied on the mainline.


2013-10-14  Eric Botcazou  

PR bootstrap/58509
* config/sparc/sparc-protos.h (widen_mem_for_ldd_peep): Declare.
(registers_ok_for_ldd_peep): Move around.
* config/sparc/sparc.c (widen_mem_for_ldd_peep): New.
* config/sparc/sparc.md (widening peepholes): Use it.


2013-10-14  Eric Botcazou  

* gnat.dg/specs/opt1.ads: New test.


-- 
Eric BotcazouIndex: config/sparc/sparc.md
===
--- config/sparc/sparc.md	(revision 203486)
+++ config/sparc/sparc.md	(working copy)
@@ -6971,9 +6971,10 @@ (define_peephole2
   (const_int 0))]
   "TARGET_V9
&& mems_ok_for_ldd_peep (operands[0], operands[1], NULL_RTX)"
-  [(set (match_dup 0)
-   (const_int 0))]
-  "operands[0] = widen_memory_access (operands[0], DImode, 0);")
+  [(set (match_dup 0) (const_int 0))]
+{
+  operands[0] = widen_mem_for_ldd_peep (operands[0], operands[1], DImode);
+})
 
 (define_peephole2
   [(set (match_operand:SI 0 "memory_operand" "")
@@ -6982,9 +6983,10 @@ (define_peephole2
   (const_int 0))]
   "TARGET_V9
&& mems_ok_for_ldd_peep (operands[1], operands[0], NULL_RTX)"
-  [(set (match_dup 1)
-   (const_int 0))]
-  "operands[1] = widen_memory_access (operands[1], DImode, 0);")
+  [(set (match_dup 1) (const_int 0))]
+{
+  operands[1] = widen_mem_for_ldd_peep (operands[1], operands[0], DImode);
+})
 
 (define_peephole2
   [(set (match_operand:SI 0 "register_operand" "")
@@ -6993,10 +6995,11 @@ (define_peephole2
 (match_operand:SI 3 "memory_operand" ""))]
   "registers_ok_for_ldd_peep (operands[0], operands[2]) 
&& mems_ok_for_ldd_peep (operands[1], operands[3], operands[0])" 
-  [(set (match_dup 0)
-	(match_dup 1))]
-  "operands[1] = widen_memory_access (operands[1], DImode, 0);
-   operands[0] = gen_rtx_REG (DImode, REGNO (operands[0]));")
+  [(set (match_dup 0) (match_dup 1))]
+{
+  operands[1] = widen_mem_for_ldd_peep (operands[1], operands[3], DImode);
+  operands[0] = gen_rtx_REG (DImode, REGNO (operands[0]));
+})
 
 (define_peephole2
   [(set (match_operand:SI 0 "memory_operand" "")
@@ -7005,10 +7008,11 @@ (define_peephole2
 (match_operand:SI 3 "register_operand" ""))]
   "registers_ok_for_ldd_peep (operands[1], operands[3]) 
&& mems_ok_for_ldd_peep (operands[0], operands[2], NULL_RTX)"
-  [(set (match_dup 0)
-	(match_dup 1))]
-  "operands[0] = widen_memory_access (operands[0], DImode, 0);
-   operands[1] = gen_rtx_REG (DImode, REGNO (operands[1]));")
+  [(set (match_dup 0) (match_dup 1))]
+{
+  operands[0] = widen_mem_for_ldd_peep (operands[0], operands[2], DImode);
+  operands[1] = gen_rtx_REG (DImode, REGNO (operands[1]));
+})
 
 (define_peephole2
   [(set (match_operand:SF 0 "register_operand" "")
@@ -7017,10 +7021,11 @@ (define_peephole2
 (match_operand:SF 3 "memory_operand" ""))]
   "registers_ok_for_ldd_peep (operands[0], operands[2]) 
&& mems_ok_for_ldd_peep (operands[1], operands[3], operands[0])"
-  [(set (match_dup 0)
-	(match_dup 1))]
-  "operands[1] = widen_memory_access (operands[1], DFmode, 0);
-   operands[0] = gen_rtx_REG (DFmode, REGNO (operands[0]));")
+  [(set (match_dup 0) (match_dup 1))]
+{
+  operands[1] = widen_mem_for_ldd_peep (operands[1], operands[3], DFmode);
+  operands[0] = gen_rtx_REG (DFmode, REGNO (operands[0]));
+})
 
 (define_peephole2
   [(set (match_operand:SF 0 "memory_operand" "")
@@ -7029,10 +7034,11 @@ (define_peephole2
 (match_operand:SF 3 "register_operand" ""))]
   "registers_ok_for_ldd_peep (operands[1], operands[3]) 
   && mems_ok_for_ldd_peep (operands[0], operands[2], NULL_RTX)"
-  [(set (match_dup 0)
-	(match_dup 1))]
-  "operands[0] = widen_memory_access (operands[0], DFmode, 0);
-   operands[1] = gen_rtx_REG (DFmode, REGNO (operands[1]));")
+  [(set (match_dup 0) (match_dup 1))]
+{
+  operands[0] = widen_mem_for_ldd_peep (operands[0], operands[2], DFmode);
+  operands[1] = gen_rtx_REG (DFmode, REGNO (operands[1]));
+})
 
 (define_peephole2
   [(set (match_operand:SI 0 "register_operand" "")
@@ -7041,10 +7047,11 @@ (define_peephole2
 (match_operand:SI 3 "memory_operand" ""))]
   "registers_ok_for_ldd_peep (operands[2], operands[0]) 
   && mems_ok_for_ldd_peep (operands[3], operands[1], operands[0])"
-  [(set (match_dup 2)
-	(match_dup 3))]
-   "operands[3] = widen_memory_access (operands[3], DImode, 0);
-operands[2] = gen_r

Re: [PATCH] Transaction fix: New target hook special_function_flags

[Jakub Jelinek]

On Mon, Oct 14, 2013 at 12:07:00PM +0200, Richard Biener wrote:
> > htm-nofloat-2.c fails with that patch.  The returns-twice flag on
> > tbegin prevents several optimizations on the cfg and basically
> > disables the TX optimization in s390_optimize_nonescaping_tx that way.
> > I'll try to address this with a follow-on patch.
> >
> > Ok for mainline and 4.8?
> 
> I don't see what's special about s390 so that the attributes are only
> required there.  In fact they look valid generally, so no need for the
> new target hook.

Well, the builtins are machine specific.  But, why don't you just
add the attributes to the builtins when you register them in the backend?
You are calling add_builtin_function with NULL_TREE attrs, just pass
the right attribute list and there won't be a need for an extra target hook.

Jakub

RE: [PATCH] Fix PR58682

[Paulo Matos]

> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On
> Behalf Of Paulo Matos
> Sent: 11 October 2013 08:55
> To: Kyrill Tkachov
> Cc: gcc-patches@gcc.gnu.org
> Subject: RE: [PATCH] Fix PR58682
> 
> 
> Thanks, fixed patch attached.
> Working on how to submit a testcase for this given that I need to submit 5
> files + compile with profile-generate + execute + compile with profile-use to
> generate the ICE.
> 
> --
> Paulo Matos

OK, testcase generated. Patch attached but there are a few issues and need some 
comments.

 * The test includes 6 additional sources and 3 headers. This feels like it 
pollutes the test
directory a lot. Should I at least submit preprocessed sources, so that the 
headers disappear?
 * The sources come from CoreMark, does anybody know if their license allows us 
to include this
test in GCC? Also, the code if formatted with CoreMark formatting, should I 
just use indent to 
properly format the patch?
 * Last, but not least, this patch only causes an ICE on 4_8, but not because 
trunk is fixed.
Instead trunk generates edge counts in such a way that they never happen to be 
higher than max_count
when a call is inlined. Is it still worth it to get it into trunk (even though 
trunk should 
still be patched?)


In 4_8:
$ make -j8 RUNTESTFLAGS="tree-prof.exp=core_list_join.c" check-gcc
...
FAIL: gcc.dg/tree-prof/core_list_join.c compilation,  -fprofile-use 
-D_PROFILE_USE (internal compiler error)

=== gcc Summary ===

# of expected passes2
# of unexpected failures1
# of unresolved testcases   1
/projects/firepath_tools1_scratch/pmatos/tmp/GCC/builds/gcc-4_8/gcc/xgcc  
version 4.8.2 20131010 (prerelease) (GCC)

-- 
Paulo Matos

Re: [Patch, Fortran] PR58658 - add missing pointer-assign check for CLASS(*)

[Mikael Morin]

Le 07/10/2013 23:31, Tobias Burnus a écrit :
> The patch is rather obvious. The question is just why was the check
> there at the first place.
> 
> Build and regtested on x86-64-gnu-linux.
> OK for the trunk?
> 
OK. Thanks.

Mikael

[PATCH] Move effective target check after other directives in c-c++-common/cpp/openmp-define-3.c

[Kyrill Tkachov]

Hi all,

This minuscule patch moves the dg-require-effective-target fopenmp line after 
the other directives in the c-c++-common/cpp/openmp-define-3.c test. Otherwise 
dejagnu still proceeds to add -fopenmp to the options which fails on bare metal 
arm and aarch64 targets.


[cc'ing Thomas because he added the test and Jakub because he merged the OpenMP 
support recently]


Ok to commit to trunk?

Thanks,
Kyrilldiff --git a/gcc/testsuite/c-c++-common/cpp/openmp-define-3.c b/gcc/testsuite/c-c++-common/cpp/openmp-define-3.c
index 601a1c3..6986c55 100644
--- a/gcc/testsuite/c-c++-common/cpp/openmp-define-3.c
+++ b/gcc/testsuite/c-c++-common/cpp/openmp-define-3.c
@@ -1,6 +1,6 @@
-/* { dg-require-effective-target fopenmp } */
 /* { dg-options "-fopenmp" } */
 /* { dg-do preprocess } */
+/* { dg-require-effective-target fopenmp } */
 
 #ifndef _OPENMP
 # error _OPENMP not defined

Re: lto-plugin: mismatch between ld's architecture and GCC's configure --host

[Thomas Schwinge]

Hi!

On Sat, 12 Oct 2013 12:20:19 +0200, I wrote:
> This is a bit of a weird scenario -- but it is supposed to work fine in
> my opinion (but doesn't).
> 
> I have a GNU toolchain as 32-bit x86 GNU/Linux executables, configured to
> to generate code for 32-bit x86 by default, and using -m64 for x86_64.
> 
> This toolchain I'm using on a x86_64 system (which can execute 32-bit
> executables) to build a *native* GCC, that is I'm using the 32-bit
> toolchain to build a x86_64 GCC (configuring with CC='gcc -m64' CXX='g++
> -m64').  I intend to continue using the 32-bit toolchain's linker, which
> also is a 32-bit executable (GNU ld).  That one also defaults to x86
> code, but can handle the x86_64 case fine if passed -m elf_x86_64, which
> GCC does.
> 
> That the linker is a 32-bit executable is an implementation detail that
> is not important generally: it's a separate process living in its own
> address space.  However it becomes relevant in the case of linker
> plugins: the native x86_64 GCC that I'm building also builds a x86_64
> lto-plugin, which the 32-bit ld cannot load:
> 
> $ gcc/xgcc -B[...] [...]/gcc.c-torture/execute/ieee/2320-1.c [...] 
> -flto [...]
> [...]/ld: [...]/gcc/liblto_plugin.so: error loading plugin: 
> [...]/gcc/liblto_plugin.so: wrong ELF class: ELFCLASS64
> collect2: error: ld returned 1 exit status
> 
> So, aside from building a 64-bit ld (which is the "lame" alternative), I
> now need to teach GCC's build system that the lto-plugin may need special
> configuration: CC='gcc -m32' -- and possibly its own build of libiberty,
> too, which it may depend on (but doesn't in my case, so I might cut this
> short, and just error out).

The latter was a Saturday morning thinko: only because linking a shared
library succeeds, that doesn't mean all the symbols it depends on are
present.  ;-) So I do need a special libiberty build (or get rid of the
libiberty dependency in lto-plugin, of course, which I have not
assessed).

> Instead of auto-detecting the linker's
> architecture (and then, what to do with that information?), I intend to
> make this a manual process (so, some new top-level configure
> argument(s)).  Adding yet another set of {...,CC,...}_FOR_[something] is
> probably overkill -- I'll try to find something simpler.
> 
> Any comments on this scenario?

Here are the patches.  Unless the new option is exercised, there are no
effects on a native x86_64 GNU/Linux bootstrap build (the build trees'
*.o files are identical, as are the test results).  OK to commit?

Allow overriding the libiberty used for building the LTO plugin.

lto-plugin/
* configure.ac (--with-libiberty): New configure option.
* configure: Regenerate.
* Makefile.am (libiberty, libiberty_pic): New variables.
(liblto_plugin_la_LIBADD, liblto_plugin_la_LDFLAGS)
(liblto_plugin_la_DEPENDENCIES): Use them.
* Makefile.in: Regenerate.
---
 lto-plugin/Makefile.am  | 20 +++-
 lto-plugin/Makefile.in  | 22 --
 lto-plugin/configure| 17 +++--
 lto-plugin/configure.ac |  5 +
 4 files changed, 43 insertions(+), 21 deletions(-)

diff --git lto-plugin/Makefile.am lto-plugin/Makefile.am
index b24015e..8b7bb54 100644
--- lto-plugin/Makefile.am
+++ lto-plugin/Makefile.am
@@ -15,17 +15,19 @@ libexecsub_LTLIBRARIES = liblto_plugin.la
 gcc_build_dir = ../$(host_subdir)/gcc
 in_gcc_libs = $(foreach lib, $(libexecsub_LTLIBRARIES), 
$(gcc_build_dir)/$(lib))
 
-# Can be removed when libiberty becomes a normal convenience library
-Wc=-Wc,
-
 liblto_plugin_la_SOURCES = lto-plugin.c
+# Note that we intentionally override the bindir supplied by ACX_LT_HOST_FLAGS.
+liblto_plugin_la_LDFLAGS = $(lt_host_flags) -module -bindir $(libexecsubdir)
+# Can be simplified when libiberty becomes a normal convenience library.
+libiberty=$(with_libiberty)/libiberty.a
+libiberty_pic=$(with_libiberty)/pic/libiberty.a
+Wc=-Wc,
 liblto_plugin_la_LIBADD = \
-   $(if $(wildcard 
../libiberty/pic/libiberty.a),$(Wc)../libiberty/pic/libiberty.a,)
-# Note that we intentionally override the bindir supplied by ACX_LT_HOST_FLAGS
-liblto_plugin_la_LDFLAGS = $(lt_host_flags) -module -bindir $(libexecsubdir) \
-   $(if $(wildcard 
../libiberty/pic/libiberty.a),,-Wc,../libiberty/libiberty.a)
-liblto_plugin_la_DEPENDENCIES = $(if $(wildcard \
-   ../libiberty/pic/libiberty.a),../libiberty/pic/libiberty.a,)
+   $(if $(wildcard $(libiberty_pic)),$(Wc)$(libiberty_pic),)
+liblto_plugin_la_LDFLAGS += \
+   $(if $(wildcard $(libiberty_pic)),,-Wc,$(libiberty))
+liblto_plugin_la_DEPENDENCIES = \
+   $(if $(wildcard $(libiberty_pic)),$(libiberty_pic),)
 
 all-local: $(in_gcc_libs)
 
diff --git lto-plugin/configure.ac lto-plugin/configure.ac
index 9a418d2..b73fabb 100644
--- lto-plugin/configure.ac
+++ lto-plugin/configure.ac
@@ -4,6 +4,11 @@ AC_CANONICAL_SYSTEM
 GCC_TOPLEV_SUBDIRS
 AM_INIT_AUTOMAKE([foreign no-dist])
 AM_MAINTAINER_MODE
+AC

Re: [PATCH] Fix PR58682

[Kyrill Tkachov]

On 14/10/13 11:23, Paulo Matos wrote:

-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On
Behalf Of Paulo Matos
Sent: 14 October 2013 11:22
To: Kyrill Tkachov
Cc: gcc-patches@gcc.gnu.org
Subject: RE: [PATCH] Fix PR58682


OK, testcase generated. Patch attached but there are a few issues and need
some comments.


I am sorry, I forgot to attach the patch. Here it is.
OK, testcase generated. Patch attached but there are a few issues and need some 
comments.



  * The test includes 6 additional sources and 3 headers. This feels like it 
pollutes the test
directory a lot. Should I at least submit preprocessed sources, so that the 
headers disappear?
  * The sources come from CoreMark, does anybody know if their license allows 
us to include this
test in GCC? Also, the code if formatted with CoreMark formatting, should I 
just use indent to
properly format the patch?
I'd think there would be legal issues adding coremark to the testsuite but I'm 
not an expert on this. In any case, I think it's too big of a testcase. Any way 
we could reduce it?



  * Last, but not least, this patch only causes an ICE on 4_8, but not because 
trunk is fixed.
Instead trunk generates edge counts in such a way that they never happen to be 
higher than max_count
when a call is inlined. Is it still worth it to get it into trunk (even though 
trunk should
still be patched?)

CC'ing one of the testsuite maintainers...

Kyrill

Re: [PATCH] Transaction fix: New target hook special_function_flags

[Andreas Krebbel]

On 14/10/13 12:14, Jakub Jelinek wrote:
> On Mon, Oct 14, 2013 at 12:07:00PM +0200, Richard Biener wrote:
>>> htm-nofloat-2.c fails with that patch.  The returns-twice flag on
>>> tbegin prevents several optimizations on the cfg and basically
>>> disables the TX optimization in s390_optimize_nonescaping_tx that way.
>>> I'll try to address this with a follow-on patch.
>>>
>>> Ok for mainline and 4.8?
>>
>> I don't see what's special about s390 so that the attributes are only
>> required there.  In fact they look valid generally, so no need for the
>> new target hook.
> 
> Well, the builtins are machine specific.  But, why don't you just
> add the attributes to the builtins when you register them in the backend?
> You are calling add_builtin_function with NULL_TREE attrs, just pass
> the right attribute list and there won't be a need for an extra target hook.

I somehow couldn't get it working with the add_builtin_function parameter. 
Perhaps because these
attrs are supposed to be translated into the respective tree flags 
(DECL_IS_RETURNS_TWICE) at that
point already?!

But the following seems to work fine:

---
 gcc/config/s390/s390.c |   39 +!!
 1 file changed, 1 insertion(+), 38 modifications(!)

Index: gcc/config/s390/s390.c
===
*** gcc/config/s390/s390.c.orig
--- gcc/config/s390/s390.c
*** static void
*** 9900,9905 
--- 9900,9906 
  s390_init_builtins (void)
  {
tree ftype, uint64_type;
+   tree decl;

/* void foo (void) */
ftype = build_function_type_list (void_type_node, NULL_TREE);
*** s390_init_builtins (void)
*** 9909,9938 
/* void foo (int) */
ftype = build_function_type_list (void_type_node, integer_type_node,
NULL_TREE);
!   add_builtin_function ("__builtin_tabort", ftype,
!   S390_BUILTIN_TABORT, BUILT_IN_MD, NULL, NULL_TREE);
add_builtin_function ("__builtin_tx_assist", ftype,
S390_BUILTIN_TX_ASSIST, BUILT_IN_MD, NULL, NULL_TREE);

/* int foo (void *) */
ftype = build_function_type_list (integer_type_node, ptr_type_node, 
NULL_TREE);
!   add_builtin_function ("__builtin_tbegin", ftype, S390_BUILTIN_TBEGIN,
!   BUILT_IN_MD, NULL, NULL_TREE);
!   add_builtin_function ("__builtin_tbegin_nofloat", ftype,
!   S390_BUILTIN_TBEGIN_NOFLOAT,
!   BUILT_IN_MD, NULL, NULL_TREE);

/* int foo (void *, int) */
ftype = build_function_type_list (integer_type_node, ptr_type_node,
integer_type_node, NULL_TREE);
!   add_builtin_function ("__builtin_tbegin_retry", ftype,
!   S390_BUILTIN_TBEGIN_RETRY,
!   BUILT_IN_MD,
!   NULL, NULL_TREE);
!   add_builtin_function ("__builtin_tbegin_retry_nofloat", ftype,
!   S390_BUILTIN_TBEGIN_RETRY_NOFLOAT,
!   BUILT_IN_MD,
!   NULL, NULL_TREE);

/* int foo (void) */
ftype = build_function_type_list (integer_type_node, NULL_TREE);
--- 9910,9947 
/* void foo (int) */
ftype = build_function_type_list (void_type_node, integer_type_node,
NULL_TREE);
!   decl = add_builtin_function ("__builtin_tabort", ftype,
!  S390_BUILTIN_TABORT, BUILT_IN_MD, NULL, 
NULL_TREE);
!   set_call_expr_flags (decl, ECF_NORETURN);
!
add_builtin_function ("__builtin_tx_assist", ftype,
S390_BUILTIN_TX_ASSIST, BUILT_IN_MD, NULL, NULL_TREE);

/* int foo (void *) */
ftype = build_function_type_list (integer_type_node, ptr_type_node, 
NULL_TREE);
!   decl = add_builtin_function ("__builtin_tbegin", ftype, S390_BUILTIN_TBEGIN,
!  BUILT_IN_MD, NULL, NULL_TREE);
!   set_call_expr_flags (decl, ECF_RETURNS_TWICE);
!
!   decl = add_builtin_function ("__builtin_tbegin_nofloat", ftype,
!  S390_BUILTIN_TBEGIN_NOFLOAT,
!  BUILT_IN_MD, NULL, NULL_TREE);
!   set_call_expr_flags (decl, ECF_RETURNS_TWICE);

/* int foo (void *, int) */
ftype = build_function_type_list (integer_type_node, ptr_type_node,
integer_type_node, NULL_TREE);
!   decl = add_builtin_function ("__builtin_tbegin_retry", ftype,
!  S390_BUILTIN_TBEGIN_RETRY,
!  BUILT_IN_MD,
!  NULL, NULL_TREE);
!   set_call_expr_flags (decl, ECF_RETURNS_TWICE);
!
!   decl = add_builtin_function ("__builtin_tbegin_retry_nofloat", ftype,
!  S390_BUILTIN_TBEGIN_RETRY_NOFLOAT,
!  BUILT_IN_MD,
!  NULL, NULL_TREE);
!   set_call_expr_flags (decl, ECF_RETURNS_TWICE);

/* int foo (void) */
ftype = bui

RE: [PATCH] Fix PR58682

[Paulo Matos]

> -Original Message-
> From: Kyrill Tkachov [mailto:kyrylo.tkac...@arm.com]
> Sent: 14 October 2013 11:44
> To: Paulo Matos
> Cc: gcc-patches@gcc.gnu.org; mikest...@comcast.net
> Subject: Re: [PATCH] Fix PR58682
> 
> I'd think there would be legal issues adding coremark to the testsuite but
> I'm
> not an expert on this. In any case, I think it's too big of a testcase. Any
> way
> we could reduce it?
> 

I agree it's too big but since it's necessary to compile/execute/compile it's 
very hard 
to reduce it without eliminating the resulting ICE.

I will give it a try though.

-- 
Paulo Mato

Re: [PATCH] Transaction fix: New target hook special_function_flags

[Richard Biener]

On Mon, Oct 14, 2013 at 1:21 PM, Andreas Krebbel
 wrote:
> On 14/10/13 12:14, Jakub Jelinek wrote:
>> On Mon, Oct 14, 2013 at 12:07:00PM +0200, Richard Biener wrote:
 htm-nofloat-2.c fails with that patch.  The returns-twice flag on
 tbegin prevents several optimizations on the cfg and basically
 disables the TX optimization in s390_optimize_nonescaping_tx that way.
 I'll try to address this with a follow-on patch.

 Ok for mainline and 4.8?
>>>
>>> I don't see what's special about s390 so that the attributes are only
>>> required there.  In fact they look valid generally, so no need for the
>>> new target hook.
>>
>> Well, the builtins are machine specific.  But, why don't you just
>> add the attributes to the builtins when you register them in the backend?
>> You are calling add_builtin_function with NULL_TREE attrs, just pass
>> the right attribute list and there won't be a need for an extra target hook.
>
> I somehow couldn't get it working with the add_builtin_function parameter. 
> Perhaps because these
> attrs are supposed to be translated into the respective tree flags 
> (DECL_IS_RETURNS_TWICE) at that
> point already?!

Yes, via handle_..._attribute.

> But the following seems to work fine:

Looks good.

Richard.

> ---
>  gcc/config/s390/s390.c |   39 +!!
>  1 file changed, 1 insertion(+), 38 modifications(!)
>
> Index: gcc/config/s390/s390.c
> ===
> *** gcc/config/s390/s390.c.orig
> --- gcc/config/s390/s390.c
> *** static void
> *** 9900,9905 
> --- 9900,9906 
>   s390_init_builtins (void)
>   {
> tree ftype, uint64_type;
> +   tree decl;
>
> /* void foo (void) */
> ftype = build_function_type_list (void_type_node, NULL_TREE);
> *** s390_init_builtins (void)
> *** 9909,9938 
> /* void foo (int) */
> ftype = build_function_type_list (void_type_node, integer_type_node,
> NULL_TREE);
> !   add_builtin_function ("__builtin_tabort", ftype,
> !   S390_BUILTIN_TABORT, BUILT_IN_MD, NULL, NULL_TREE);
> add_builtin_function ("__builtin_tx_assist", ftype,
> S390_BUILTIN_TX_ASSIST, BUILT_IN_MD, NULL, NULL_TREE);
>
> /* int foo (void *) */
> ftype = build_function_type_list (integer_type_node, ptr_type_node, 
> NULL_TREE);
> !   add_builtin_function ("__builtin_tbegin", ftype, S390_BUILTIN_TBEGIN,
> !   BUILT_IN_MD, NULL, NULL_TREE);
> !   add_builtin_function ("__builtin_tbegin_nofloat", ftype,
> !   S390_BUILTIN_TBEGIN_NOFLOAT,
> !   BUILT_IN_MD, NULL, NULL_TREE);
>
> /* int foo (void *, int) */
> ftype = build_function_type_list (integer_type_node, ptr_type_node,
> integer_type_node, NULL_TREE);
> !   add_builtin_function ("__builtin_tbegin_retry", ftype,
> !   S390_BUILTIN_TBEGIN_RETRY,
> !   BUILT_IN_MD,
> !   NULL, NULL_TREE);
> !   add_builtin_function ("__builtin_tbegin_retry_nofloat", ftype,
> !   S390_BUILTIN_TBEGIN_RETRY_NOFLOAT,
> !   BUILT_IN_MD,
> !   NULL, NULL_TREE);
>
> /* int foo (void) */
> ftype = build_function_type_list (integer_type_node, NULL_TREE);
> --- 9910,9947 
> /* void foo (int) */
> ftype = build_function_type_list (void_type_node, integer_type_node,
> NULL_TREE);
> !   decl = add_builtin_function ("__builtin_tabort", ftype,
> !  S390_BUILTIN_TABORT, BUILT_IN_MD, NULL, 
> NULL_TREE);
> !   set_call_expr_flags (decl, ECF_NORETURN);
> !
> add_builtin_function ("__builtin_tx_assist", ftype,
> S390_BUILTIN_TX_ASSIST, BUILT_IN_MD, NULL, NULL_TREE);
>
> /* int foo (void *) */
> ftype = build_function_type_list (integer_type_node, ptr_type_node, 
> NULL_TREE);
> !   decl = add_builtin_function ("__builtin_tbegin", ftype, 
> S390_BUILTIN_TBEGIN,
> !  BUILT_IN_MD, NULL, NULL_TREE);
> !   set_call_expr_flags (decl, ECF_RETURNS_TWICE);
> !
> !   decl = add_builtin_function ("__builtin_tbegin_nofloat", ftype,
> !  S390_BUILTIN_TBEGIN_NOFLOAT,
> !  BUILT_IN_MD, NULL, NULL_TREE);
> !   set_call_expr_flags (decl, ECF_RETURNS_TWICE);
>
> /* int foo (void *, int) */
> ftype = build_function_type_list (integer_type_node, ptr_type_node,
> integer_type_node, NULL_TREE);
> !   decl = add_builtin_function ("__builtin_tbegin_retry", ftype,
> !  S390_BUILTIN_TBEGIN_RETRY,
> !  BUILT_IN_MD,
> !  NULL, NULL_TREE);
> !   set_call_expr_flags (decl, ECF_RETURNS_TWICE);
> !
> !   decl = add_bu

Re: [PATCH] Transaction fix: New target hook special_function_flags

[Jakub Jelinek]

On Mon, Oct 14, 2013 at 01:26:25PM +0200, Richard Biener wrote:
> > I somehow couldn't get it working with the add_builtin_function parameter. 
> > Perhaps because these
> > attrs are supposed to be translated into the respective tree flags 
> > (DECL_IS_RETURNS_TWICE) at that
> > point already?!
> 
> Yes, via handle_..._attribute.

??  If add_builtin_function last argument is non-NULL, it will call
decl_attributes with that argument and thus should set up evertyhing.
So, IMHO:
  tree noreturn = tree_cons (get_identifier ("noreturn"), NULL, NULL);
  tree returns_twice = tree_cons (get_identifier ("returns_twice"), NULL, NULL);
and passing either of those to add_builtin_function should IMHO work just
fine.

Jakub

Re: libsanitizer merge from upstream r191666

[Konstantin Serebryany]

+dnovillo, davidxl
Any suggestions?

On Wed, Oct 2, 2013 at 12:54 PM, Konstantin Serebryany
 wrote:
> 
>
>
>
> On Wed, Oct 2, 2013 at 12:51 PM, Konstantin Serebryany
>  wrote:
>> Hi,
>>
>> I'd like to start a review for libsanitizer merge from upstream.
>> This is the first full merge since 2013-02-21 and it contains lots of 
>> changes,
>> including two changes in asan API which require a corresponding change
>> in asan.c.
>> The patch to asan.c contains one FIXME which I hope to resolve during
>> the review.
>>
>> The major user-visible change in libsanitizer is the introduction of
>> LeakSanitizer (lsan),
>> a heap leak detector that runs on top of AddressSanitizer.
>> https://code.google.com/p/address-sanitizer/wiki/LeakSanitizer
>>
>> Two more features of AddressSanitizer are supported by this run-time update,
>> but they require corresponding compiler changes which are not
>> implemented yet in asan.c:
>> https://code.google.com/p/address-sanitizer/wiki/UseAfterReturn
>> https://code.google.com/p/address-sanitizer/wiki/InitializationOrderFiasco
>>
>> Other changes include:
>>   - various stability, portability, and performance improvements in
>> AddressSanitizer and ThreadSanitizer, code refactoring.
>>   - Improved native Windows support.
>>   - probably various new bugs too, but the upstream head is heavily
>> tested on Chromium and other large source bases.
>>
>>
>> I tested this change like this on x86_64 Linux Ubuntu 12.04:
>> rm -rf */{*/,}libsanitizer && make -j 50  && make -C gcc
>> check-g{cc,++}  RUNTESTFLAGS='--target_board=unix\{-m32,-m64\}
>> asan.exp'
>>
>> Since the change also pulls minor changes in ubsan, please suggest me
>> how to test that too.
>>
>> Expected ChangeLog entries:
>> === gcc/testsuite/ChangeLog
>>
>> 2013-10-XX  Kostya Serebryany  
>>
>> * g++.dg/asan/asan_test.cc: Update the test
>> to match the fresh asan run-time.
>> * c-c++-common/asan/stack-overflow-1.c: Ditto.
>>
>> === gcc/ChangeLog
>>
>> 2013-10-XX  Kostya Serebryany  
>>
>> * asan.c: Update to match the changed asan API.
>> (asan_emit_stack_protection): update the string stored in the
>> stack red zone to match new API. Store the PC of the current
>> function in the red zone.
>> (asan_global_struct): update the __asan_global definition to match
>> the new API.
>> (asan_add_global): Ditto.
>> * sanitizer.def: rename __asan_init_v1 to __asan_init_v3
>>
>> === libsanitizer/ChangeLog
>>
>> 2013-10-XX  Kostya Serebryany  
>>
>> * All source files: Merge from upstream r191666.
>> * merge.sh: Added lsan.
>> * configure.ac: Added lsan.
>> * Makefile.am: Added lsan.
>> * sanitizer_common/Makefile.am: Added lsan.
>> * asan/Makefile.am: Added dependency on lsan.
>> * lsan/Makefile.am: New file.
>> * asan/Makefile.in: Regenerate.
>> * lsan/Makefile.in: Regenerate.
>> * Makefile.in: Regenerate.
>> * configure: Regenerate.
>> * sanitizer_common/Makefile.in: Regenerate.
>>
>> Patch attached.
>>
>> --kcc

[PATCH] Move LTO canonical type merging code to the LTO frontend

[Richard Biener]

$subject, no other changes (yet).

LTO bootstrapped on x86_64-unknown-linux-gnu, testing in progress.

Richard.

2013-10-14  Richard Biener  

* gimple.c (gimple_canonical_types, canonical_type_hash_cache,
iterative_hash_canonical_type, gimple_canonical_type_hash,
gimple_canonical_types_compatible_p, gimple_canonical_type_eq,
gimple_register_canonical_type, print_gimple_types_stats,
free_gimple_type_tables): Move to lto/lto.c
(gt-gimple.h): Do not include.
* gimple.h (gimple_register_canonical_type,
print_gimple_types_stats, free_gimple_type_tables): Remove.
* Makefile.in (GTFILES): Remove gimple.c.

lto/
* lto-lang.c (lto_init): Do not re-init canonical types here.
(lto_register_canonical_types): Move to ...
* lto.c (lto_register_canonical_types): ... here.
(gimple_canonical_types, canonical_type_hash_cache,
iterative_hash_canonical_type, gimple_canonical_type_hash,
gimple_canonical_types_compatible_p, gimple_canonical_type_eq,
gimple_register_canonical_type): Add canonical type merging machinery
moved from gimple.c.
(read_cgraph_and_symbols): Init and free canonical type tables
here.
(print_lto_report_1): Report canonical type table stats here.

Index: gcc/gimple.c
===
*** gcc/gimple.c(revision 203517)
--- gcc/gimple.c(working copy)
*** along with GCC; see the file COPYING3.
*** 37,47 
  #include "demangle.h"
  #include "langhooks.h"
  
- /* Global canonical type table.  */
- static GTY((if_marked ("ggc_marked_p"), param_is (union tree_node)))
-   htab_t gimple_canonical_types;
- static GTY((if_marked ("tree_int_map_marked_p"), param_is (struct 
tree_int_map)))
-   htab_t canonical_type_hash_cache;
  
  /* All the tuples have their operand vector (if present) at the very bottom
 of the structure.  Therefore, the offset required to find the
--- 37,42 
*** gimple_compare_field_offset (tree f1, tr
*** 3099,3556 
return false;
  }
  
- /* Returning a hash value for gimple type TYPE combined with VAL.
- 
-The hash value returned is equal for types considered compatible
-by gimple_canonical_types_compatible_p.  */
- 
- static hashval_t
- iterative_hash_canonical_type (tree type, hashval_t val)
- {
-   hashval_t v;
-   void **slot;
-   struct tree_int_map *mp, m;
- 
-   m.base.from = type;
-   if ((slot = htab_find_slot (canonical_type_hash_cache, &m, NO_INSERT)))
- return iterative_hash_hashval_t (((struct tree_int_map *) *slot)->to, 
val);
- 
-   /* Combine a few common features of types so that types are grouped into
-  smaller sets; when searching for existing matching types to merge,
-  only existing types having the same features as the new type will be
-  checked.  */
-   v = iterative_hash_hashval_t (TREE_CODE (type), 0);
-   v = iterative_hash_hashval_t (TREE_ADDRESSABLE (type), v);
-   v = iterative_hash_hashval_t (TYPE_ALIGN (type), v);
-   v = iterative_hash_hashval_t (TYPE_MODE (type), v);
- 
-   /* Incorporate common features of numerical types.  */
-   if (INTEGRAL_TYPE_P (type)
-   || SCALAR_FLOAT_TYPE_P (type)
-   || FIXED_POINT_TYPE_P (type)
-   || TREE_CODE (type) == OFFSET_TYPE
-   || POINTER_TYPE_P (type))
- {
-   v = iterative_hash_hashval_t (TYPE_PRECISION (type), v);
-   v = iterative_hash_hashval_t (TYPE_UNSIGNED (type), v);
- }
- 
-   if (VECTOR_TYPE_P (type))
- {
-   v = iterative_hash_hashval_t (TYPE_VECTOR_SUBPARTS (type), v);
-   v = iterative_hash_hashval_t (TYPE_UNSIGNED (type), v);
- }
- 
-   if (TREE_CODE (type) == COMPLEX_TYPE)
- v = iterative_hash_hashval_t (TYPE_UNSIGNED (type), v);
- 
-   /* For pointer and reference types, fold in information about the type
-  pointed to but do not recurse to the pointed-to type.  */
-   if (POINTER_TYPE_P (type))
- {
-   v = iterative_hash_hashval_t (TYPE_REF_CAN_ALIAS_ALL (type), v);
-   v = iterative_hash_hashval_t (TYPE_ADDR_SPACE (TREE_TYPE (type)), v);
-   v = iterative_hash_hashval_t (TYPE_RESTRICT (type), v);
-   v = iterative_hash_hashval_t (TREE_CODE (TREE_TYPE (type)), v);
- }
- 
-   /* For integer types hash only the string flag.  */
-   if (TREE_CODE (type) == INTEGER_TYPE)
- v = iterative_hash_hashval_t (TYPE_STRING_FLAG (type), v);
- 
-   /* For array types hash the domain bounds and the string flag.  */
-   if (TREE_CODE (type) == ARRAY_TYPE && TYPE_DOMAIN (type))
- {
-   v = iterative_hash_hashval_t (TYPE_STRING_FLAG (type), v);
-   /* OMP lowering can introduce error_mark_node in place of
-random local decls in types.  */
-   if (TYPE_MIN_VALUE (TYPE_DOMAIN (type)) != error_mark_node)
-   v = iterative_hash_expr (TYPE_MIN_VALUE (TYPE_DOMAIN (type)), v);
-   if (TYPE_MAX_VALUE (TYPE_DOMAIN (type)) 

Re: libsanitizer merge from upstream r191666

[Marek Polacek]

> >> I tested this change like this on x86_64 Linux Ubuntu 12.04:
> >> rm -rf */{*/,}libsanitizer && make -j 50  && make -C gcc
> >> check-g{cc,++}  RUNTESTFLAGS='--target_board=unix\{-m32,-m64\}
> >> asan.exp'
> >>
> >> Since the change also pulls minor changes in ubsan, please suggest me
> >> how to test that too.

We now have an ubsan testuite; I usually run just
make check -C gcc RUNTESTFLAGS='--target_board=unix\{-m32,-m64\}
ubsan.exp'

Marek

Re: libsanitizer merge from upstream r191666

[Konstantin Serebryany]

Thanks!
(I still need more suggestions/review :)

On Mon, Oct 14, 2013 at 3:48 PM, Marek Polacek  wrote:
>> >> I tested this change like this on x86_64 Linux Ubuntu 12.04:
>> >> rm -rf */{*/,}libsanitizer && make -j 50  && make -C gcc
>> >> check-g{cc,++}  RUNTESTFLAGS='--target_board=unix\{-m32,-m64\}
>> >> asan.exp'
>> >>
>> >> Since the change also pulls minor changes in ubsan, please suggest me
>> >> how to test that too.
>
> We now have an ubsan testuite; I usually run just
> make check -C gcc RUNTESTFLAGS='--target_board=unix\{-m32,-m64\}
> ubsan.exp'
>
> Marek

[PATCH][LTO] Finally remove old merging code

[Richard Biener]

Totally forgot about it - noticed now when moving the canonical
type stuff.  So I do not forget before we release 4.9 the following
removes the old merging code now.  This should speedup
-flto-report[-wpa] quite a bit (and reduce it's memory usage).

LTO bootstrap running on x86_64-unknown-linux-gnu.

Richard.

2013-10-14  Richard Biener  

lto/
* lto.c (gimple_types, type_hash_cache, struct type_pair_d,
type_pair_cache, lookup_type_pair, struct sccs, next_dfs_num,
gtc_next_dfs_num, compare_type_names_p, gtc_visit,
gimple_types_compatible_p_1, gimple_types_compatible_p,
visit, iterative_hash_name, struct type_hash_pair,
type_hash_pair_compare, iterative_hash_gimple_type, gimple_type_hash,
gimple_type_eq, gimple_register_type, num_not_merged_types,
num_not_merged_types_in_same_scc, num_not_merged_types_trees,
num_not_merged_types_in_same_scc_trees): Remove old merging code
and statistics.
(lto_read_decls): Do not run old merging code in parallel.
(read_cgraph_and_symbols): Do not init/free old merging
data structures.
(print_lto_report_1): Do not report differences of old vs. new
merging code.

Index: gcc/lto/lto.c
===
*** gcc/lto/lto.c   (revision 203521)
--- gcc/lto/lto.c   (working copy)
*** lto_register_canonical_types (tree node)
*** 676,1712 
  }
  
  
- /* ???  Old hashing and merging code follows, we keep it for statistics
-purposes for now.  */
- 
- /* Global type table.  FIXME, it should be possible to re-use some
-of the type hashing routines in tree.c (type_hash_canon, type_hash_lookup,
-etc), but those assume that types were built with the various
-build_*_type routines which is not the case with the streamer.  */
- static GTY((if_marked ("ggc_marked_p"), param_is (union tree_node)))
-   htab_t gimple_types;
- static GTY((if_marked ("tree_int_map_marked_p"), param_is (struct 
tree_int_map)))
-   htab_t type_hash_cache;
- 
- static hashval_t gimple_type_hash (const void *);
- 
- /* Structure used to maintain a cache of some type pairs compared by
-gimple_types_compatible_p when comparing aggregate types.  There are
-three possible values for SAME_P:
- 
-   -2: The pair (T1, T2) has just been inserted in the table.
-0: T1 and T2 are different types.
-1: T1 and T2 are the same type.  */
- 
- struct type_pair_d
- {
-   unsigned int uid1;
-   unsigned int uid2;
-   signed char same_p;
- };
- typedef struct type_pair_d *type_pair_t;
- 
- #define GIMPLE_TYPE_PAIR_SIZE 16381
- struct type_pair_d *type_pair_cache;
- 
- 
- /* Lookup the pair of types T1 and T2 in *VISITED_P.  Insert a new
-entry if none existed.  */
- 
- static inline type_pair_t
- lookup_type_pair (tree t1, tree t2)
- {
-   unsigned int index;
-   unsigned int uid1, uid2;
- 
-   if (TYPE_UID (t1) < TYPE_UID (t2))
- {
-   uid1 = TYPE_UID (t1);
-   uid2 = TYPE_UID (t2);
- }
-   else
- {
-   uid1 = TYPE_UID (t2);
-   uid2 = TYPE_UID (t1);
- }
-   gcc_checking_assert (uid1 != uid2);
- 
-   /* iterative_hash_hashval_t imply an function calls.
-  We know that UIDS are in limited range.  */
-   index = unsigned HOST_WIDE_INT)uid1 << HOST_BITS_PER_WIDE_INT / 2) + 
uid2)
-  % GIMPLE_TYPE_PAIR_SIZE);
-   if (type_pair_cache [index].uid1 == uid1
-   && type_pair_cache [index].uid2 == uid2)
- return &type_pair_cache[index];
- 
-   type_pair_cache [index].uid1 = uid1;
-   type_pair_cache [index].uid2 = uid2;
-   type_pair_cache [index].same_p = -2;
- 
-   return &type_pair_cache[index];
- }
- 
- /* Per pointer state for the SCC finding.  The on_sccstack flag
-is not strictly required, it is true when there is no hash value
-recorded for the type and false otherwise.  But querying that
-is slower.  */
- 
- struct sccs
- {
-   unsigned int dfsnum;
-   unsigned int low;
-   bool on_sccstack;
-   union {
- hashval_t hash;
- signed char same_p;
-   } u;
- };
- 
- static unsigned int next_dfs_num;
- static unsigned int gtc_next_dfs_num;
- 
- /* Return true if T1 and T2 have the same name.  If FOR_COMPLETION_P is
-true then if any type has no name return false, otherwise return
-true if both types have no names.  */
- 
- static bool
- compare_type_names_p (tree t1, tree t2)
- {
-   tree name1 = TYPE_NAME (t1);
-   tree name2 = TYPE_NAME (t2);
- 
-   if ((name1 != NULL_TREE) != (name2 != NULL_TREE))
- return false;
- 
-   if (name1 == NULL_TREE)
- return true;
- 
-   /* Either both should be a TYPE_DECL or both an IDENTIFIER_NODE.  */
-   if (TREE_CODE (name1) != TREE_CODE (name2))
- return false;
- 
-   if (TREE_CODE (name1) == TYPE_DECL)
- name1 = DECL_NAME (name1);
-   gcc_checking_assert (!name1 || TREE_CODE (name1) == IDENTIFIER_NODE);
- 
-   if (TREE_CODE (name2) == TYPE_DECL)
- name2 = DE

Re: [PATCH] Transaction fix: New target hook special_function_flags

[Andreas Krebbel]

On 14/10/13 13:30, Jakub Jelinek wrote:
> On Mon, Oct 14, 2013 at 01:26:25PM +0200, Richard Biener wrote:
>>> I somehow couldn't get it working with the add_builtin_function parameter. 
>>> Perhaps because these
>>> attrs are supposed to be translated into the respective tree flags 
>>> (DECL_IS_RETURNS_TWICE) at that
>>> point already?!
>>
>> Yes, via handle_..._attribute.
> 
> ??  If add_builtin_function last argument is non-NULL, it will call
> decl_attributes with that argument and thus should set up evertyhing.
> So, IMHO:
>   tree noreturn = tree_cons (get_identifier ("noreturn"), NULL, NULL);
>   tree returns_twice = tree_cons (get_identifier ("returns_twice"), NULL, 
> NULL);
> and passing either of those to add_builtin_function should IMHO work just
> fine.

Yes that works - thanks. My first test was incomplete. I've tried with only 
"returns_twice" first
and while this prevents the tree level ccp optimization it is not sufficient to 
fix the testcase. On
rtl level the f = 88.0f assignment inside the transaction is still removed as 
dead code. This only
stops when making tabort "noreturn" but this of course is no real fix since an 
abort might occur
also without calling tabort explicitly.

Having FPRs live accross an abort together with the incomplete CFG modelling of 
transactions will
probably continue to cause all kinds of trouble until this is sorted out.

Thanks for your help!

Bye,

-Andreas-

---
 gcc/config/s390/s390.c |   13 +++!!
 1 file changed, 3 insertions(+), 10 modifications(!)

Index: gcc/config/s390/s390.c
===
*** gcc/config/s390/s390.c.orig
--- gcc/config/s390/s390.c
*** static void
*** 9900,9905 
--- 9900,9908 
  s390_init_builtins (void)
  {
tree ftype, uint64_type;
+   tree returns_twice_attr = tree_cons (get_identifier ("returns_twice"),
+  NULL, NULL);
+   tree noreturn_attr = tree_cons (get_identifier ("noreturn"), NULL, NULL);

/* void foo (void) */
ftype = build_function_type_list (void_type_node, NULL_TREE);
*** s390_init_builtins (void)
*** 9910,9926 
ftype = build_function_type_list (void_type_node, integer_type_node,
NULL_TREE);
add_builtin_function ("__builtin_tabort", ftype,
!   S390_BUILTIN_TABORT, BUILT_IN_MD, NULL, NULL_TREE);
add_builtin_function ("__builtin_tx_assist", ftype,
S390_BUILTIN_TX_ASSIST, BUILT_IN_MD, NULL, NULL_TREE);

/* int foo (void *) */
ftype = build_function_type_list (integer_type_node, ptr_type_node, 
NULL_TREE);
add_builtin_function ("__builtin_tbegin", ftype, S390_BUILTIN_TBEGIN,
!   BUILT_IN_MD, NULL, NULL_TREE);
add_builtin_function ("__builtin_tbegin_nofloat", ftype,
S390_BUILTIN_TBEGIN_NOFLOAT,
!   BUILT_IN_MD, NULL, NULL_TREE);

/* int foo (void *, int) */
ftype = build_function_type_list (integer_type_node, ptr_type_node,
--- 9913,9929 
ftype = build_function_type_list (void_type_node, integer_type_node,
NULL_TREE);
add_builtin_function ("__builtin_tabort", ftype,
!   S390_BUILTIN_TABORT, BUILT_IN_MD, NULL, noreturn_attr);
add_builtin_function ("__builtin_tx_assist", ftype,
S390_BUILTIN_TX_ASSIST, BUILT_IN_MD, NULL, NULL_TREE);

/* int foo (void *) */
ftype = build_function_type_list (integer_type_node, ptr_type_node, 
NULL_TREE);
add_builtin_function ("__builtin_tbegin", ftype, S390_BUILTIN_TBEGIN,
!   BUILT_IN_MD, NULL, returns_twice_attr);
add_builtin_function ("__builtin_tbegin_nofloat", ftype,
S390_BUILTIN_TBEGIN_NOFLOAT,
!   BUILT_IN_MD, NULL, returns_twice_attr);

/* int foo (void *, int) */
ftype = build_function_type_list (integer_type_node, ptr_type_node,
*** s390_init_builtins (void)
*** 9928,9938 
add_builtin_function ("__builtin_tbegin_retry", ftype,
S390_BUILTIN_TBEGIN_RETRY,
BUILT_IN_MD,
!   NULL, NULL_TREE);
add_builtin_function ("__builtin_tbegin_retry_nofloat", ftype,
S390_BUILTIN_TBEGIN_RETRY_NOFLOAT,
BUILT_IN_MD,
!   NULL, NULL_TREE);

/* int foo (void) */
ftype = build_function_type_list (integer_type_node, NULL_TREE);
--- 9931,9941 
add_builtin_function ("__builtin_tbegin_retry", ftype,
S390_BUILTIN_TBEGIN_RETRY,
BUILT_IN_MD,
!   NULL, returns_twice_attr);
add_builtin_function ("__builtin_tbegin_retry_nofloat", ftype,
S390_BUILTIN_TBEGIN_RETRY_NOFLOAT,
BUILT_IN_MD,
!   NULL, returns_twice_att

[C++ PATCH] Fix PR58705

[Marek Polacek]

We were ICEing on the attached testcase, because in check_narrowing,
for = {{}}, we wanted to check recursively the CONSTRUCTOR_ELTs,
even though init in this case has 0 CONSTRUCTOR_NELTS.  So I added
the check for CONSTRUCTOR_NELTS > 0.  Moreover, since empty scalar
initializers are forbidden in C FE, I think we should error out here
too.  (Complex type is considered as an arithmetic type as a GNU
extension and arithmetic types are scalar types.)
This isn't C++11-specific as it may look from the PR.  The bug
exhibits when -Wnarrowing (that is implicitly enabled with C++11) is
on, since in check_narrowing we have

  if (!warn_narrowing || !ARITHMETIC_TYPE_P (type))
  return;

and with -Wno-narrowing we just return early.

Regtested/bootstrapped on x86_64-linux, ok for trunk?

2013-10-14  Marek Polacek  

PR c++/58705
cp/
* typeck2.c (check_narrowing): Give an error when the scalar
initializer is empty.
testsuite/
* g++.dg/parse/pr58705.C: New test.

--- gcc/cp/typeck2.c.mp 2013-10-14 11:11:36.971293089 +0200
+++ gcc/cp/typeck2.c2013-10-14 11:52:14.582061052 +0200
@@ -833,7 +833,10 @@ check_narrowing (tree type, tree init)
   && TREE_CODE (type) == COMPLEX_TYPE)
 {
   tree elttype = TREE_TYPE (type);
-  check_narrowing (elttype, CONSTRUCTOR_ELT (init, 0)->value);
+  if (CONSTRUCTOR_NELTS (init) > 0)
+   check_narrowing (elttype, CONSTRUCTOR_ELT (init, 0)->value);
+  else
+   error ("empty scalar initializer");
   if (CONSTRUCTOR_NELTS (init) > 1)
check_narrowing (elttype, CONSTRUCTOR_ELT (init, 1)->value);
   return;
--- gcc/testsuite/g++.dg/parse/pr58705.C.mp 2013-10-14 11:14:46.460955343 
+0200
+++ gcc/testsuite/g++.dg/parse/pr58705.C2013-10-14 11:51:02.698810118 
+0200
@@ -0,0 +1,5 @@
+// PR c++/58705
+// { dg-do compile }
+// { dg-options "-Wnarrowing" }
+
+_Complex float f = {{}};  // { dg-error "empty scalar initializer" }

Marek

[Ada] Use of non-static constants in aspect Global

[Arnaud Charlet]

This patch updates the legality checks of aspect/pragma Global to allow
references to enclosing formal parameters.


-- Source --


--  formal_references.adb

procedure Formal_References
  (In_Formal : Integer;
   In_Out_Formal : in out Integer;
   Out_Formal: out Integer)
is
   procedure Nested (Own_Formal : Integer)
 with Global => (Input  => (In_Formal, Own_Formal),
 In_Out => In_Out_Formal,
 Output => Out_Formal),
  Depends => (Out_Formal=> (In_Formal, In_Out_Formal, Own_Formal),
  In_Out_Formal => In_Out_Formal)
   is begin null; end Nested;
begin
   null;
end Formal_References;


-- Compilation and output --


$gcc -c -gnat12 -gnatd.V formal_references.adb
formal_references.adb:7:44: global item cannot reference formal parameter

Tested on x86_64-pc-linux-gnu, committed on trunk

2013-10-14  Hristian Kirtchev  

* sem_prag.adb (Analyze_Global_Item): Allow
references to enclosing formal parameters.

Index: sem_prag.adb
===
--- sem_prag.adb(revision 203522)
+++ sem_prag.adb(working copy)
@@ -1428,13 +1428,16 @@
 
 if Present (Item_Id) then
 
-   --  A global item cannot reference a formal parameter. Do this
-   --  check first to provide a better error diagnostic.
+   --  A global item may denote a formal parameter of an enclosing
+   --  subprogram. Do this check first to provide a better error
+   --  diagnostic.
 
if Is_Formal (Item_Id) then
-  Error_Msg_N
-("global item cannot reference formal parameter", Item);
-  return;
+  if Scope (Item_Id) = Subp_Id then
+ Error_Msg_N
+   ("global item cannot reference formal parameter", Item);
+ return;
+  end if;
 
--  The only legal references are those to abstract states and
--  variables.

[testsuite] Fix gcc.dg/torture/pr58670.c for Solaris 9/x86 assembler

[Rainer Orth]

The new gcc.dg/torture/pr58670.c testcase FAILs on Solaris 9/x86 with
the Sun assembler:

FAIL: gcc.dg/torture/pr58670.c  -O0  (test for excess errors)
Excess errors:
Assembler: pr58670.c
"/var/tmp//cceOnFp7.s", line 18 : Illegal mnemonic
"/var/tmp//cceOnFp7.s", line 18 : Syntax error
"/var/tmp//cceOnFp7.s", line 45 : Illegal mnemonic
"/var/tmp//cceOnFp7.s", line 45 : Syntax error

as doesn't grok the unadorned bts, but requires btsl instead.  The
following patch doest just that; tested with the appropriate runtest
invocation on i386-pc-solaris2.9 with either as or gas 2.23.2 and
checking that with gas the generated insn stays the same.  I guess this
is obvious?

Thanks.
Rainer


2013-10-14  Rainer Orth  

* gcc.dg/torture/pr58670.c (ASM_STR) [__i386__ || __x86_64__]: Use
btsl.

# HG changeset patch
# Parent 439bff21626bdf77e8264901c6c6607bb3a90741
Fix gcc.dg/torture/pr58670.c for Solaris 9/x86 assembler

diff --git a/gcc/testsuite/gcc.dg/torture/pr58670.c b/gcc/testsuite/gcc.dg/torture/pr58670.c
--- a/gcc/testsuite/gcc.dg/torture/pr58670.c
+++ b/gcc/testsuite/gcc.dg/torture/pr58670.c
@@ -2,7 +2,7 @@
 /* { dg-do run { target i?86-*-* x86_64-*-* } } */
 
 #if defined (__i386__) || defined (__x86_64__)
-#define ASM_STR "bts $1, %0; jc %l[lab]"
+#define ASM_STR "btsl $1, %0; jc %l[lab]"
 #endif
 
 __attribute__((noinline, noclone)) int

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

[Ada] Update documentation of debug switches

[Arnaud Charlet]

This patch removes the documentation of debug switches that are not used
anymore by gnat2why, and are thus free for other uses.

In frontend.adb, there was a now obsolete reference to -gnatd.H, which
is also removed.

Tested on x86_64-pc-linux-gnu, committed on trunk

2013-10-14  Johannes Kanig  

* debug.adb: Release now unused debug switches that were only
relevant for gnat2why backend, not the frontend
* frontend.adb (Frontend) Do not stop when -gnatd.H is present,
was unused

Index: frontend.adb
===
--- frontend.adb(revision 203521)
+++ frontend.adb(working copy)
@@ -99,13 +99,6 @@
 
CStand.Create_Standard;
 
-   --  If the -gnatd.H flag is present, we are only interested in the Standard
-   --  package, so the frontend has done its job here.
-
-   if Debug_Flag_Dot_HH then
-  return;
-   end if;
-
--  Check possible symbol definitions specified by -gnateD switches
 
Prepcomp.Process_Command_Line_Symbol_Definitions;
Index: debug.adb
===
--- debug.adb   (revision 203521)
+++ debug.adb   (working copy)
@@ -125,16 +125,16 @@
--  d.E
--  d.F  SPARK mode
--  d.G  Frame condition mode for gnat2why
-   --  d.H  Standard package only mode for gnat2why
+   --  d.H
--  d.I  Do not ignore enum representation clauses in CodePeer mode
--  d.J  Disable parallel SCIL generation mode
-   --  d.K  SPARK check mode for gnat2why
+   --  d.K
--  d.L  Depend on back end for limited types in if and case expressions
--  d.M  Relaxed RM semantics
--  d.N  Add node to all entities
--  d.O  Dump internal SCO tables
--  d.P  Previous (non-optimized) handling of length comparisons
-   --  d.Q  Flow Analysis mode for gnat2why
+   --  d.Q
--  d.R  Restrictions in ali files in positional form
--  d.S  Force Optimize_Alignment (Space)
--  d.T  Force Optimize_Alignment (Time)
@@ -143,7 +143,7 @@
--  d.W  Print out debugging information for Walk_Library_Items
--  d.X
--  d.Y
-   --  d.Z  Dump flow analysis graphs, for debugging purposes (gnat2why)
+   --  d.Z
 
--  d1   Error msgs have node numbers where possible
--  d2   Eliminate error flags in verbose form error messages
@@ -596,7 +596,7 @@
 
--  d.D  SPARK strict mode. Interpret compiler permissions as strictly as
--   possible in SPARK mode.
-
+   --
--  d.F  SPARK mode. Generate AST in a form suitable for formal
--   verification, as well as additional cross reference information in
--   ALI files to compute effects of subprograms. Note that ALI files
@@ -606,10 +606,6 @@
--   generate Why code. Instead, it generates ALI files with an extra
--   section which contains the effects of subprograms.
 
-   --  d.H  Standard package only mode for gnat2why. In this mode, gnat2why
-   --   will only generate Why code for package Standard. Any given input
-   --   file will be ignored.
-
--  d.I  Do not ignore enum representation clauses in CodePeer mode.
--   The default of ignoring representation clauses for enumeration
--   types in CodePeer is good for the majority of Ada code, but in some
@@ -620,9 +616,6 @@
--   done in parallel to speed processing. This switch disables this
--   behavior.
 
-   --  d.K  SPARK check mode for gnat2why. In this mode, gnat2why does not
-   --   generate Why code.
-
--  d.L  Normally the front end generates special expansion for conditional
--   expressions of a limited type. This debug flag removes this special
--   case expansion, leaving it up to the back end to handle conditional
@@ -644,9 +637,6 @@
--   This is there in case we find a situation where the optimization
--   malfunctions, to provide a work around.
 
-   --  d.Q  Flow Analysis mode for gnat2why. When this flag is given,
-   --   gnat2why will do flow analysis, and no translation to Why is done.
-
--  d.R  As documented in lib-writ.ads, restrictions in the ali file can
--   have two forms, positional and named. The named notation is the
--   current preferred form, but the use of this debug switch will force
@@ -671,11 +661,6 @@
--   the order in which units are walked. This is primarily for use in
--   debugging CodePeer mode.
 
-   --  d.Z  In gnat2why, in Flow analysis mode (-gnatd.Q), dump the different
-   --   graphs (control flow, control dependence) for debugging purposes.
-   --   This debug flag will be removed when flow analysis is sufficiently
-   --   stable.
-
--  d.Y  Prevents the use of the N_Expression_With_Actions node even in the
--   case of the gcc back end. Provided as a back up in case the new
--   scheme has problems.

Re: [testsuite] Fix gcc.dg/torture/pr58670.c for Solaris 9/x86 assembler

[Jakub Jelinek]

On Mon, Oct 14, 2013 at 02:35:53PM +0200, Rainer Orth wrote:
> The new gcc.dg/torture/pr58670.c testcase FAILs on Solaris 9/x86 with
> the Sun assembler:
> 
> FAIL: gcc.dg/torture/pr58670.c  -O0  (test for excess errors)
> Excess errors:
> Assembler: pr58670.c
> "/var/tmp//cceOnFp7.s", line 18 : Illegal mnemonic
> "/var/tmp//cceOnFp7.s", line 18 : Syntax error
> "/var/tmp//cceOnFp7.s", line 45 : Illegal mnemonic
> "/var/tmp//cceOnFp7.s", line 45 : Syntax error
> 
> as doesn't grok the unadorned bts, but requires btsl instead.  The
> following patch doest just that; tested with the appropriate runtest
> invocation on i386-pc-solaris2.9 with either as or gas 2.23.2 and
> checking that with gas the generated insn stays the same.  I guess this
> is obvious?

Ok, but please apply it both to trunk and 4.8.

> 2013-10-14  Rainer Orth  
> 
>   * gcc.dg/torture/pr58670.c (ASM_STR) [__i386__ || __x86_64__]: Use
>   btsl.

Jakub

[Ada] Implement pragmas Type_Invariant[_Class]

[Arnaud Charlet]

This implements two new pragmas, whose names, syntax, and semantics
match the corresponding aspects Type_Invariant and Type_Invariant'Class
as closely as possible. For Type_Invariant'Class the pragma is named
Type_Invariant_Class, since the attribute form of the name is not legal
for a pragma name.

The following test

 1. with Ada.Text_IO;use Ada.Text_IO;
 2. with Ada.Assertions; use Ada.Assertions;
 3. with Ada.Exceptions; use Ada.Exceptions;
 4. procedure PSimpleinv is
 5.package X is
 6.   type R is private;
 7.   pragma Type_Invariant (R, Testr (R));
 8.   function Testr (X : R) return Boolean;
 9.   function Gen (X : Integer) return R;
10.   procedure Make (X : out R);
11.
12.   type T1 is tagged private;
13.   pragma Type_Invariant (T1, Testt1 (T1));
14.   type T2 is new T1 with private;
15.   function Testt1 (X : T1) return Boolean;
16.   function Maket2 return T2;
17.
18.private
19.   type R is record
20.  Field : Integer := 4;
21.   end record;
22.
23.   type T1 is tagged record
24.  Field : Integer := 4;
25.   end record;
26.
27.   type T2 is new T1 with record
28.  Field2 : Integer := 4;
29.   end record;
30.end X;
31.
32.package body X is
33.   function Testr (X : R) return Boolean is
34.   begin
35.  return X.Field mod 2 = 1;
36.   end Testr;
37.
38.   function Gen (X : Integer) return R is
39.   begin
40.  return (Field => X);
41.   end Gen;
42.
43.   procedure Make (X : out R) is
44.   begin
45.  X := (Field => 4);
46.   end Make;
47.
48.   function Testt1 (X : T1) return Boolean is
49.   begin
50.  return X.Field mod 2 = 1;
51.   end Testt1;
52.
53.   function Maket2 return T2 is
54.   begin
55.  return (Field => 4, Field2 => 3);
56.   end Maket2;
57.
58.   --  No exception, private initialization
59.
60.   VPrivate : R := (Field => 6);
61.end X;
62.
63. begin
64.--  No exception, OK initialization
65.
66.begin
67.   declare
68.  V1 : X.R := X.Gen (5);
69.   begin
70.  null;
71.   end;
72.   Put_Line ("V1: no exception");
73.end;
74.
75.--  Bad result from public function
76.
77.begin
78.   declare
79.  V2 : X.R := X.Gen (4);
80.   begin
81.  null;
82.   end;
83.   Put_Line ("V2: no exception");
84.exception
85.   when E : Assertion_Error =>
86.  Put_Line ("V2: " & Exception_Message (E));
87.end;
88.
89.--  Bad default initialization
90.
91.begin
92.   declare
93.  V3 : X.R;
94.   begin
95.  null;
96.   end;
97.   Put_Line ("V3: no exception");
98.exception
99.   when E : Assertion_Error =>
   100.  Put_Line ("V3: " & Exception_Message (E));
   101.end;
   102.
   103.--  Bad OUT parameter
   104.
   105.begin
   106.   declare
   107.  V4 : X.R := X.Gen (5);
   108.   begin
   109.  X.Make (V4);
   110.   end;
   111.   Put_Line ("V4: no exception");
   112.exception
   113.   when E : Assertion_Error =>
   114.  Put_Line ("V4: " & Exception_Message (E));
   115.end;
   116.
   117.--  Bad conversion
   118.
   119.begin
   120.   declare
   121.  TT : X.T2 := X.Maket2;
   122.  V5 : X.T1 := X.T1 (TT);
   123.   begin
   124.  null;
   125.   end;
   126.   Put_Line ("V5: no exception");
   127.exception
   128.   when E : Assertion_Error =>
   129.  Put_Line ("V5: " & Exception_Message (E));
   130.end;
   131. end PSimpleinv;

compiled with -gnata12 -gnatw.l, outputs:

V1: no exception
V2: failed invariant from psimpleinv.adb:7
V3: failed invariant from psimpleinv.adb:7
V4: failed invariant from psimpleinv.adb:7
V5: failed invariant from psimpleinv.adb:13

The following test:

 1. with Ada.Text_IO;use Ada.Text_IO;
 2. with Ada.Assertions; use Ada.Assertions;
 3. with Ada.Exceptions; use Ada.Exceptions;
 4. procedure PInheritinv is
 5.package X is
 6.
 7.   type T1 is tagged private;
 8.   pragma Type_Invariant_Class (T1, Testt1 (T1));
 9.
10.   function Testt1 (X : T1) return Boolean;
11.   function Maket1 return T1;
12.
13.   type T2 is new T1 with private;
   |
>>> info: "T2" inherits "Invariant'Class" aspect from line 8

14.
15.   function Maket2 return T2;
16.   function

Re: [PATCH] Transaction fix: New target hook special_function_flags

[Richard Biener]

On Mon, Oct 14, 2013 at 2:20 PM, Andreas Krebbel
 wrote:
> On 14/10/13 13:30, Jakub Jelinek wrote:
>> On Mon, Oct 14, 2013 at 01:26:25PM +0200, Richard Biener wrote:
 I somehow couldn't get it working with the add_builtin_function parameter. 
 Perhaps because these
 attrs are supposed to be translated into the respective tree flags 
 (DECL_IS_RETURNS_TWICE) at that
 point already?!
>>>
>>> Yes, via handle_..._attribute.
>>
>> ??  If add_builtin_function last argument is non-NULL, it will call
>> decl_attributes with that argument and thus should set up evertyhing.
>> So, IMHO:
>>   tree noreturn = tree_cons (get_identifier ("noreturn"), NULL, NULL);
>>   tree returns_twice = tree_cons (get_identifier ("returns_twice"), NULL, 
>> NULL);
>> and passing either of those to add_builtin_function should IMHO work just
>> fine.
>
> Yes that works - thanks. My first test was incomplete. I've tried with only 
> "returns_twice" first
> and while this prevents the tree level ccp optimization it is not sufficient 
> to fix the testcase. On
> rtl level the f = 88.0f assignment inside the transaction is still removed as 
> dead code. This only
> stops when making tabort "noreturn" but this of course is no real fix since 
> an abort might occur
> also without calling tabort explicitly.
>
> Having FPRs live accross an abort together with the incomplete CFG modelling 
> of transactions will
> probably continue to cause all kinds of trouble until this is sorted out.

Yeah, similar to the setjmp/longjmp mess I've fixed on GIMPLE (but that
is still broken on the RTL level).

Richard.

> Thanks for your help!
>
> Bye,
>
> -Andreas-
>
> ---
>  gcc/config/s390/s390.c |   13 +++!!
>  1 file changed, 3 insertions(+), 10 modifications(!)
>
> Index: gcc/config/s390/s390.c
> ===
> *** gcc/config/s390/s390.c.orig
> --- gcc/config/s390/s390.c
> *** static void
> *** 9900,9905 
> --- 9900,9908 
>   s390_init_builtins (void)
>   {
> tree ftype, uint64_type;
> +   tree returns_twice_attr = tree_cons (get_identifier ("returns_twice"),
> +  NULL, NULL);
> +   tree noreturn_attr = tree_cons (get_identifier ("noreturn"), NULL, NULL);
>
> /* void foo (void) */
> ftype = build_function_type_list (void_type_node, NULL_TREE);
> *** s390_init_builtins (void)
> *** 9910,9926 
> ftype = build_function_type_list (void_type_node, integer_type_node,
> NULL_TREE);
> add_builtin_function ("__builtin_tabort", ftype,
> !   S390_BUILTIN_TABORT, BUILT_IN_MD, NULL, NULL_TREE);
> add_builtin_function ("__builtin_tx_assist", ftype,
> S390_BUILTIN_TX_ASSIST, BUILT_IN_MD, NULL, NULL_TREE);
>
> /* int foo (void *) */
> ftype = build_function_type_list (integer_type_node, ptr_type_node, 
> NULL_TREE);
> add_builtin_function ("__builtin_tbegin", ftype, S390_BUILTIN_TBEGIN,
> !   BUILT_IN_MD, NULL, NULL_TREE);
> add_builtin_function ("__builtin_tbegin_nofloat", ftype,
> S390_BUILTIN_TBEGIN_NOFLOAT,
> !   BUILT_IN_MD, NULL, NULL_TREE);
>
> /* int foo (void *, int) */
> ftype = build_function_type_list (integer_type_node, ptr_type_node,
> --- 9913,9929 
> ftype = build_function_type_list (void_type_node, integer_type_node,
> NULL_TREE);
> add_builtin_function ("__builtin_tabort", ftype,
> !   S390_BUILTIN_TABORT, BUILT_IN_MD, NULL, 
> noreturn_attr);
> add_builtin_function ("__builtin_tx_assist", ftype,
> S390_BUILTIN_TX_ASSIST, BUILT_IN_MD, NULL, NULL_TREE);
>
> /* int foo (void *) */
> ftype = build_function_type_list (integer_type_node, ptr_type_node, 
> NULL_TREE);
> add_builtin_function ("__builtin_tbegin", ftype, S390_BUILTIN_TBEGIN,
> !   BUILT_IN_MD, NULL, returns_twice_attr);
> add_builtin_function ("__builtin_tbegin_nofloat", ftype,
> S390_BUILTIN_TBEGIN_NOFLOAT,
> !   BUILT_IN_MD, NULL, returns_twice_attr);
>
> /* int foo (void *, int) */
> ftype = build_function_type_list (integer_type_node, ptr_type_node,
> *** s390_init_builtins (void)
> *** 9928,9938 
> add_builtin_function ("__builtin_tbegin_retry", ftype,
> S390_BUILTIN_TBEGIN_RETRY,
> BUILT_IN_MD,
> !   NULL, NULL_TREE);
> add_builtin_function ("__builtin_tbegin_retry_nofloat", ftype,
> S390_BUILTIN_TBEGIN_RETRY_NOFLOAT,
> BUILT_IN_MD,
> !   NULL, NULL_TREE);
>
> /* int foo (void) */
> ftype = build_function_type_list (integer_type_node, NULL_TREE);
> --- 9931,9941 
> add_builtin_function ("__builtin

[Ada] Handling of null refinements in aspect/pragma Refined_Global

[Arnaud Charlet]

This patch updates the analysis of aspect/pragma Refined_Global to accept
legal global refinements of states with null visible refinements.


-- Source --


--  global_null.ads

package Global_Null
  with Abstract_State =>
 ((In_State with External, Input_Only),
  (In_Error with External, Input_Only),
   In_Out_State,
   In_Out_Error,
  (Out_State with External, Output_Only),
  (Out_Error with External, Output_Only))
is
   In_Var : Integer;
   In_Out_Var : Integer;
   Out_Var: Integer;

   procedure OK_1
 with Global =>
(Input  => In_State,
 In_Out => In_Out_State,
 Output => Out_State);

   procedure OK_2
 with Global =>
(Input  => In_State,
 In_Out => In_Out_State,
 Output => Out_State);

   procedure OK_3
 with Global =>
(Input  => (In_State, In_Var),
 In_Out => (In_Out_State, In_Out_Var),
 Output => (Out_State, Out_Var));

   procedure Error_1
 with Global =>
(Input  => In_Error,
 In_Out => In_Out_Error,
 Output => Out_Error);

   procedure Error_2
 with Global =>
(Input  => In_Error,
 In_Out => In_Out_Error,
 Output => Out_Error);

   procedure Error_3
 with Global =>
(Input  => (In_Error, In_Var),
 In_Out => (In_Out_Error, In_Out_Var),
 Output => (Out_Error, Out_Var));
end Global_Null;

--  global_null.adb

package body Global_Null
  with Refined_State =>
 (In_State => null,
  In_Error => Var_1,
  In_Out_State => null,
  In_Out_Error => Var_2,
  Out_State=> null,
  Out_Error=> Var_3)
is
   procedure OK_1
 with Refined_Global => null
   is begin null; end OK_1;

   procedure OK_2
 with Refined_Global =>
(Input  => null,
 In_Out => null,
 Output => null)
   is begin null; end OK_2;

   procedure OK_3
 with Refined_Global =>
(Input  => In_Var,
 In_Out => In_Out_Var,
 Output => Out_Var)
   is begin null; end OK_3;

   procedure Error_1
 with Refined_Global => null
   is begin null; end Error_1;

   procedure Error_2
 with Refined_Global =>
(Input  => null,
 In_Out => null,
 Output => null)
   is begin null; end Error_2;

   procedure Error_3
 with Refined_Global =>
(Input  => In_Var,
 In_Out => In_Out_Var,
 Output => Out_Var)
   is begin null; end Error_3;

   Var_1 : Integer;
   Var_2 : Integer;
   Var_3 : Integer;
end Global_Null;


-- Compilation and output --


$ gcc -c -gnat12 -gnatd.V global_null.adb
global_null.adb:29:11: refinement cannot be null, subprogram "Error_1" has
  global items
global_null.adb:33:11: global refinement of state "In_Error" must include at
  least one constituent of mode Input
global_null.adb:40:11: global refinement of state "In_Error" must include at
  least one constituent of mode Input

Tested on x86_64-pc-linux-gnu, committed on trunk

2013-10-14  Hristian Kirtchev  

* einfo.adb: Flag263 is now known as Has_Null_Refinement.
(Has_Null_Refinement): New routine.
(Set_Has_Null_Refinement): New routine.
(Write_Entity_Flags): Output the status of flag
Has_Null_Refinement.
* einfo.ads: Add new flag Has_Null_Refinement along with
comment on usage and update all nodes subject to the flag.
(Has_Null_Refinement): New routine along with pragma Inline.
(Set_Has_Null_Refinement): New rouitine along with pragma Inline.
* sem_prag.adb (Analyze_Constituent): Mark a state as having
a null refinement when the sole constituent is "null".
(Analyze_Global_List): Handle null input/output items.
(Analyze_Refined_Global_In_Decl_Part): Add local variable
Has_Null_State. Add logic to handle combinations of states
with null refinements and null global lists and/or items.
(Check_In_Out_States, Check_Input_States, Check_Output_States):
Use attribute Has_Null_Refinement to detect states with
constituents.
(Check_Refined_Global_List): Handle null input/output items.
(Process_Global_Item): Handle states with null refinements.
(Process_Global_List): Handle null input/output items.

Index: einfo.adb
===
--- einfo.adb   (revision 203523)
+++ einfo.adb   (working copy)
@@ -551,8 +551,8 @@
 
--Has_Delayed_Rep_Aspects Flag261
--May_Inherit_Delayed_Rep_Aspects Flag262
+   --Has_Null_Refinement Flag263
 
-   --(unused)Flag263
--(unused)Flag264
--(unused)F

[Ada] Fix debug info for renaming of dereferenced return value

[Arnaud Charlet]

This fixes the debugging information generated for a variable renaming the
dereference of the return value of a function returning an access type.

The compiler was both materializing the renaming object and generating
the special debug renaming variable for it, without generating debugging
information for the temporary capturing the return value and linked to
by the debug renaming variable.

The compiler will now avoid to materialize the renaming object and generate
debugging information for the temporary in the following example:

   type P is access all Integer;
   X : aliased Integer := 42;

   function Val return P is
   begin
  return X'Access;
   end Val;

   V : Integer renames Val.all;

Tested on x86_64-pc-linux-gnu, committed on trunk

2013-10-14  Eric Botcazou  

* exp_dbug.adb (Debug_Renaming_Declaration): Do not
materialize the entity when the renamed object contains an
N_Explicit_Dereference.
* sem_ch8.adb (Analyze_Object_Renaming):
If the renaming comes from source and the renamed object is a
dereference, mark the prefix as needing debug information.

Index: exp_dbug.adb
===
--- exp_dbug.adb(revision 203521)
+++ exp_dbug.adb(working copy)
@@ -411,7 +411,6 @@
Ren := Prefix (Ren);
 
 when N_Explicit_Dereference =>
-   Set_Materialize_Entity (Ent);
Prepend_String_To_Buffer ("XA");
Ren := Prefix (Ren);
 
Index: sem_ch8.adb
===
--- sem_ch8.adb (revision 203523)
+++ sem_ch8.adb (working copy)
@@ -1208,11 +1208,22 @@
   --  may have been rewritten in several ways.
 
   elsif Is_Object_Reference (Nam) then
- if Comes_From_Source (N)
-   and then Is_Dependent_Component_Of_Mutable_Object (Nam)
- then
-Error_Msg_N
-  ("illegal renaming of discriminant-dependent component", Nam);
+ if Comes_From_Source (N) then
+if Is_Dependent_Component_Of_Mutable_Object (Nam) then
+   Error_Msg_N
+ ("illegal renaming of discriminant-dependent component", Nam);
+end if;
+
+--  If the renaming comes from source and the renamed object is a
+--  dereference, then mark the prefix as needing debug information,
+--  since it might have been rewritten hence internally generated
+--  and Debug_Renaming_Declaration will link the renaming to it.
+
+if Nkind (Nam) = N_Explicit_Dereference
+  and then Is_Entity_Name (Prefix (Nam))
+then
+   Set_Debug_Info_Needed (Entity (Prefix (Nam)));
+end if;
  end if;
 
   --  A static function call may have been folded into a literal

[Ada] Handle initialization of array aggregate with <> component

[Arnaud Charlet]

This patch makes sure that initialization of components corresponding
to a <> component clause is handled correctly. There are two cases.
If there is a Default_Component_Value aspect for the array, then this
value is used, otherwise normal default initialization takes place
(including in particular Initialize_Scalars initialization).

The following program compiles quietly as shown and outputs 456.
Before this update, the component printed was uninitialized.

 1. with Text_IO; use Text_IO;
 2. procedure Boxinit is
 3.type T is new Integer with Default_Value => 123;
 4.type T_For_Two is array (Boolean) of T
 5.  with Default_Component_Value => 456;
 6.X : T_For_Two := (others => <>);
 7. begin
 8.Put_Line (T'Image (X (False)));
 9. end;

The following program compiles quietly as shown and runs
without generating any output (previously Program_Error
was raised, because B_Strange did not get the expected
Initialize_Scalars initialization

 1. pragma Initialize_Scalars;
 2. procedure BoxIS is
 3.type Boolean_Array is
 4.  array (Natural range <>) of Boolean;
 5.type Ptr_Boolean_Array is
 6.  access Boolean_Array;
 7.B_Strange : Ptr_Boolean_Array :=
 8.  new Boolean_Array'(1 .. 5 => <>);
 9.B_Normal : Ptr_Boolean_Array :=
10.  new Boolean_Array (1 .. 5);
11. begin
12.if B_Strange.all /= B_Normal.all then
13.   raise Program_Error;
14.end if;
15. end BoxIS;

Tested on x86_64-pc-linux-gnu, committed on trunk

2013-10-14  Robert Dewar  

* einfo.ads, einfo.adb (Default_Aspect_Component_Value): Is on base type
only.
* exp_aggr.adb (Expand_Array_Aggregate): Handle proper
initialization of <> component.
* exp_ch3.adb, exp_tss.adb: Minor reformatting
* sem_ch13.adb (Default_Aspect_Component_Value, Default_Aspect_Value):
Is on base type only.
* sinfo.ads: Minor comment revision.

Index: sinfo.ads
===
--- sinfo.ads   (revision 203522)
+++ sinfo.ads   (working copy)
@@ -3596,7 +3596,7 @@
   --  Sloc points to first selector name
   --  Choices (List1)
   --  Loop_Actions (List2-Sem)
-  --  Expression (Node3)
+  --  Expression (Node3) (empty if Box_Present)
   --  Box_Present (Flag15)
   --  Inherited_Discriminant (Flag13)
 
Index: einfo.adb
===
--- einfo.adb   (revision 203526)
+++ einfo.adb   (working copy)
@@ -853,13 +853,13 @@
function Default_Aspect_Component_Value (Id : E) return N is
begin
   pragma Assert (Is_Array_Type (Id));
-  return Node19 (Id);
+  return Node19 (Base_Type (Id));
end Default_Aspect_Component_Value;
 
function Default_Aspect_Value (Id : E) return N is
begin
   pragma Assert (Is_Scalar_Type (Id));
-  return Node19 (Id);
+  return Node19 (Base_Type (Id));
end Default_Aspect_Value;
 
function Default_Expr_Function (Id : E) return E is
@@ -3456,13 +3456,13 @@
 
procedure Set_Default_Aspect_Component_Value (Id : E; V : E) is
begin
-  pragma Assert (Is_Array_Type (Id));
+  pragma Assert (Is_Array_Type (Id) and then Is_Base_Type (Id));
   Set_Node19 (Id, V);
end Set_Default_Aspect_Component_Value;
 
procedure Set_Default_Aspect_Value (Id : E; V : E) is
begin
-  pragma Assert (Is_Scalar_Type (Id));
+  pragma Assert (Is_Scalar_Type (Id) and then Is_Base_Type (Id));
   Set_Node19 (Id, V);
end Set_Default_Aspect_Value;
 
Index: einfo.ads
===
--- einfo.ads   (revision 203526)
+++ einfo.ads   (working copy)
@@ -738,13 +738,13 @@
 --   subprograms, this returns the {function,procedure}_specification, not
 --   the subprogram_declaration.
 
---Default_Aspect_Component_Value (Node19)
+--Default_Aspect_Component_Value (Node19) [base type only]
 --   Defined in array types. Holds the static value specified in a
---   default_component_value aspect specification for the array type.
+--   Default_Component_Value aspect specification for the array type.
 
---Default_Aspect_Value (Node19)
+--Default_Aspect_Value (Node19) [base type only]
 --   Defined in scalar types. Holds the static value specified in a
---   default_value aspect specification for the type.
+--   Default_Value aspect specification for the type.
 
 --Default_Expr_Function (Node21)
 --   Defined in parameters. It holds the entity of the parameterless
@@ -5171,7 +5171,7 @@
--  E_Array_Type
--  E_Array_Subtype
--First_Index (Node17)
-   --Default_Aspect_Component_Value  (Node19)
+   --Default_Aspect_Component_Value  (Node19)   (base type only)
--Component_Type  (Node20)   (base ty

[Ada] Implement new attribute Library_Level

[Arnaud Charlet]

This implements a new attribute Standard'Library_Level (Standard is
the only allowed prefix), which returns a Boolean value which is True
if the attribute is evaluated at the library level (e.g. with a package
declaration), and false if evaluated elsewhere (e.g. within a subprogram
body). In the case of generics, the value indicates the placement
of the instantiation, not the template, and indeed the use of this
attribute within a generic is the intended common application
as shown in this example:

 1. generic
 2. package LLTestP is
 3.pragma Compile_Time_Warning
 4.  (not Standard'Library_Level,
 5.   "LLTest should be instantiated at library level");
 6. end;

 1. with LLTestP;
 2. package LLTestP1 is
 3.package P is new LLTestP;
 4.P1L : constant Boolean := Standard'Library_Level;
 5. end;

 1. with LLTestP;
 2. with LLTestP1; use LLTestP1;
 3. with Text_IO; use Text_IO;
 4. procedure LLTest is
 5.package P1 is new LLTestP;
   |
>>> warning: in instantiation at lltestp.ads:4
>>> warning: LLTest should be instantiated at library level

 6. begin
 7.Put_Line (Boolean'Image (Standard'Library_Level));
 8.Put_Line (Boolean'Image (P1L));
 9. end;

When run, LLTest outputs:

FALSE
TRUE

Tested on x86_64-pc-linux-gnu, committed on trunk

2013-10-14  Robert Dewar  

* exp_attr.adb (Expand_N_Attribute_Reference): Add error
entry for Library_Level attribute (which should not survive
to expansion)
* gnat_rm.texi: Document attribute Library_Level
* sem_attr.adb (Analyze_Attribute, case Library_Level): Implement
this new attribute (Set_Boolean_Result): Replaces Set_Result
(Check_Standard_Prefix): Document that Check_E0 is called
(Check_System_Prefix): New procedure
* snames.ads-tmpl: Add entry for Library_Level attribute

Index: gnat_rm.texi
===
--- gnat_rm.texi(revision 203527)
+++ gnat_rm.texi(working copy)
@@ -337,6 +337,7 @@
 * Attribute Integer_Value::
 * Attribute Invalid_Value::
 * Attribute Large::
+* Attribute Library_Level::
 * Attribute Loop_Entry::
 * Attribute Machine_Size::
 * Attribute Mantissa::
@@ -7842,6 +7843,7 @@
 * Attribute Integer_Value::
 * Attribute Invalid_Value::
 * Attribute Large::
+* Attribute Library_Level::
 * Attribute Loop_Entry::
 * Attribute Machine_Size::
 * Attribute Mantissa::
@@ -8341,6 +8343,31 @@
 the Ada 83 reference manual for an exact description of the semantics of
 this attribute.
 
+@node Attribute Library_Level
+@unnumberedsec Attribute Library_Level
+@findex Library_Level
+@noindent
+@noindent
+@code{Standard'Library_Level} (@code{Standard} is the only allowed
+prefix) returns a Boolean value which is True if the attribute is
+evaluated at the library level (e.g. with a package declaration),
+and false if evaluated elsewhere (e.g. within a subprogram body).
+In the case of generics, the value indicates the placement of
+the instantiation, not the template, and indeed the use of this
+attribute within a generic is the intended common application
+as shown in this example:
+
+@smallexample @c ada
+generic
+  ...
+package Gen is
+  pragma Compile_Time_Error
+(not Standard'Library_Level,
+ "Gen can only be instantiated at library level");
+  ...
+end Gen;
+@end smallexample
+
 @node Attribute Loop_Entry
 @unnumberedsec Attribute Loop_Entry
 @findex Loop_Entry
Index: exp_attr.adb
===
--- exp_attr.adb(revision 203521)
+++ exp_attr.adb(working copy)
@@ -6485,6 +6485,7 @@
Attribute_Has_Tagged_Values|
Attribute_Large|
Attribute_Last_Valid   |
+   Attribute_Library_Level|
Attribute_Lock_Free|
Attribute_Machine_Emax |
Attribute_Machine_Emin |
Index: sem_attr.adb
===
--- sem_attr.adb(revision 203521)
+++ sem_attr.adb(working copy)
@@ -189,6 +189,11 @@
--  where therefore the prefix of the attribute does not match the enclosing
--  scope.
 
+   procedure Set_Boolean_Result (N : Node_Id; B : Boolean);
+   --  Rewrites node N with an occurrence of either Standard_False or
+   --  Standard_True, depending on the value of the parameter B. The
+   --  result is marked as a static expression.
+
---
-- Analyze_Attribute --
---
@@ -339,13 +344,17 @@
   --  Verify that prefix of attribute N is a scalar type
 
   procedure Check_Standard_Prefix;
-  --  Verify that prefix of attribute N is package Standard
+  --  Verify that prefix of attribute N is package Standard. Also 

[Ada] Display executable load address before traceback

[Arnaud Charlet]

This is useful for post-mortem traceback analysis on PIE platforms.
No new test, as this is platform specific.

Tested on x86_64-pc-linux-gnu, committed on trunk

2013-10-14  Tristan Gingold  

* adaint.c, adaint.h (__gnat_get_executable_load_address):
New function.
* a-exexda.adb (Append_Info_Basic_Exception_Traceback): Add
executable load address (Basic_Exception_Tback_Maxlength): Adjust.

Index: a-exexda.adb
===
--- a-exexda.adb(revision 203521)
+++ a-exexda.adb(working copy)
@@ -6,7 +6,7 @@
 --  --
 -- B o d y  --
 --  --
---  Copyright (C) 1992-2012, Free Software Foundation, Inc. --
+--  Copyright (C) 1992-2013, Free Software Foundation, Inc. --
 --  --
 -- GNAT is free software;  you can  redistribute it  and/or modify it under --
 -- terms of the  GNU General Public License as published  by the Free Soft- --
@@ -206,6 +206,11 @@
pragma Export
  (Ada, Exception_Message_Length, "__gnat_exception_msg_len");
 
+   function Get_Executable_Load_Address return System.Address;
+   pragma Import (C, Get_Executable_Load_Address,
+  "__gnat_get_executable_load_address");
+   --  Get the load address of the executable, or Null_Address if not known
+
-
-- Append_Info_Address --
-
@@ -377,17 +382,29 @@
--  As for Basic_Exception_Information:
 
BETB_Header : constant String := "Call stack traceback locations:";
+   LDAD_Header : constant String := "Load address: ";
 
procedure Append_Info_Basic_Exception_Traceback
  (X: Exception_Occurrence;
   Info : in out String;
   Ptr  : in out Natural)
is
+  Load_Address : Address;
begin
   if X.Num_Tracebacks = 0 then
  return;
   end if;
 
+  --  The executable load address line
+
+  Load_Address := Get_Executable_Load_Address;
+  if Load_Address /= Null_Address then
+ Append_Info_String (LDAD_Header, Info, Ptr);
+ Append_Info_Address (Load_Address, Info, Ptr);
+ Append_Info_NL (Info, Ptr);
+  end if;
+
+  --  The traceback lines
   Append_Info_String (BETB_Header, Info, Ptr);
   Append_Info_NL (Info, Ptr);
 
@@ -407,11 +424,12 @@
function Basic_Exception_Tback_Maxlength
  (X : Exception_Occurrence) return Natural
is
-  Space_Per_Traceback : constant := 2 + 16 + 1;
+  Space_Per_Address : constant := 2 + 16 + 1;
   --  Space for "0x" +  + " "
begin
-  return BETB_Header'Length + 1 +
-   X.Num_Tracebacks * Space_Per_Traceback + 1;
+  return LDAD_Header'Length + Space_Per_Address +
+   BETB_Header'Length + 1 +
+   X.Num_Tracebacks * Space_Per_Address + 1;
end Basic_Exception_Tback_Maxlength;
 
---
Index: adaint.c
===
--- adaint.c(revision 203521)
+++ adaint.c(working copy)
@@ -3830,8 +3830,8 @@
 extern void __main (void);
 
 void __main (void) {}
-#endif
-#endif
+#endif /* RTSS */
+#endif /* RTX */
 
 #if defined (__ANDROID__)
 
@@ -3889,7 +3889,7 @@
   CPU_SET_S (cpu - 1, count, set);
 }
 
-#else
+#else /* !CPU_ALLOC */
 
 /* Static cpu sets */
 
@@ -3919,8 +3919,59 @@
  CPU by a 0, so we need to adjust. */
   CPU_SET (cpu - 1, set);
 }
+#endif /* !CPU_ALLOC */
+#endif /* linux */
+
+/* Return the load address of the executable, or 0 if not known.  In the
+   specific case of error, (void *)-1 can be returned. Beware: this unit may
+   be in a shared library.  As low-level units are needed, we allow #include
+   here.  */
+
+#if defined (__APPLE__)
+#include 
+#elif defined (__linux__)
+#include 
+#elif defined (__AIX__)
+#include 
 #endif
+
+const void *
+__gnat_get_executable_load_address (void)
+{
+#if defined (__APPLE__)
+  return _dyld_get_image_header (0);
+
+#elif defined (__linux__)
+  struct link_map *map = _r_debug.r_map;
+
+  return (const void *)map->l_addr;
+
+#elif defined (__AIX__)
+  /* Unfortunately, AIX wants to return the info for all loaded objects,
+ so we need to increase the buffer if too small.  */
+  size_t blen = 4096;
+  int status;
+
+  while (1)
+{
+  char buf[blen];
+
+  status = loadquery (L_GETINFO, buf, blen);
+  if (status == 0)
+{
+  struct ldinfo *info = (struct ld_info *)buf;
+  return info->ldinfo_textorg;
+}
+  blen = blen * 2;
+
+  /* Avoid stack overflow.  */
+  if (blen > 40 * 1024)
+return (const void *)-1;
+}
+#else
+  return NULL;
 #endif
+}
 
 #i

[Ada] Full views of private subtypes with unknown discriminants.

[Arnaud Charlet]

A private subtype with unknown discriminants may have a full view that is
a constrained discriminated subtype. The Is_Constrained flag must be properly
set for this full view, to prevent spurious errors when the subtype is used
in an object declaration with a dynamically tagged expression.

The execution of:

 gnatmake -q -gna05 extra_class_main.adb
 extra_class_main

must yield:

FALSE
 123

-- 
with Extra_Class.Inner;
procedure Extra_Class_Main is
   package Extra is new Extra_Class.IO (Extra_Class.Inner.Ex_ATP);

begin
   Extra.Dummy;
end Extra_Class_Main;
--
package Extra_Class is
   type ATP (<>) is abstract tagged private;
   function Initialize return ATP is abstract;

   generic
  type UATP (<>) is new ATP with private;
   package IO is

  procedure Dummy;
   end IO;

private
   type ATP (Size : Natural) is abstract tagged record
  Active : Boolean := False;
   end record;
end Extra_Class;
--
package body Extra_Class.Inner is
   function Initialize return Ex_ATP is
  Value : Ex_ATP;
   begin
  return Value;
   end Initialize;
end Extra_Class.Inner;
---
with Text_IO; use Text_IO;
package body Extra_Class is

   package body IO is

  UATP_O : UATP'Class := UATP'(Initialize);   --  Workaround
  UATP_1 : UATP := UATP'(Initialize);

  procedure Dummy is
  begin
null;
UATP_1.Active := UATP_1.Size = 1;
Put_Line (Boolean'image (UATP_1.Active));
Put_Line (Integer'image (UATP_1.Size));
  end Dummy;

   end IO;

end Extra_Class;
---
package Extra_Class.Inner is
   type Ex_ATP is new Extra_Class.ATP with private;
   function Initialize return Ex_ATP;

private
   type Ex_ATP is new Extra_Class.ATP (123) with null record;
end Extra_Class.Inner;

Tested on x86_64-pc-linux-gnu, committed on trunk

2013-10-14  Ed Schonberg  

* sem_ch3.adb (Complete_Private_Subtype): If the full view of
the base type is constrained, the full view of the subtype is
known to be constrained as well.

Index: sem_ch3.adb
===
--- sem_ch3.adb (revision 203522)
+++ sem_ch3.adb (working copy)
@@ -10393,6 +10393,14 @@
 Set_First_Entity (Full, First_Entity (Full_Base));
 Set_Last_Entity  (Full, Last_Entity (Full_Base));
 
+--  If the underlying base type is constrained, we know that the
+--  full view of the subtype is constrained as well (the converse
+--  is not necessarily true).
+
+if Is_Constrained (Full_Base) then
+   Set_Is_Constrained (Full);
+end if;
+
  when others =>
 Copy_Node (Full_Base, Full);
 

[Ada] Path names of preprocessing data files with spaces

[Arnaud Charlet]

When a source is compiled with automated preprocessing specified by
switch -gnatep= with the full path of the preprocessing data file and
the path name includes spaces, the ALI file is detected as incorrect.
This patch fixes that: path names that include spaces are now quoted in
ALI files.

Tested on x86_64-pc-linux-gnu, committed on trunk

2013-10-14  Vincent Celier  

* ali.adb (Get_File_Name): New Boolean parameter May_Be_Quoted,
defaulted to False.  Calls Get_Name with May_Be_Quoted.
(Get_Name): New Boolean parameter May_Be_Quoted, defaulted to
False. If May_Be_Quoted is True and first non blank charater is
'"', unquote the name.
(Scan_ALI): For the file/path name on the D line, call Get_File_Name
with May_Be_Quoted = True, as it may have been quoted.
* lib-util.adb, lib-util.ads (Write_Info_Name_May_Be_Quoted): New
procedure to write file/path names that may contain spaces and if they
do are quoted.
* lib-writ.adb (Write_ALI): Use new procedure
Write_Info_Name_May_Be_Quoted to write file/path names on D lines.

Index: lib-writ.adb
===
--- lib-writ.adb(revision 203521)
+++ lib-writ.adb(working copy)
@@ -1428,7 +1428,7 @@
   Fname := Name_Find;
end if;
 
-   Write_Info_Name (Fname);
+   Write_Info_Name_May_Be_Quoted (Fname);
Write_Info_Tab (25);
Write_Info_Str (String (Time_Stamp (Sind)));
Write_Info_Char (' ');
Index: ali.adb
===
--- ali.adb (revision 203521)
+++ ali.adb (working copy)
@@ -186,9 +186,13 @@
   function Getc return Character;
   --  Get next character, bumping P past the character obtained
 
-  function Get_File_Name (Lower : Boolean := False) return File_Name_Type;
+  function Get_File_Name
+(Lower : Boolean := False;
+ May_Be_Quoted : Boolean := False) return File_Name_Type;
   --  Skip blanks, then scan out a file name (name is left in Name_Buffer
   --  with length in Name_Len, as well as returning a File_Name_Type value.
+  --  If May_Be_Quoted is True and the first non blank character is '"',
+  --  then remove starting and ending quotes and undoubled internal quotes.
   --  If lower is false, the case is unchanged, if Lower is True then the
   --  result is forced to all lower case for systems where file names are
   --  not case sensitive. This ensures that gnatbind works correctly
@@ -198,7 +202,8 @@
 
   function Get_Name
 (Ignore_Spaces  : Boolean := False;
- Ignore_Special : Boolean := False) return Name_Id;
+ Ignore_Special : Boolean := False;
+ May_Be_Quoted  : Boolean := False) return Name_Id;
   --  Skip blanks, then scan out a name (name is left in Name_Buffer with
   --  length in Name_Len, as well as being returned in Name_Id form).
   --  If Lower is set to True then the Name_Buffer will be converted to
@@ -215,6 +220,10 @@
   --an operator name starting with a double quote which is terminated
   --by another double quote.
   --
+  --If May_Be_Quoted is True and the first non blank character is '"'
+  --the name is 'unquoted'. In this case Ignore_Special is ignored and
+  --assumed to be True.
+  --
   --  It is an error to set both Ignore_Spaces and Ignore_Special to True.
   --  This function handles wide characters properly.
 
@@ -450,12 +459,14 @@
   ---
 
   function Get_File_Name
-(Lower : Boolean := False) return File_Name_Type
+(Lower : Boolean := False;
+ May_Be_Quoted : Boolean := False) return File_Name_Type
   is
  F : Name_Id;
 
   begin
- F := Get_Name (Ignore_Special => True);
+ F := Get_Name (Ignore_Special => True,
+May_Be_Quoted  => May_Be_Quoted);
 
  --  Convert file name to all lower case if file names are not case
  --  sensitive. This ensures that we handle names in the canonical
@@ -475,8 +486,11 @@
 
   function Get_Name
 (Ignore_Spaces  : Boolean := False;
- Ignore_Special : Boolean := False) return Name_Id
+ Ignore_Special : Boolean := False;
+ May_Be_Quoted  : Boolean := False) return Name_Id
   is
+ Char : Character;
+
   begin
  Name_Len := 0;
  Skip_Space;
@@ -489,38 +503,79 @@
 end if;
  end if;
 
- loop
-Add_Char_To_Name_Buffer (Getc);
+ Char := Getc;
 
-exit when At_End_Of_Field and then not Ignore_Spaces;
+ --  Deal with quoted characters
 
-if not Ignore_Special then
-   if Name_Buffer (1) = '"' then
-  exit when Name_Le

[Ada] Option to ignore unrecognized style/warning/validity switches

[Arnaud Charlet]

This implements the -gnateu switch which causes subsequent unrecognized
style (-gnaty), warning (-gnatw), and validity (-gnatV) switches to be
ignored generating a warning message only. This is useful when compiling
a set of sources developed with a later version of the compiler using an
earlier version of the compiler (of course this earlier version must
implement the -gnateu switch).

Tested on x86_64-pc-linux-gnu, committed on trunk

2013-10-14  Robert Dewar  

* gnat_ugn.texi: Document -gnateu switch.
* opt.ads (Ignore_Unrecognized_VWY_Switches): New switch.
* stylesw.adb: Ignore unrecognized switch if
Ignore_Unrecognized_VWY_Switches set.
* switch-c.adb: Implement -gnateu (sets
Ignore_Unrecognized_VWY_Switches).
* validsw.adb: Ignore unrecognized switch if
Ignore_Unrecognized_VWY_Switches set.
* warnsw.adb: Ignore unrecognized switch if
Ignore_Unrecognized_VWY_Switches set.

Index: switch-c.adb
===
--- switch-c.adb(revision 203521)
+++ switch-c.adb(working copy)
@@ -717,6 +717,12 @@
 
  return;
 
+  --  -gnateu (unrecognized y,V,w switches)
+
+  when 'u' =>
+ Ptr := Ptr + 1;
+ Ignore_Unrecognized_VWY_Switches := True;
+
   --  -gnateV (validity checks on parameters)
 
   when 'V' =>
Index: gnat_ugn.texi
===
--- gnat_ugn.texi   (revision 203526)
+++ gnat_ugn.texi   (working copy)
@@ -3829,6 +3829,14 @@
 @cindex @option{-gnatet} (@command{gcc})
 Generate target dependent information.
 
+@item -gnateu
+@cindex @option{-gnateu} (@command{gcc})
+Ignore unrecognized validity, warning, and style switches that
+apppear after this switch is given. This may be useful when
+compiling sources developed on a later version of the compiler
+with an earlier version. Of course the earlier version must
+support this switch.
+
 @item ^-gnateV^/PARAMETER_VALIDITY_CHECK^
 @cindex @option{-gnateV} (@command{gcc})
 Check validity of subprogram parameters.
Index: warnsw.adb
===
--- warnsw.adb  (revision 203521)
+++ warnsw.adb  (working copy)
@@ -25,6 +25,7 @@
 
 with Err_Vars; use Err_Vars;
 with Opt;  use Opt;
+with Output;   use Output;
 
 package body Warnsw is
 
@@ -386,7 +387,11 @@
 No_Warn_On_Non_Local_Exception  := True;
 
  when others =>
-return False;
+if Ignore_Unrecognized_VWY_Switches then
+   Write_Line ("unrecognized switch -gnatw." & C & " ignored");
+else
+   return False;
+end if;
   end case;
 
   return True;
@@ -672,6 +677,11 @@
 Warn_On_Unchecked_Conversion:= False;
 
  when others =>
+if Ignore_Unrecognized_VWY_Switches then
+   Write_Line ("unrecognized switch -gnatw" & C & " ignored");
+else
+   return False;
+end if;
 return False;
   end case;
 
Index: stylesw.adb
===
--- stylesw.adb (revision 203521)
+++ stylesw.adb (working copy)
@@ -25,6 +25,7 @@
 
 with Hostparm; use Hostparm;
 with Opt;  use Opt;
+with Output;   use Output;
 
 package body Stylesw is
 
@@ -466,9 +467,13 @@
null;
 
 when others =>
-   Err_Col := Err_Col - 1;
-   Bad_Style_Switch ("invalid style switch: " & C);
-   return;
+   if Ignore_Unrecognized_VWY_Switches then
+  Write_Line ("unrecognized switch -gnaty" & C & " ignored");
+   else
+  Err_Col := Err_Col - 1;
+  Bad_Style_Switch ("invalid style switch: " & C);
+  return;
+   end if;
 end case;
 
  --  Turning switches off
@@ -571,9 +576,13 @@
null;
 
 when others =>
-   Err_Col := Err_Col - 1;
-   Bad_Style_Switch ("invalid style switch: " & C);
-   return;
+   if Ignore_Unrecognized_VWY_Switches then
+  Write_Line ("unrecognized switch -gnaty-" & C & " ignored");
+   else
+  Err_Col := Err_Col - 1;
+  Bad_Style_Switch ("invalid style switch: " & C);
+  return;
+   end if;
 end case;
  end if;
   end loop;
Index: validsw.adb
===
--- validsw.adb (revision 203521)
+++ validsw.adb (working copy)
@@ -6,7 +6,7 @@
 --  --
 -- B o d y   

[Ada] Makes the exception type a little bit more general

[Arnaud Charlet]

The OpenVMS specific component Import_Code is replaced by Foreign_Data.
Although the size of the component is not the same, due to alignment constraint
of the component before and after, the size of the record doesn't change.
Furthermore, this component is never used by the code generated for gnat1 or
gnatbind, so there is no bootstrap issue.

No functional change, so no new testcase.

Tested on x86_64-pc-linux-gnu, committed on trunk

2013-10-14  Tristan Gingold  

* cstand.adb (Create_Standard): Change Import_Code component
of Standard_Exception_Type to Foreign_Data. Its type is now
Standard_A_Char (access to character).
* exp_prag.adb (Expand_Pragma_Import_Export_Exception): Adjust
definition of Code to match the type of Foreign_Data.
* s-stalib.ads (Exception_Data): Replace Import_Code by Foreign_Data
Change the definition of standard predefined exceptions.
(Exception_Code): Remove.
* raise.h (Exception_Code): Remove (Exception_Data): Replace
Import_Code field by Foreign_Data.
* rtsfind.ads (RE_Exception_Code): Remove
(RE_Import_Address): Add.
* a-exexpr-gcc.adb (Import_Code_For): Replaced by Foreign_Data_For.
* exp_ch11.adb (Expand_N_Exception_Declaration): Associate null
to Foreign_Data component.
* raise-gcc.c (Import_Code_For): Replaced by Foreign_Data_For.
(is_handled_by): Add comments. Use replaced function. Change
condition so that an Ada occurrence is never handled by
Foreign_Exception.
* s-exctab.adb (Internal_Exception): Associate Null_Address to
Foreign_Data component.
* s-vmexta.adb, s-vmexta.ads (Exception_Code): Declare Replace
SSL.Exception_Code by Exception_Code.

Index: exp_prag.adb
===
--- exp_prag.adb(revision 203534)
+++ exp_prag.adb(working copy)
@@ -646,8 +646,9 @@
  --  alias to define the symbol.
 
  Code :=
-   Make_Integer_Literal (Loc,
- Intval => Exception_Code (Id));
+   Unchecked_Convert_To (Standard_A_Char,
+ Make_Integer_Literal (Loc,
+   Intval => Exception_Code (Id)));
 
  --  Declare a dummy object
 
@@ -655,7 +656,7 @@
Make_Object_Declaration (Loc,
  Defining_Identifier => Excep_Internal,
  Object_Definition   =>
-   New_Reference_To (RTE (RE_Exception_Code), Loc));
+   New_Reference_To (RTE (RE_Address), Loc));
 
  Insert_Action (N, Excep_Object);
  Analyze (Excep_Object);
@@ -711,13 +712,12 @@
 
   else
  Code :=
-Unchecked_Convert_To (RTE (RE_Exception_Code),
-  Make_Function_Call (Loc,
-Name =>
-  New_Reference_To (RTE (RE_Import_Value), Loc),
-Parameter_Associations => New_List
-  (Make_String_Literal (Loc,
-Strval => Excep_Image;
+Make_Function_Call (Loc,
+  Name =>
+New_Reference_To (RTE (RE_Import_Address), Loc),
+  Parameter_Associations => New_List
+(Make_String_Literal (Loc,
+  Strval => Excep_Image)));
   end if;
 
   --  Generate the call to Register_VMS_Exception
@@ -733,7 +733,7 @@
 Prefix => New_Occurrence_Of (Id, Loc),
 Attribute_Name => Name_Unrestricted_Access);
 
-  Analyze_And_Resolve (Code, RTE (RE_Exception_Code));
+  Analyze_And_Resolve (Code, RTE (RE_Address));
   Analyze (Call);
end if;
 
Index: raise.h
===
--- raise.h (revision 203521)
+++ raise.h (working copy)
@@ -6,7 +6,7 @@
  *  *
  *  C Header File   *
  *  *
- *  Copyright (C) 1992-2012, Free Software Foundation, Inc. *
+ *  Copyright (C) 1992-2013, Free Software Foundation, Inc. *
  *  *
  * GNAT is free software;  you can  redistribute it  and/or modify it under *
  * terms of the  GNU General Public License as published  by the Free Soft- *
@@ -35,15 +35,14 @@
 
 /* C counterparts of wha

[Ada] Better handling of controlled objects in conditional expressions

[Arnaud Charlet]

A call to a function that returns a controlled object generates finalization
actions that must be placed in the code immediately after use of the object.
This patch fixes a bug in the handling of these actions when the context of
the function call is a generated if-expression.

Executing:

gnatmake -gnatE -q main
main

must yield:

True

---
with Ada.Text_IO; use Ada.Text_IO;
with Pack;use Pack;

procedure Main is
   function Factorial (Val : Natural) return Natural is
   begin
  if Val > 1 then
 return Factorial (Val - 1) * Val;
  else
 return 1;
  end if;
   end Factorial;

begin
   if Is_Even (Factorial (2))
 or Equal (Left  => New_Ctrl,
   Right => New_Ctrl)
   then
  Put_Line ("True");
   else
  Put_Line ("False");
   end if;
end Main;
---
with Ada.Finalization; use Ada.Finalization;
package Pack is
   type Ctrl is new Controlled with record
  Id : Natural := 123;
   end record;

   function Equal (Left : Ctrl; Right : Ctrl) return Boolean;
   function Is_Even (Val : Natural) return Boolean;
   function New_Ctrl return Ctrl;
end Pack;
---
package body Pack is
   function Equal (Left : Ctrl; Right : Ctrl) return Boolean is
   begin
  return Left.Id = Right.Id;
   end Equal;

   function Is_Even (Val : Natural) return Boolean is
   begin
  return Val / 2 = 0;
   end Is_Even;

   function New_Ctrl return Ctrl is
  Result : Ctrl;
   begin
  return Result;
   end New_Ctrl;
end Pack;

Tested on x86_64-pc-linux-gnu, committed on trunk

2013-10-14  Ed Schonberg  

* exp_ch4.adb (Process_Transient_Object): If a transient scope
has already been created, use the corresponding Node_To_Be_Wrapped
as the insertion point for the controlled actions.

Index: exp_ch4.adb
===
--- exp_ch4.adb (revision 203521)
+++ exp_ch4.adb (working copy)
@@ -12159,11 +12159,22 @@
  Top : Node_Id;
 
   begin
+ --  In most cases an expression that creates a controlled object
+ --  generates a transient scope around it. If this is the case then
+ --  other controlled values can reuse it.
+
+ if Scope_Is_Transient then
+return Node_To_Be_Wrapped;
+
+ --  In some cases, such as return statements, no transient scope is
+ --  generated, in which case we have to look up in the tree to find
+ --  the proper list on which to place the transient.
+
  --  When the node is inside a case/if expression, the lifetime of any
  --  temporary controlled object is extended. Find a suitable insertion
  --  node by locating the topmost case or if expressions.
 
- if Within_Case_Or_If_Expression (N) then
+ elsif Within_Case_Or_If_Expression (N) then
 Par := N;
 Top := N;
 while Present (Par) loop

[Ada] Overlapping parameter is error not warning in Ada 2012 mode

[Arnaud Charlet]

This patch implements the required incompatible change in Ada 2012
that makes overlap of elementary parameters passed as OUT or IN OUT
an error (rather than a warning situation). It also implements the
debug flag -gnatd.E that converts this back to a warning.

The following program compiled in Ada 2012 mode gives:

 1. with Text_IO; use Text_IO;
 2. procedure OverlapWarn is
 3.procedure OW (a, b : out Integer) is
 4.begin
 5.   A := 3;
 6.   B := 3;
 7.end;
 8.X : Integer;
 9. begin
10.OW (X, X);
   |
>>> writable actual for "a" overlaps with actual for "b"

11.Put_Line (X'Img);
12. end OverlapWarn;

But if -gnatd.E is given in Ada 2012 mode, the error is a warning:

 1. with Text_IO; use Text_IO;
 2. procedure OverlapWarn is
 3.procedure OW (a, b : out Integer) is
 4.begin
 5.   A := 3;
 6.   B := 3;
 7.end;
 8.X : Integer;
 9. begin
10.OW (X, X);
   |
>>> warning: writable actual for "a" overlaps with actual for "b"

11.Put_Line (X'Img);
12. end OverlapWarn;

And the program can be executed, and outputs 3

Tested on x86_64-pc-linux-gnu, committed on trunk

2013-10-14  Robert Dewar  

* debug.adb: Document -gnatd.E.
* gnat1drv.adb (Adjust_Global_Switches): Set Error_To_Warning
if -gnatd.E set.
* opt.ads (Error_To_Warning): New switch.
* osint.adb: Minor reformatting.
* sem_warn.adb (Warn_On_Overlapping_Actuals): Overlap is error
in some cases in Ada 2012 mode (unless Error_To_Warning) is set.
* sem_warn.ads (Warn_On_Overlapping_Actuals): Document error
in Ada 2012 mode.

Index: debug.adb
===
--- debug.adb   (revision 203524)
+++ debug.adb   (working copy)
@@ -122,7 +122,7 @@
--  d.B
--  d.C  Generate concatenation call, do not generate inline code
--  d.D  SPARK strict mode
-   --  d.E
+   --  d.E  Turn selected errors into warnings
--  d.F  SPARK mode
--  d.G  Frame condition mode for gnat2why
--  d.H
@@ -581,22 +581,26 @@
--  d.w  This flag turns off the scanning of loops to detect possible
--   infinite loops.
 
+   --  d.x  No exception handlers in generated code. This causes exception
+   --   handlers to be eliminated from the generated code. They are still
+   --   fully compiled and analyzed, they just get eliminated from the
+   --   code generation step.
+
--  d.A  There seems to be a problem with ASIS if we activate the circuit
--   for reading and writing the aspect specification hash table, so
--   for now, this is controlled by the debug flag d.A. The hash table
--   is only written and read if this flag is set.
 
-   --  d.x  No exception handlers in generated code. This causes exception
-   --   handlers to be eliminated from the generated code. They are still
-   --   fully compiled and analyzed, they just get eliminated from the
-   --   code generation step.
-
--  d.C  Generate call to System.Concat_n.Str_Concat_n routines in cases
--   where we would normally generate inline concatenation code.
 
--  d.D  SPARK strict mode. Interpret compiler permissions as strictly as
--   possible in SPARK mode.
-   --
+
+   --  d.E  Turn selected errors into warnings. This debug switch causes a
+   --   specific set of error messages into warnings. Setting this switch
+   --   causes Opt.Error_To_Warning to be set to True.
+
--  d.F  SPARK mode. Generate AST in a form suitable for formal
--   verification, as well as additional cross reference information in
--   ALI files to compute effects of subprograms. Note that ALI files
Index: gnat1drv.adb
===
--- gnat1drv.adb(revision 203521)
+++ gnat1drv.adb(working copy)
@@ -117,6 +117,13 @@
  Relaxed_RM_Semantics := True;
   end if;
 
+  --  -gnatd.E sets Error_To_Warning mode, causing selected error messages
+  --  to be treated as warnings instead of errors.
+
+  if Debug_Flag_Dot_EE then
+ Error_To_Warning := True;
+  end if;
+
   --  Disable CodePeer_Mode in Check_Syntax, since we need front-end
   --  expansion.
 
Index: sem_warn.adb
===
--- sem_warn.adb(revision 203521)
+++ sem_warn.adb(working copy)
@@ -3410,13 +3410,27 @@
   then
  null;
 
-  --  Here we may need to issue message
+  --  Here we may need to issue overlap message
 
   else
  Error_Msg_Warn :=
+
+   --  Overlap checking is an error only in Ada 2012. For
+   --  earlier versio

[Ada] Comparaison of symbols to integers in preprocessing

[Arnaud Charlet]

When preprocessing a source, it is now possible to use comparaison of
symbols with integers, using operators =, <, <=, > or >=, as in:

#if symbol = 3

#if symbol <= 20

Tested on x86_64-pc-linux-gnu, committed on trunk

2013-10-14  Vincent Celier  

* prep.adb (Expression): Accept terms of the form 'symbol 
integer", where relop is =, <, <=, > or >=.
(Parse_Def_File): Accept literal integer values.
* gcc-interface/Make-lang.in: Add s-valint.o, s-valuns.o and
s-valuti.o to the compiler object files.

Index: prep.adb
===
--- prep.adb(revision 203521)
+++ prep.adb(working copy)
@@ -6,7 +6,7 @@
 --  --
 -- B o d y  --
 --  --
---  Copyright (C) 2002-2012, Free Software Foundation, Inc. --
+--  Copyright (C) 2002-2013, Free Software Foundation, Inc. --
 --  --
 -- GNAT is free software;  you can  redistribute it  and/or modify it under --
 -- terms of the  GNU General Public License as published  by the Free Soft- --
@@ -33,6 +33,7 @@
 with Sinput;
 with Stringt;  use Stringt;
 with Table;
+with Uintp;use Uintp;
 
 with GNAT.Heap_Sort_G;
 
@@ -268,9 +269,14 @@
 
  --  Check the syntax of the value
 
- if Definition (Index + 1) /= '"'
-   or else Definition (Definition'Last) /= '"'
+ if Definition (Index + 1) = '"'
+   and then Definition (Definition'Last) = '"'
  then
+Result.Is_A_String := True;
+
+ else
+Result.Is_A_String := False;
+
 for J in Index + 1 .. Definition'Last loop
case Definition (J) is
   when '_' | '.' | '0' .. '9' | 'a' .. 'z' | 'A' .. 'Z' =>
@@ -286,7 +292,6 @@
 
  --  And put the value in the result
 
- Result.Is_A_String := False;
  Start_String;
  Store_String_Chars (Definition (Index + 1 .. Definition'Last));
  Result.Value := End_String;
@@ -390,6 +395,8 @@
   Symbol_Value1: String_Id;
   Symbol_Value2: String_Id;
 
+  Relop : Token_Type;
+
begin
   --  Loop for each term
 
@@ -447,13 +454,97 @@
  Current_Result := Index_Of (Symbol_Name1) /= No_Symbol;
   end if;
 
-   elsif Token = Tok_Equal then
+   elsif
+ Token = Tok_Equal or else
+ Token = Tok_Less or else
+ Token = Tok_Less_Equal or else
+ Token = Tok_Greater or else
+ Token = Tok_Greater_Equal
+   then
+  Relop := Token;
   Scan.all;
-
   Change_Reserved_Keyword_To_Symbol;
 
-  if Token = Tok_Identifier then
+  if Token = Tok_Integer_Literal then
 
+ --  symbol =  integer
+ --  symbol <  integer
+ --  symbol <= integer
+ --  symbol >  integer
+ --  symbol >= integer
+
+ declare
+Value : constant Int := UI_To_Int (Int_Literal_Value);
+Data  : Symbol_Data;
+Symbol_Value : Int;
+ begin
+if Evaluation then
+   Symbol1 := Index_Of (Symbol_Name1);
+
+   if Symbol1 = No_Symbol then
+  Error_Msg_Name_1 := Symbol_Name1;
+  Error_Msg ("unknown symbol %", Symbol_Pos1);
+  Symbol_Value1 := No_String;
+
+   else
+  Data := Mapping.Table (Symbol1);
+
+  if Data.Is_A_String then
+ Error_Msg_Name_1 := Symbol_Name1;
+ Error_Msg
+   ("symbol % value is not integer",
+Symbol_Pos1);
+
+  else
+ begin
+String_To_Name_Buffer (Data.Value);
+Symbol_Value :=
+  Int'Value (Name_Buffer (1 .. Name_Len));
+
+case Relop is
+   when Tok_Equal =>
+  Current_Result :=
+Symbol_Value = Value;
+
+   when Tok_Less =>
+  Current_Result :=
+  

[Ada] Library_Level attribute now applies to an entity name

[Arnaud Charlet]

The prefix of the Library_Level must now be an entity name, and the
attribute indicates if the entity is declarated at the library level.
Note that within a generic instantition, the name of the generic unit
denotes the instance, which means that this attribute can be used to
test if a generic is instantiated at the library level, as in:

 1. generic
 2. package LLTestP is
 3.pragma Compile_Time_Warning
 4.  (not LLTestP'Library_Level,
 5.   "LLTest should be instantiated at library level");
 6. end;

 1. with LLTestP;
 2. package LLTestP1 is
 3.package P is new LLTestP;
 4.XXX : Integer;
 5.P1L : constant Boolean := XXX'Library_Level;
 6. end;

 1. with LLTestP;
 2. with LLTestP1; use LLTestP1;
 3. with Text_IO; use Text_IO;
 4. procedure LLTest is
 5.package P1 is new LLTestP;
   |
>>> warning: in instantiation at lltestp.ads:4
>>> warning: LLTest should be instantiated at library level

 6.X : Integer;
   |
>>> warning: variable "X" is read but never assigned

 7. begin
 8.Put_Line (Boolean'Image (LLTest'Library_Level));
 9.Put_Line (Boolean'Image (P1L));
10.Put_Line (Boolean'Image (X'Library_Level));
11. end;

When executed, the output is:

TRUE
TRUE
FALSE

Tested on x86_64-pc-linux-gnu, committed on trunk

2013-10-14  Robert Dewar  

* gnat_rm.texi: Library_Level attribute now applies to an
entity name.
* sem_attr.adb (Analyze_Attribute, case Library_Level): Prefix
is now an entity name.

Index: gnat_rm.texi
===
--- gnat_rm.texi(revision 203528)
+++ gnat_rm.texi(working copy)
@@ -8348,21 +8348,20 @@
 @findex Library_Level
 @noindent
 @noindent
-@code{Standard'Library_Level} (@code{Standard} is the only allowed
-prefix) returns a Boolean value which is True if the attribute is
-evaluated at the library level (e.g. with a package declaration),
-and false if evaluated elsewhere (e.g. within a subprogram body).
-In the case of generics, the value indicates the placement of
-the instantiation, not the template, and indeed the use of this
-attribute within a generic is the intended common application
-as shown in this example:
+@code{P'Library_Level}, where P is an entity name,
+returns a Boolean value which is True if the entity is declared
+at the library level, and False otherwise. Note that within a
+generic instantition, the name of the generic unit denotes the
+instance, which means that this attribute can be used to test
+if a generic is instantiated at the library level, as shown
+in this example:
 
 @smallexample @c ada
 generic
   ...
 package Gen is
   pragma Compile_Time_Error
-(not Standard'Library_Level,
+(not Gen'Library_Level,
  "Gen can only be instantiated at library level");
   ...
 end Gen;
Index: sem_attr.adb
===
--- sem_attr.adb(revision 203528)
+++ sem_attr.adb(working copy)
@@ -3689,11 +3689,14 @@
 
   when Attribute_Library_Level =>
  Check_E0;
- Check_Standard_Prefix;
 
+ if not Is_Entity_Name (P) then
+Error_Attr_P ("prefix of % attribute must be an entity name");
+ end if;
+
  if not Inside_A_Generic then
 Set_Boolean_Result (N,
-  Nearest_Dynamic_Scope (Current_Scope) = Standard_Standard);
+  Is_Library_Level_Entity (Entity (P)));
  end if;
 
  Set_Etype (N, Standard_Boolean);

[Ada] State refinement constituent uninstall

[Arnaud Charlet]

This patch hides the refinement constituents of all abstract states with
visible refinement at the end of the package body declarations.

Tested on x86_64-pc-linux-gnu, committed on trunk

2013-10-14  Hristian Kirtchev  

* einfo.adb: Flag 263 is now known as Has_Visible_Refinement.
(Has_Non_Null_Refinement): New routine.
(Has_Null_Refinement): The routine is now synthesized.
(Has_Visible_Refinement): New routine.
(Set_Has_Visible_Refinement): New routine.
(Write_Entity_Flags): Remove the output for
Has_Null_Refinement. Add output for Has_Visible_Refinement.
* einfo.ads: Update the occurrences of Has_Non_Null_Refinement,
Has_Null_Refinement and Has_Visible_Refinement in entities.
(Has_Non_Null_Refinement): New synthesized attribute.
(Has_Null_Refinement): This attribute is now synthesized.
(Has_Visible_Refinement): New routine with corresponding
pragma Inline.
(Set_Has_Visible_Refinement): New routine with corresponding pragma
Inline.
* sem_ch3.adb (Analyze_Declarations): Add new local
variable In_Package_Body. Remove state refinements from
visibility at the end of the package body declarations.
(Remove_Visible_Refinements): New routine.
* sem_prag.adb (Analyze_Constituent): Collect a null
constituent and mark the state as having visible refinement.
(Analyze_Global_Item): Use attribute Has_Visible_Refinement to
detect a state with visible refinement.
(Analyze_Input_Output): Use attribute Has_Visible_Refinement to detect
a state with visible refinement.
(Check_Dependency_Clause): Use attribute Has_Non_Null_Refinement rather
than checking the contents of list Refinement_Constituents.
(Check_In_Out_States): Use attribute Has_Non_Null_Refinement rather
than checking the contents of list Refinement_Constituents.
(Check_Input_States): Use attribute Has_Non_Null_Refinement rather
than checking the contents of list Refinement_Constituents.
(Check_Matching_Constituent): Mark a state as having visible refinement.
(Check_Output_States): Use attribute Has_Non_Null_Refinement rather than
checking the contents of list Refinement_Constituents.
(Check_Refined_Global_Item): Use attribute Has_Visible_Refinement
to detect a state with visible refinement.
(Is_Matching_Input): Use attribute Has_Non_Null_Refinement rather than
checking the contents of list Refinement_Constituents.
* sem_util.adb (Is_Refined_State): Use attribute
Has_Visible_Refinement to detect a state with visible refinement.

Index: sem_ch3.adb
===
--- sem_ch3.adb (revision 203531)
+++ sem_ch3.adb (working copy)
@@ -2067,6 +2067,11 @@
   --  (They have the sloc of the label as found in the source, and that
   --  is ahead of the current declarative part).
 
+  procedure Remove_Visible_Refinements (Spec_Id : Entity_Id);
+  --  Spec_Id is the entity of a package that may define abstract states.
+  --  If the states have visible refinement, remove the visibility of each
+  --  constituent at the end of the package body declarations.
+
   -
   -- Adjust_Decl --
   -
@@ -2080,6 +2085,24 @@
  end loop;
   end Adjust_Decl;
 
+  
+  -- Remove_Visible_Refinements --
+  
+
+  procedure Remove_Visible_Refinements (Spec_Id : Entity_Id) is
+ State_Elmt : Elmt_Id;
+
+  begin
+ if Present (Abstract_States (Spec_Id)) then
+State_Elmt := First_Elmt (Abstract_States (Spec_Id));
+while Present (State_Elmt) loop
+   Set_Has_Visible_Refinement (Node (State_Elmt), False);
+
+   Next_Elmt (State_Elmt);
+end loop;
+ end if;
+  end Remove_Visible_Refinements;
+
   --  Local variables
 
   Body_Id : Entity_Id;
@@ -2089,6 +2112,9 @@
   Prag: Node_Id;
   Spec_Id : Entity_Id;
 
+  In_Package_Body : Boolean := False;
+  --  Flag set when the current declaration list belongs to a package body
+
--  Start of processing for Analyze_Declarations
 
begin
@@ -2220,6 +2246,8 @@
  --  Refined_Global because the last two may mention constituents.
 
  elsif Nkind (Context) = N_Package_Body then
+In_Package_Body := True;
+
 Body_Id := Defining_Entity (Context);
 Spec_Id := Corresponding_Spec (Context);
 Prag:= Get_Pragma (Body_Id, Pragma_Refined_State);
@@ -2256,6 +2284,14 @@
 
  Next (Decl);
   end loop;
+
+  --  State refinements are visible upto the end the of the package body
+  --  declarations. Hide the refinements from visibility to re

[Ada] Imported C++ exceptions

[Arnaud Charlet]

It is now possible to import C++ exceptions and to handle it.
The following program will display: Got Cpp exception
It can be built using the following project file:

project except is
  for Languages use ("Ada", "C++");
  for Main use ("main.adb");
end except;

package Cppexcept is
   Cpp_Int_Exception : exception;
   pragma Import (Cpp, Cpp_Int_Exception, "_ZTIi");
end Cppexcept;

with Ada.Text_IO; use Ada.Text_IO;
with Ada.Exceptions; use Ada.Exceptions;
with Cppexcept; use Cppexcept;

procedure Main is
   procedure Raise_Excep_Int;
   pragma Import (C, Raise_Excep_Int);
   --  Raise a Cpp exception
begin
   Raise_Excep_Int;
exception
   when Cpp_Int_Exception =>
  Put_Line ("Got Cpp exception");
   when X: others =>
  Put_Line ("Err, got unexpected exception: "
& Exception_Information (X));
end Main;

extern "C" void raise_excep_int (void)
{
  throw 2;
}

Tested on x86_64-pc-linux-gnu, committed on trunk

2013-10-14  Tristan Gingold  

* sem_prag.adb (Process_Import_Or_Interface): Allow importing
of exception using convention Cpp.
* exp_prag.adb (Expand_Pragma_Import_Or_Interface): Expand cpp
imported exceptions.
* raise-gcc.c (is_handled_by): Filter C++ exception occurrences.
* gnat_rm.texi: Document how to import C++ exceptions.

Index: exp_prag.adb
===
--- exp_prag.adb(revision 203544)
+++ exp_prag.adb(working copy)
@@ -575,6 +575,64 @@
  if No (Init_Call) and then Present (Expression (Parent (Def_Id))) then
 Set_Expression (Parent (Def_Id), Empty);
  end if;
+  elsif Ekind (Def_Id) = E_Exception
+and then Convention (Def_Id) = Convention_CPP
+  then
+
+ --  Import a C++ convention
+
+ declare
+Loc: constant Source_Ptr := Sloc (N);
+Exdata : List_Id;
+Lang_Char  : Node_Id;
+Foreign_Data   : Node_Id;
+Rtti_Name  : constant Node_Id := Arg3 (N);
+Dum: constant Entity_Id  := Make_Temporary (Loc, 'D');
+
+ begin
+Exdata := Component_Associations (Expression (Parent (Def_Id)));
+
+Lang_Char := Next (First (Exdata));
+
+--  Change the one-character language designator to 'C'
+
+Rewrite (Expression (Lang_Char),
+  Make_Character_Literal (Loc,
+Chars => Name_uC,
+Char_Literal_Value =>
+  UI_From_Int (Character'Pos ('C';
+Analyze (Expression (Lang_Char));
+
+--  Change the value of Foreign_Data
+
+Foreign_Data := Next (Next (Next (Next (Lang_Char;
+
+Insert_Actions (Def_Id, New_List (
+  Make_Object_Declaration (Loc,
+Defining_Identifier => Dum,
+Object_Definition   =>
+  New_Occurrence_Of (Standard_Character, Loc)),
+
+  Make_Pragma (Loc,
+Chars=> Name_Import,
+Pragma_Argument_Associations => New_List (
+  Make_Pragma_Argument_Association (Loc,
+Expression => Make_Identifier (Loc, Name_Ada)),
+
+  Make_Pragma_Argument_Association (Loc,
+Expression => Make_Identifier (Loc, Chars (Dum))),
+
+  Make_Pragma_Argument_Association (Loc,
+Chars => Name_Link_Name,
+Expression => Relocate_Node (Rtti_Name));
+
+Rewrite (Expression (Foreign_Data),
+  Unchecked_Convert_To (Standard_A_Char,
+Make_Attribute_Reference (Loc,
+  Prefix => Make_Identifier (Loc, Chars (Dum)),
+  Attribute_Name => Name_Address)));
+Analyze (Expression (Foreign_Data));
+ end;
   end if;
end Expand_Pragma_Import_Or_Interface;
 
Index: gnat_rm.texi
===
--- gnat_rm.texi(revision 203543)
+++ gnat_rm.texi(working copy)
@@ -11963,6 +11963,7 @@
 @emph{Exception_Name:} n
 @emph{Message:} m
 @emph{PID:} ppp
+@emph{Load address:} 0x
 @emph{Call stack traceback locations:}
 0x 0x 0x ... 0xhhh
 @end smallexample
@@ -11984,10 +11985,12 @@
 not making use of this field.
 
 @item
-The Call stack traceback locations line and the following values
-are present only if at least one traceback location was recorded.
-The values are given in C style format, with lower case letters
-for a-f, and only as many digits present as are necessary.
+The Load address line, the Call stack traceback locations line and the
+following values are present only if at least one traceback location was
+recorded. The Load address indicates the address at which the main executable
+was loaded; this line may not be present if operating syst

[Ada] Missing errors in the body of a protected function

[Arnaud Charlet]

In the body of a protected function, the protected object itself is a constant
(not just its components).

Compiling p.adb must yield:

   p.adb:12:20: actual for "It" must be a variable
   p.adb:18:17: actual for "It" must be a variable

procedure P is
   protected type Prot is
  function F return integer;
   private
  buffer : String (1 .. 100);
   end;
   procedure Stack_it (It : in out Prot) is begin null; end;

   protected body Prot is
  function F return integer is
  begin
 Stack_it (prot);  -- ERROR
 return 15;
  end;
   end Prot;
   procedure Wrapper (It : Prot) is
   begin
  Stack_It (It);  -- ERROR
   end;
begin
   null;
end;

Tested on x86_64-pc-linux-gnu, committed on trunk

2013-10-14  Ed Schonberg  

* sem_util.adb (Is_Variable, In_Protected_Function):  In the
body of a protected function, the protected object itself is a
constant (not just its components).

Index: sem_util.adb
===
--- sem_util.adb(revision 203546)
+++ sem_util.adb(working copy)
@@ -10198,7 +10198,8 @@
   function In_Protected_Function (E : Entity_Id) return Boolean;
   --  Within a protected function, the private components of the enclosing
   --  protected type are constants. A function nested within a (protected)
-  --  procedure is not itself protected.
+  --  procedure is not itself protected. Within the body of a protected
+  --  function the current instance of the protected type is a constant.
 
   function Is_Variable_Prefix (P : Node_Id) return Boolean;
   --  Prefixes can involve implicit dereferences, in which case we must
@@ -10210,12 +10211,24 @@
   ---
 
   function In_Protected_Function (E : Entity_Id) return Boolean is
- Prot : constant Entity_Id := Scope (E);
+ Prot : Entity_Id;
  S: Entity_Id;
 
   begin
+ if Is_Type (E) then
+--  E is the current instance of a type.
+
+Prot := E;
+
+ else
+--  E is an object.
+
+Prot := Scope (E);
+ end if;
+
  if not Is_Protected_Type (Prot) then
 return False;
+
  else
 S := Current_Scope;
 while Present (S) and then S /= Prot loop
@@ -10336,9 +10349,14 @@
   or else  K = E_In_Out_Parameter
   or else  K = E_Generic_In_Out_Parameter
 
-   --  Current instance of type
+   --  Current instance of type. If this is a protected type, check
+   --  that we are not within the body of one of its protected
+   --  functions.
 
-  or else (Is_Type (E) and then In_Open_Scopes (E))
+  or else (Is_Type (E)
+and then In_Open_Scopes (E)
+and then not In_Protected_Function (E))
+
   or else (Is_Incomplete_Or_Private_Type (E)
 and then In_Open_Scopes (Full_View (E)));
  end;

[Ada] Aspect Initial_Condition

[Arnaud Charlet]

This patch provides the initial implementation of aspect/pragma
Initial_Condition. This construct is intended for formal verification proofs.

The construct has the following syntax:

   pragma Initial_Condition (boolean_EXPRESSION);

The construct has the following semantic rules:

The Initial_Condition aspect is introduced by an aspect_specification where the
aspect_mark is Initial_Condition and the aspect_definition shall be a boolean
expression.

An Initial_Condition aspect shall only be placed in an aspect_specification of
a package_specification.

Each variable or state abstraction denoted in an Initial_Condition aspect of a
package Q which is declared immediately within the visible part of Q shall be
initialized during the elaboration of Q and be denoted by a name of an
initialization_item of the Initializes aspect of Q.

An Initial_Condition aspect is a sort of postcondition for the elaboration of
both the specification and body of a package. If present on a package, then its
Boolean_expression defines properties (a predicate) of the state of the package
which can be assumed to be true immediately following the elaboration of the
package. [The expression of the Initial_Condition cannot denote a state
abstraction. This means that to express properties of hidden state, functions
declared in the visible part acting on the state abstractions of the package
must be used.]

With respect to dynamic semantics, specifying a given expression as the
Initial_Condition aspect of a package is equivalent to specifying that
expression as the argument of an Assert pragma occurring at the end of the
(possibly implicit) statement list of the (possibly implicit) body of the
package. [This equivalence includes all interactions with pragma
Assertion_Policy. This equivalence does not extend to matters of static
semantics, such as name resolution.] An Initial_Condition expression does not
cause freezing until the point where it is evaluated [, at which point
everything that it might freeze has already been frozen].


-- Source --


--  semantics.ads

package Semantics
   with Abstract_State=>  State,
Initializes   => (State, Var_1, Var_2),
Initial_Condition => (Var_1 = 1 and then Var_2 = 0)
is
   Var_1 : Integer;
   Var_2 : Integer;

   package Error_1
 with Initial_Condition => (Var_3 > 0)  --  no Initializes
   is
  Var_3 : Integer;
   end Error_1;

   package Error_2
 with Initializes   => (Var_4, Var_5),
  Initial_Condition => (Var_4 = 0)  --  Var_5 missing
   is
  Var_4 : Integer;
  Var_5 : Integer;
   end Error_2;

end Semantics;

--  exec_body_ok2.ads

package Exec_Body_OK2
  with Initializes   => Var,
   Initial_Condition => (Var = 123)
is
   Var : Integer := 0;
   procedure Dummy;
end Exec_Body_OK2;

--  exec_body_ok2.adb

package body Exec_Body_OK2 is
   procedure Dummy is begin null; end Dummy;
begin
   Var := 123;
end Exec_Body_OK2;

--  runtime_ok.adb

with Exec_Body_OK2;

procedure Runtime_OK is begin null; end Runtime_OK;

--  exec_spec_error.ads

package Exec_Spec_Error
  with Initializes   => Var,
   Initial_Condition => (Var = 123)
is
   Var : Integer := 0;  --  not 123
end Exec_Spec_Error;

--  runtime_error2.adb

with Exec_Spec_Error;

procedure Runtime_Error2 is begin null; end Runtime_Error2;


-- Compilation and output --


$ gcc -c -gnatd.V semantics.ads
$ gnatmake -q -gnata -gnatd.V runtime_ok.adb
$ gnatmake -q -gnata -gnatd.V runtime_error2.adb
$ ./runtime_ok
$ ./runtime_error2.adb
semantics.ads:10:11: "Initial_Condition" requires the presence of aspect or
  pragma "Initializes"
semantics.ads:17:11: expression of "Initial_Condition" must mention the
  following variables
semantics.ads:17:11:   "Var_5" declared at line 20
raised SYSTEM.ASSERTIONS.ASSERT_FAILURE : Initial_Condition failed at
  exec_spec_error.ads:3

Tested on x86_64-pc-linux-gnu, committed on trunk

2013-10-14  Hristian Kirtchev  

* aspects.adb: Add an entry in table Canonical_Aspect for
Initial_Condition.
* aspects.ads: Add entries in tables Aspect_Id, Aspect_Argument,
Aspect_Names and Aspect_Delay for Initial_Condition.
* einfo.adb (Get_Pragma): Include pragma Initial_Condition to
categorization pragmas.
* einfo.ads (Get_Pragma): Update comment on usage.
* exp_ch7.adb (Expand_N_Package_Body): Add a runtime check to
verify the assertion introduced by pragma Initial_Condition.
(Expand_N_Package_Declaration): Add a runtime check to
verify the assertion introduced by pragma Initial_Condition.
(Expand_Pragma_Initial_Condition): New routine.
* par-prag: Include pragma Initial_Condition to the list of
pragmas that do not require special processing by the parser.
* sem_ch3.adb (Analyze_Declarations): Analyze pragma
Initial_Condition at the end of the visible dec

Re: [Ada] Imported C++ exceptions

[Duncan Sands]

Hi Arnaud,

On 14/10/13 15:29, Arnaud Charlet wrote:

It is now possible to import C++ exceptions and to handle it.

...

Index: exp_prag.adb
===
--- exp_prag.adb(revision 203544)
+++ exp_prag.adb(working copy)
@@ -575,6 +575,64 @@
  if No (Init_Call) and then Present (Expression (Parent (Def_Id))) then
 Set_Expression (Parent (Def_Id), Empty);
  end if;
+  elsif Ekind (Def_Id) = E_Exception
+and then Convention (Def_Id) = Convention_CPP
+  then
+
+ --  Import a C++ convention


should this comment say "Import a C++ exception"?

Ciao, Duncan.

[Ada] Legality of null dependence items

[Arnaud Charlet]

This patch catches two syntax errors related to the use of null items in aspect
or pragma [Refined_]Depends. The patch also streamlines the error messages of
various aspects or pragmas that deal with null and non-null items.


-- Source --


--  depends_illegal.ads

package Depends_Illegal is
   procedure P1 (Par1 : Integer)
  with Depends => (null =>+ Par1);

   procedure P2 (Par1 : Integer ; Par2 : out Integer)
  with Depends => (Par2 => (Par1, null));
end Depends_Illegal;


-- Compilation and output --


$ gcc -c -gnatd.V depends_legal.ads
depends_illegal.ads:3:24: useless dependence, null depends on itself
depends_illegal.ads:6:39: cannot mix null and non-null dependency items

Tested on x86_64-pc-linux-gnu, committed on trunk

2013-10-14  Hristian Kirtchev  

* sem_prag.adb (Analyze_Dependency_Clause): Add new local variable
Non_Null_Output_Seen.  Update the call to Analyze_Input_Output.
(Analyze_Input_Item): Streamline the detection mechanism of null and
non-null items.
(Analyze_Input_List): Add new local variable
Non_Null_Input_Seen. Update all calls to Analyze_Input_Output.
(Analyze_Input_Output): Add new formal parameter Non_Null_Seen
and update the related comment on usage. Update the
recursive call to itself. Attribute 'Result is now treated
as a non-null item. Detect mixes of null and non-null items.
(Analyze_Initialization_Item): Streamline the detection mechanism
of null and non-null items.

Index: sem_prag.adb
===
--- sem_prag.adb(revision 203551)
+++ sem_prag.adb(working copy)
@@ -555,12 +555,13 @@
  --  Verify the legality of a single input list
 
  procedure Analyze_Input_Output
-   (Item  : Node_Id;
-Is_Input  : Boolean;
-Self_Ref  : Boolean;
-Top_Level : Boolean;
-Seen  : in out Elist_Id;
-Null_Seen : in out Boolean);
+   (Item  : Node_Id;
+Is_Input  : Boolean;
+Self_Ref  : Boolean;
+Top_Level : Boolean;
+Seen  : in out Elist_Id;
+Null_Seen : in out Boolean;
+Non_Null_Seen : in out Boolean);
  --  Verify the legality of a single input or output item. Flag
  --  Is_Input should be set whenever Item is an input, False when it
  --  denotes an output. Flag Self_Ref should be set when the item is an
@@ -568,7 +569,8 @@
  --  be set whenever Item appears immediately within an input or output
  --  list. Seen is a collection of all abstract states, variables and
  --  formals processed so far. Flag Null_Seen denotes whether a null
- --  input or output has been encountered.
+ --  input or output has been encountered. Flag Non_Null_Seen denotes
+ --  whether a non-null input or output has been encountered.
 
  
  -- Analyze_Input_List --
@@ -579,8 +581,9 @@
 --  A list containing the entities of all inputs that appear in the
 --  current input list.
 
-Null_Input_Seen : Boolean := False;
---  A flag used to track the legality of a null input
+Non_Null_Input_Seen : Boolean := False;
+Null_Input_Seen : Boolean := False;
+--  Flags used to check the legality of an input list
 
 Input : Node_Id;
 
@@ -596,12 +599,13 @@
   Input := First (Expressions (Inputs));
   while Present (Input) loop
  Analyze_Input_Output
-   (Item  => Input,
-Is_Input  => True,
-Self_Ref  => False,
-Top_Level => False,
-Seen  => Inputs_Seen,
-Null_Seen => Null_Input_Seen);
+   (Item  => Input,
+Is_Input  => True,
+Self_Ref  => False,
+Top_Level => False,
+Seen  => Inputs_Seen,
+Null_Seen => Null_Input_Seen,
+Non_Null_Seen => Non_Null_Input_Seen);
 
  Next (Input);
   end loop;
@@ -614,12 +618,13 @@
 
 else
Analyze_Input_Output
- (Item  => Inputs,
-  Is_Input  => True,
-  Self_Ref  => False,
-  Top_Level => False,
-  Seen  => Inputs_Seen,
-  Null_Seen => Null_Input_Seen);
+ (Item  => Inputs,
+  Is_Input  => True,
+  Self_Ref  => False,
+

[Ada] Initialize choice exception parameter in gigi

[Arnaud Charlet]

The code to initialize the exception parameter is now emitted in gigi rather
than in the front-end. This applies only in the ZCX case. This is slightly
more efficient and will future implementation of intefacing with C++
exceptions.
No functional change.

Tested on x86_64-pc-linux-gnu, committed on trunk

2013-10-14  Tristan Gingold  

* a-exexpr-gcc.adb (Set_Exception_Parameter): New procedure.
(Set_Foreign_Occurrence): New procedure, extracted from
Setup_Current_Excep.
* exp_ch11.adb (Expand_Exception_Handlers): Do not expand choice
parameter in case of zcx.
* sem_ch11.adb (Analyze_Exception_Handlers): Need debug info
for the choice parameter.
* raise-gcc.c: Add comments.

Index: a-exexpr-gcc.adb
===
--- a-exexpr-gcc.adb(revision 203538)
+++ a-exexpr-gcc.adb(working copy)
@@ -199,13 +199,14 @@
  (GCC_Exception : not null GCC_Exception_Access);
pragma No_Return (Reraise_GCC_Exception);
pragma Export (C, Reraise_GCC_Exception, "__gnat_reraise_zcx");
-   --  Called to implement raise without exception, ie reraise.  Called
+   --  Called to implement raise without exception, ie reraise. Called
--  directly from gigi.
 
function Setup_Current_Excep
  (GCC_Exception : not null GCC_Exception_Access) return EOA;
pragma Export (C, Setup_Current_Excep, "__gnat_setup_current_excep");
-   --  Write Get_Current_Excep.all from GCC_Exception
+   --  Write Get_Current_Excep.all from GCC_Exception. Called by the
+   --  personnality routine.
 
procedure Unhandled_Except_Handler
  (GCC_Exception : not null GCC_Exception_Access);
@@ -243,6 +244,17 @@
   UW_Argument  : System.Address);
pragma Import (C, Unwind_ForcedUnwind, "__gnat_Unwind_ForcedUnwind");
 
+   procedure Set_Exception_Parameter
+ (Excep : EOA;
+  GCC_Exception : not null GCC_Exception_Access);
+   pragma Export (C, Set_Exception_Parameter,
+"__gnat_set_exception_parameter");
+   --  Called inserted by gigi to initialize the exception parameter
+
+   procedure Set_Foreign_Occurrence (Excep : EOA; Mo : System.Address);
+   --  Utility routine to initialize occurrence Excep for a foreign exception
+   --  whose machine occurrence is Mo.
+
--  Hooks called when entering/leaving an exception handler for a given
--  occurrence, aimed at handling the stack of active occurrences. The
--  calls are generated by gigi in tree_transform/N_Exception_Handler.
@@ -338,6 +350,20 @@
   Free (Copy);
end GNAT_GCC_Exception_Cleanup;
 
+   
+   -- Set_Foreign_Occurrence --
+   
+
+   procedure Set_Foreign_Occurrence (Excep : EOA; Mo : System.Address) is
+   begin
+  Excep.Id := Foreign_Exception'Access;
+  Excep.Machine_Occurrence := Mo;
+  Excep.Msg_Length := 0;
+  Excep.Exception_Raised := True;
+  Excep.Pid := Local_Partition_ID;
+  Excep.Num_Tracebacks := 0;
+   end Set_Foreign_Occurrence;
+
-
-- Setup_Current_Excep --
-
@@ -366,12 +392,7 @@
 
  --  A default one
 
- Excep.Id := Foreign_Exception'Access;
- Excep.Machine_Occurrence := GCC_Exception.all'Address;
- Excep.Msg_Length := 0;
- Excep.Exception_Raised := True;
- Excep.Pid := Local_Partition_ID;
- Excep.Num_Tracebacks := 0;
+ Set_Foreign_Occurrence (Excep, GCC_Exception.all'Address);
 
  return Excep;
   end if;
@@ -465,6 +486,34 @@
   Propagate_GCC_Exception (To_GCC_Exception (Excep.Machine_Occurrence));
end Propagate_Exception;
 
+   -
+   -- Set_Exception_Parameter --
+   -
+
+   procedure Set_Exception_Parameter
+ (Excep : EOA;
+  GCC_Exception : not null GCC_Exception_Access) is
+   begin
+  --  Setup the exception occurrence
+
+  if GCC_Exception.Class = GNAT_Exception_Class then
+
+ --  From the GCC exception
+
+ declare
+GNAT_Occurrence : constant GNAT_GCC_Exception_Access :=
+  To_GNAT_GCC_Exception (GCC_Exception);
+ begin
+Save_Occurrence (Excep.all, GNAT_Occurrence.Occurrence);
+ end;
+  else
+
+ --  A default one
+
+ Set_Foreign_Occurrence (Excep, GCC_Exception.all'Address);
+  end if;
+   end Set_Exception_Parameter;
+
--
-- Unhandled_Except_Handler --
--
Index: exp_ch11.adb
===
--- exp_ch11.adb(revision 203539)
+++ exp_ch11.adb(working copy)
@@ -1025,7 +1025,12 @@
--...
-- end;
 
-   if Present (Choice_Parameter (Handler)) then
+   --  This expansion is not performed when using GCC ZCX. 

Re: [PATCH] Workaround errata for the PMC-Sierra RM7000 cpu.

[Maciej W. Rozycki]

On Thu, 10 Oct 2013, Richard Sandiford wrote:

> Ideally opcodes/mips*.c would have a flag to mark load instructions,
> but all we have at the moment are flags to mark load delays, which means
> that LD and some other load instructions don't have them.  So I can think
> of three options:
> 
> (1) Turn INSN_LOAD_MEMORY_DELAY into INSN_LOAD_GPR and
> INSN_COPRO_MEMORY_DELAY into INSN_LOAD_COPRO.  Add the flags to all
> loads in the opcode table that don't currently have one.
> 
> This would be the best approach, but I can understand why it might
> seem like too much effort.

 I second this suggestion, except that I'd leave INSN_COPRO_MEMORY_DELAY 
alone at this time.  Otherwise we'd be hitting the grey area of the MT 
ASE's MFTR instruction for no real use (yes, you can use it to read self).  
I think the big issue here will be identifying all the exotic memory load 
instructions vendors may have invented (anything starting with `L' is an 
obvious candidate, but there are other cases too, e.g. all the SWAP* 
stuff; the presence of `b' among the operand specifiers can help, however 
is not a guarantee either way), but otherwise it's a pure mechanical `sed' 
(or equivalent) application.

  Maciej

Re: RFA: Switch on LRA on ARM (AArch32)

[Richard Earnshaw]

On 14/10/13 08:27, Yvan Roux wrote:
> Hi,
> 
> The status of LRA support for AArch32 is the sequel :
> - there is some regressions in the testsuite (gcc/g++, libstdc++ and
> fortran) in ARM mode, all due to the same neon legitimate address
> issue (tested in hard and softfp mode).
> - the compiler doesn't bootstrap with LRA enable for thumb (during
> libgcc build).
> 
> As stage 1 will be close soon, my first question is can we add the
> code to enable LRA before its ending, and fix the issues during stage
> 2 (according to Vladimir the legitimate address issue is mainly an LRA
> bugfix). The attached patch enables LRA by default but disable it for
> Thumb and let the opportunity to force LRA with -mlra, but maybe we
> can just turn it off by default.
> 
> I need your help for the Thumb issue, as suggested by Vladimir I
> disabled secondary reload for thumb (with the attached arm.h.diff
> patch) to let LRA deal with it and break a cycle, but I now face an
> issue exhibited by the attached testcase (thumb-lra.i) and the command
> line:
> 
> cc1 -O2 -mthumb -mlra thumb-lra.i
> 
> Here LRA as to deal with the thumb1_movhi_insn :
> 
> (insn 11 5 14 2 (set (reg:HI 0 r0)
> (const_int -1318 [0xfada])) /work/tmp/t2.i:14 206
> {*thumb1_movhi_insn}
>  (nil))
> 
> and creates new regs to do it :
> 
>  11: r0:HI=r114:HI
> Inserting insn reload before:
>  18: r115:SI=0xfada
>  19: r114:HI=r115:SI#0
>   REG_EQUAL 0xfada
> 
>  Choosing alt 6 in insn 18:  (0) l  (1) mi {*thumb1_movsi_insn}
>  Creating newreg=116 from oldreg=115, assigning class LO_REGS to r116
> 
>  18: r116:SI=0xfada
> Inserting insn reload after:
>  20: r115:SI=r116:SI
> 
> Creating newreg=117, assigning class LO_REGS to scratch r117
> 
> and during this mov processing, we call gen_thumb_movhi_clobber which
> ICE because the first rtx parameter is not a strict memory address but
> a register, and here I'm not sure of what to do between fixing this in
> the backend or in LRA, and how to do it.
> 
> Thanks,
> Yvan=
> 
> 

I'd go with defaulting to LRA off until the regression has been
resolved.  You also need a ChangeLog entry.

OK with those done.

R.

Re: RFA: Switch on LRA on ARM (AArch32)

[Richard Biener]

On Mon, Oct 14, 2013 at 4:08 PM, Richard Earnshaw  wrote:
> On 14/10/13 08:27, Yvan Roux wrote:
>> Hi,
>>
>> The status of LRA support for AArch32 is the sequel :
>> - there is some regressions in the testsuite (gcc/g++, libstdc++ and
>> fortran) in ARM mode, all due to the same neon legitimate address
>> issue (tested in hard and softfp mode).
>> - the compiler doesn't bootstrap with LRA enable for thumb (during
>> libgcc build).
>>
>> As stage 1 will be close soon, my first question is can we add the
>> code to enable LRA before its ending, and fix the issues during stage
>> 2 (according to Vladimir the legitimate address issue is mainly an LRA
>> bugfix). The attached patch enables LRA by default but disable it for
>> Thumb and let the opportunity to force LRA with -mlra, but maybe we
>> can just turn it off by default.
>>
>> I need your help for the Thumb issue, as suggested by Vladimir I
>> disabled secondary reload for thumb (with the attached arm.h.diff
>> patch) to let LRA deal with it and break a cycle, but I now face an
>> issue exhibited by the attached testcase (thumb-lra.i) and the command
>> line:
>>
>> cc1 -O2 -mthumb -mlra thumb-lra.i
>>
>> Here LRA as to deal with the thumb1_movhi_insn :
>>
>> (insn 11 5 14 2 (set (reg:HI 0 r0)
>> (const_int -1318 [0xfada])) /work/tmp/t2.i:14 206
>> {*thumb1_movhi_insn}
>>  (nil))
>>
>> and creates new regs to do it :
>>
>>  11: r0:HI=r114:HI
>> Inserting insn reload before:
>>  18: r115:SI=0xfada
>>  19: r114:HI=r115:SI#0
>>   REG_EQUAL 0xfada
>>
>>  Choosing alt 6 in insn 18:  (0) l  (1) mi {*thumb1_movsi_insn}
>>  Creating newreg=116 from oldreg=115, assigning class LO_REGS to r116
>>
>>  18: r116:SI=0xfada
>> Inserting insn reload after:
>>  20: r115:SI=r116:SI
>>
>> Creating newreg=117, assigning class LO_REGS to scratch r117
>>
>> and during this mov processing, we call gen_thumb_movhi_clobber which
>> ICE because the first rtx parameter is not a strict memory address but
>> a register, and here I'm not sure of what to do between fixing this in
>> the backend or in LRA, and how to do it.
>>
>> Thanks,
>> Yvan=
>>
>>
>
> I'd go with defaulting to LRA off until the regression has been
> resolved.  You also need a ChangeLog entry.

Note that sometimes it is convenient to open the doors to wider testing
with enabling something by default.  That may, in the end, result in
faster converging to an overall working system.

Richard.

> OK with those done.
>
> R.
>
>

[PATCH][LTO] Move canonical type stuff out-of-GC land

[Richard Biener]

This replaces the tree -> int hashtable caching hash values by
a pointer_map  and moves it out-of-GC.  Likewise
it moves the actual type hashtable out-of-GC.

LTO bootstrapped and tested on x86_64-unknown-linux-gnu, applied.

Richard.

2013-10-14  Richard Biener  

lto/
* lto.c (gimple_canonical_types): Move out-of GC space.
(canonical_type_hash_cache): Make a pointer-map.
(num_canonical_type_hash_entries, num_canonical_type_hash_queries):
New counters.
(iterative_hash_canonical_type): Adjust.
(read_cgraph_and_symbols): Likewise.
(print_lto_report_1): Likewise.

Index: gcc/lto/lto.c
===
--- gcc/lto/lto.c   (revision 203533)
+++ gcc/lto/lto.c   (working copy)
@@ -255,10 +255,10 @@ lto_read_in_decl_state (struct data_in *
 
 
 /* Global canonical type table.  */
-static GTY((if_marked ("ggc_marked_p"), param_is (union tree_node)))
-  htab_t gimple_canonical_types;
-static GTY((if_marked ("tree_int_map_marked_p"), param_is (struct 
tree_int_map)))
-  htab_t canonical_type_hash_cache;
+static htab_t gimple_canonical_types;
+static pointer_map  *canonical_type_hash_cache;
+static unsigned long num_canonical_type_hash_entries;
+static unsigned long num_canonical_type_hash_queries;
 
 /* Returning a hash value for gimple type TYPE combined with VAL.
 
@@ -269,12 +269,12 @@ static hashval_t
 iterative_hash_canonical_type (tree type, hashval_t val)
 {
   hashval_t v;
-  void **slot;
-  struct tree_int_map *mp, m;
+  hashval_t *slot;
 
-  m.base.from = type;
-  if ((slot = htab_find_slot (canonical_type_hash_cache, &m, NO_INSERT)))
-return iterative_hash_hashval_t (((struct tree_int_map *) *slot)->to, val);
+  num_canonical_type_hash_queries++;
+  slot = canonical_type_hash_cache->contains (type);
+  if (slot)
+return iterative_hash_hashval_t (*slot, val);
 
   /* Combine a few common features of types so that types are grouped into
  smaller sets; when searching for existing matching types to merge,
@@ -374,14 +374,9 @@ iterative_hash_canonical_type (tree type
 }
 
   /* Cache the just computed hash value.  */
-  mp = ggc_alloc_cleared_tree_int_map ();
-  mp->base.from = type;
-  mp->to = v;
-  /* As we recurse the hashtable may expand between looking up the
- cached value (and not finding one) and here, so we have to
- re-lookup the slot.  */
-  slot = htab_find_slot (canonical_type_hash_cache, &m, INSERT);
-  *slot = (void *) mp;
+  num_canonical_type_hash_entries++;
+  slot = canonical_type_hash_cache->insert (type);
+  *slot = v;
 
   return iterative_hash_hashval_t (v, val);
 }
@@ -2749,8 +2744,7 @@ read_cgraph_and_symbols (unsigned nfiles
 }
   cgraph_state = CGRAPH_LTO_STREAMING;
 
-  canonical_type_hash_cache = htab_create_ggc (512, tree_int_map_hash,
-  tree_int_map_eq, NULL);
+  canonical_type_hash_cache = new pointer_map ;
   gimple_canonical_types = htab_create_ggc (16381, gimple_canonical_type_hash,
gimple_canonical_type_eq, 0);
   gcc_obstack_init (&tree_scc_hash_obstack);
@@ -2817,7 +2811,7 @@ read_cgraph_and_symbols (unsigned nfiles
   obstack_free (&tree_scc_hash_obstack, NULL);
   htab_delete (gimple_canonical_types);
   gimple_canonical_types = NULL;
-  htab_delete (canonical_type_hash_cache);
+  delete canonical_type_hash_cache;
   canonical_type_hash_cache = NULL;
   ggc_collect ();
 
@@ -3023,13 +3017,10 @@ print_lto_report_1 (void)
   (long) gimple_canonical_types->searches,
   (long) gimple_canonical_types->collisions,
   htab_collisions (gimple_canonical_types));
-  fprintf (stderr, "[%s] GIMPLE canonical type hash table: size %ld, "
-  "%ld elements, %ld searches, %ld collisions (ratio: %f)\n", pfx,
-  (long) htab_size (canonical_type_hash_cache),
-  (long) htab_elements (canonical_type_hash_cache),
-  (long) canonical_type_hash_cache->searches,
-  (long) canonical_type_hash_cache->collisions,
-  htab_collisions (canonical_type_hash_cache));
+  fprintf (stderr, "[%s] GIMPLE canonical type pointer-map: "
+  "%lu elements, %ld searches\n", pfx,
+  num_canonical_type_hash_entries,
+  num_canonical_type_hash_queries);
 }
 
   print_lto_report (pfx);

Re: [Patch ARM] Add support for a set of multilibs to be built for A profile cores.

[Richard Earnshaw]

On 10/10/13 10:39, Ramana Radhakrishnan wrote:
> Hi,
> 
>   One of our internal patches is a multilib patch that helps in testing 
> bare-metal toolchains for v7-a and above.
> 
> It's a bit brute force but this is something that we use internally 
> every night to build a set of base libraries in a hierarchical directory 
> structure to be used by bare metal toolchains along with those that want 
> to do so from a single toolchain. I don't claim to particularly like 
> this patch especially the part of writing the MULTILIB_REUSE macros to 
> match as many of the options that I could think of that folks would use 
> sensibly along with such a toolchain.
> 
> 
> - I've missed a few -mfpu options but I deemed them to be uncommon 
> enough. If people want to submit a follow on patch for those, I'd be 
> happy to take them but this will do for now.
> 
> - Additionally if people want to extend this to cover M profile cores 
> and all cores, feel free to do so. I don't intend to do so in this cut 
> of the makefile fragment.
> 
> - I have deliberately avoided documenting that ARM in the supported list 
> for --with-multilib-list, because we aren't providing this option like 
> other targets in this regard.
> 
> - Additionally one cannot use with --with-cpu , --with-fpu, --with-float 
> --with-mode --with-arch command line options with this as the make file 
> fragment is written assuming such a case.
> 
> This does not handle all the general options that --with-multilib-list 
> provides with actually providing options on the command line, trying to 
> write this with the command lines as suggested in other ports for the 
> length that I have in mind, is just going to be unweildy and extremely 
> irritating on the command line.
> 
> Additionally there is no easy way of supplying multilib_reuse options on 
> the command line, with the result that the configure command line would 
> be long, prone to error and extremely fragile. This is less fragile than 
> that approach and hence I prefer this form for the ARM backend for the 
> current work and for people who are interested in this sort of a thing.
> 
> Additionally tested with a noddy shell script that goes something like 
> and checked for no failures.
> 
> for mode in marm mthumb ; do
> for fabi in hard softfp  ; do
> for fpu in vfpv3-d16 vfpv3 vfpv4-d16 vfpv4 neon neon-vfpv4 fp-armv8 
> neon-fp-armv8  ; do
> for cpu in cortex-a8 cortex-a5 cortex-a9 cortex-a7 cortex-a15 
> cortex-a53; do
>x=`$COMPILER /tmp/hello.c -mcpu="$cpu" -mfpu="$fpu" 
> -mfloat-abi="$fabi" "-$mode" -print-multi-directory -lm`
>if [ "$x" != "." ];
>then
>echo "PASS: mcpu=$cpu mfpu=$fpu mfloat-abi=$fabi -$mode"
>else
>echo "FAIL: mcpu=$cpu mfpu=$fpu mfloat-abi=$fabi -$mode"
>fi
> done
> done
> done
> 
> for fpu in vfpv3-d16 vfpv3 vfpv4-d16 vfpv4 neon neon-vfpv4 fp-armv8 
> neon-fp-armv8 crypto-neon-fp-armv8 ; do
> for fabi in hard softfp  ; do
> for arch in armv7-a armv8-a ; do
> #  $COMPILER /tmp/hello.c -march="$arch" -mfpu="$fpu" 
> -mfloat-abi="$fabi" -"$mode" -lm
>x=`$COMPILER /tmp/hello.c -march="$arch" -mfpu="$fpu" 
> -mfloat-abi="$fabi" "-$mode" -print-multi-directory -lm`
>   if [ "$x" != "." ];
>   then
>echo "PASS: march=$arch mfpu=$fpu mfloat-abi=$fabi -$mode"
>else
>echo "FAIL: march=$arch mfpu=$fpu mfloat-abi=$fabi -$mode"
>fi
> done
> done
> done
> 
> 
> Tested on arm-none-eabi with --with-multilib-list=aprofile C, C++ and 
> Fortran with no regressions on an ARM fast model. Note that this is not 
> on by default so will not affect default build times and we have 
> auto-testers internally that use this feature.
> 
> I think I can apply the changes for config.gcc but I'd still like 
> another set of eyes on this please.
> 
> Ok ?
> 
> regards
> Ramana
> 
> 
>   Matthew Gretton-Dann  
>   Ramana Radhakrishnan  
> 
> 
> * config/arm/t-aprofile: New file.
> * config.gcc: Handle --with-multilib-list option.
> 
> 

OK.

R.

Re: [patch] Fix altivec-7.C testsuite failure due to vector name mangling.

[Aldy Hernandez]

On 10/11/13 13:55, Brooks Moses wrote:

Hi, all -

We recently built a compiler with a default -fabi-version value that's
different from the 2 that's used as default on trunk.  The result of
this was a test failure in g++.dg/ext/altivec-7.C, which compiles a
bunch of empty functions with vector arguments and inspects the
generated assembly for the mangled names.

The failure is because the test is searching for mangled names of the
form "_Z3fooU8__vectorh", which are only generated by ABI versions 1,
2, and 3.  As noted in the documentation, "Version 4, which first
appeared in G++ 4.5, implements a standard mangling for vector types";
this standard mangling looks like "_Z3fooDv16_h" instead.

This patch fixes the failure by adjusting the test to look for the
names using the standard mangling.  It passes with all ABI versions;
the compiler always emits the standard symbols, and with versions 1,
2, and 3 it also emits duplicate symbols with the old mangling.

Ok to commit?



OK

[PATCH] tree_code_name wrapper

[Paulo Matos]

Hi, 

Find attached the patch for trunk that creates a wrapper for tree_code_name to 
ensure that no invalid tree code is passed on to tree_code_name. All 
occurrences of tree_code_name use now use get_tree_code_name. Touched mep, frv, 
rs6000, iq2000 backends.

Comments? Ok to submit?


2013-10-14  Paulo Matos  

* tree.h: Prototype for new function get_tree_code_name.
* tree.c: Make tree_code_name static. Define new function
wrapper get_tree_code_name.
(dump_tree_statistics, tree_check_failed, tree_not_check_failed, 
tree_class_check_failed, tree_range_check_failed, 
tree_not_class_check_failed,
omp_clause_check_failed, tree_contains_struct_check_failed, 
tree_operand_check_failed):  Use new wrapper get_tree_code_name 
instead of
calling tree_code_name directly.
* tree-vrp.c (dump_asserts_for): Use new wrapper get_tree_code_name.
* tree-dump.c (dequeue_and_dump): Use new wrapper get_tree_code_name.
* tree-pretty-print.c (do_niy, dump_generic_node): Use new wrapper 
get_tree_code_name.
* tree-pretty-print.h (pp_unsupported_tree): Use new wrapper 
get_tree_code_name.
* cp/error.c (code_to_string): Use new wrapper get_tree_code_name.
* cp/cxx-pretty-print.c (pp_cxx_assignment_operator): Use new wrapper 
get_tree_code_name.
* cp/pt.c (tsubst): Use new wrapper get_tree_code_name.
* cp/semantics.c (cxx_eval_constant_expression, 
potential_constant_expression_1): Use new 
wrapper get_tree_code_name.
* cp/mangle.c (MANGLE_TRACE_TREE, dump_substitution_candidates, 
add_substitution,
find_substitution): Use new wrapper get_tree_code_name.
* lto-streamer-out.c (lto_write_tree, DFS_write_tree): Use new wrapper 
get_tree_code_name.
* tree-ssa-dom.c (print_expr_hash_elt): Use new wrapper 
get_tree_code_name.
* gimple-pretty-print.c (dump_unary_rhs, dump_binary_rhs, 
dump_ternary_rhs, 
dump_gimple_assign, dump_gimple_cond, dump_gimple_omp_for): Use new 
wrapper 
get_tree_code_name.
* tree-vect-data-refs.c (vect_create_data_ref_ptr): Use new wrapper 
get_tree_code_name.
* tree-ssa-pre.c (print_pre_expr): Use new wrapper get_tree_code_name.
* ipa-prop.c (ipa_print_node_jump_functions_for_edge): Use new wrapper 
get_tree_code_name.
* print-tree.c (print_node_brief, print_node): Use new wrapper 
get_tree_code_name.
* gimple.c (gimple_check_failed): Use new wrapper get_tree_code_name.
* tree-core.h: Remove extern declaration of tree_code_name.
* config/frv/frv.c (frv_init_cumulative_args): Use new wrapper 
get_tree_code_name.
* config/mep/mep.c (mep_validate_vliw): Use new wrapper 
get_tree_code_name.
* config/iq2000/iq2000.c (init_cumulative_args): Use new wrapper 
get_tree_code_name.
* config/rs6000/rs6000.c (init_cumulative_args): Use new wrapper 
get_tree_code_name.
* lto-streamer.c (lto_tag_name, print_lto_report): Use new wrapper 
get_tree_code_name.


-- 
Paulo Matos




tree_code_name.patch
Description: tree_code_name.patch

RE: [PATCH] tree_code_name wrapper

[Paulo Matos]

> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On
> Behalf Of Paulo Matos
> Sent: 14 October 2013 16:43
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH] tree_code_name wrapper
> 
> Hi,
> 
> Find attached the patch for trunk that creates a wrapper for tree_code_name
> to ensure that no invalid tree code is passed on to tree_code_name. All
> occurrences of tree_code_name use now use get_tree_code_name. Touched mep,
> frv, rs6000, iq2000 backends.
> 
> Comments? Ok to submit?
> 
> 

Forgot to mention that I ran the testsuite on x86_64-unknown-linux-gnu and 
there was no change.

-- 
Paulo Matos

[PATCH] decide edge's hotness when there is profile info

[Dehao Chen]

This patch forces to use profile info to check if an edge is hot when
profile is available.

Bootstrapped and passed regression tests.

OK for trunk?

Thanks,
Dehao

gcc/ChangeLog:
2013-10-14  Dehao Chen  
* predict.c(cgraph_maybe_hot_edge_p): Decide edge's hotness from profile.

Index: gcc/predict.c
===
--- gcc/predict.c (revision 203568)
+++ gcc/predict.c (working copy)
@@ -185,10 +185,8 @@ maybe_hot_bb_p (struct function *fun, const_basic_
 bool
 cgraph_maybe_hot_edge_p (struct cgraph_edge *edge)
 {
-  if (profile_info && flag_branch_probabilities
-  && !maybe_hot_count_p (NULL,
- edge->count))
-return false;
+  if (profile_info && flag_branch_probabilities)
+return maybe_hot_count_p (NULL, edge->count);
   if (edge->caller->frequency == NODE_FREQUENCY_UNLIKELY_EXECUTED
   || (edge->callee
   && edge->callee->frequency == NODE_FREQUENCY_UNLIKELY_EXECUTED))

Re: [PATCH] tree_code_name wrapper

[Paolo Carlini]

Hi

On 10/14/2013 05:43 PM, Paulo Matos wrote:

* cp/error.c (code_to_string): Use new wrapper get_tree_code_name.
* cp/cxx-pretty-print.c (pp_cxx_assignment_operator): Use new wrapper 
get_tree_code_name.
* cp/pt.c (tsubst): Use new wrapper get_tree_code_name.
* cp/semantics.c (cxx_eval_constant_expression, 
potential_constant_expression_1): Use new
wrapper get_tree_code_name.
* cp/mangle.c (MANGLE_TRACE_TREE, dump_substitution_candidates, 
add_substitution,
find_substitution): Use new wrapper get_tree_code_name.
In general, if you touch files in subdirectories which have separate 
ChangeLog files you have to prepare separate ChangeLog entries (and 
then, considering the present case as an example, you don't have cp/ at 
the beginning of the corresponding file names)


Paolo.

Re: [PATCH] decide edge's hotness when there is profile info

[Xinliang David Li]

Looks like there is some inconsistency between edge hotness and callee
frequency?

David

On Mon, Oct 14, 2013 at 9:08 AM, Dehao Chen  wrote:
> This patch forces to use profile info to check if an edge is hot when
> profile is available.
>
> Bootstrapped and passed regression tests.
>
> OK for trunk?
>
> Thanks,
> Dehao
>
> gcc/ChangeLog:
> 2013-10-14  Dehao Chen  
> * predict.c(cgraph_maybe_hot_edge_p): Decide edge's hotness from profile.
>
> Index: gcc/predict.c
> ===
> --- gcc/predict.c (revision 203568)
> +++ gcc/predict.c (working copy)
> @@ -185,10 +185,8 @@ maybe_hot_bb_p (struct function *fun, const_basic_
>  bool
>  cgraph_maybe_hot_edge_p (struct cgraph_edge *edge)
>  {
> -  if (profile_info && flag_branch_probabilities
> -  && !maybe_hot_count_p (NULL,
> - edge->count))
> -return false;
> +  if (profile_info && flag_branch_probabilities)
> +return maybe_hot_count_p (NULL, edge->count);
>if (edge->caller->frequency == NODE_FREQUENCY_UNLIKELY_EXECUTED
>|| (edge->callee
>&& edge->callee->frequency == NODE_FREQUENCY_UNLIKELY_EXECUTED))

Re: [PATCH] decide edge's hotness when there is profile info

[Dehao Chen]

Not for instrumented FDO (not as I know of). But for AutoFDO, this
could be a potential risk because some callee is marked unlikely
executed simply because they are inlined and eliminated in the O2
binary. But in ipa-inline it will not get inlined because the edge is
not hot from cgraph_maybe_hot_edge_p (because callee is
UNLIKELY_EXECUTED), while the edge->count is actually hot.

Dehao

On Mon, Oct 14, 2013 at 9:13 AM, Xinliang David Li  wrote:
> Looks like there is some inconsistency between edge hotness and callee
> frequency?
>
> David
>
> On Mon, Oct 14, 2013 at 9:08 AM, Dehao Chen  wrote:
>> This patch forces to use profile info to check if an edge is hot when
>> profile is available.
>>
>> Bootstrapped and passed regression tests.
>>
>> OK for trunk?
>>
>> Thanks,
>> Dehao
>>
>> gcc/ChangeLog:
>> 2013-10-14  Dehao Chen  
>> * predict.c(cgraph_maybe_hot_edge_p): Decide edge's hotness from profile.
>>
>> Index: gcc/predict.c
>> ===
>> --- gcc/predict.c (revision 203568)
>> +++ gcc/predict.c (working copy)
>> @@ -185,10 +185,8 @@ maybe_hot_bb_p (struct function *fun, const_basic_
>>  bool
>>  cgraph_maybe_hot_edge_p (struct cgraph_edge *edge)
>>  {
>> -  if (profile_info && flag_branch_probabilities
>> -  && !maybe_hot_count_p (NULL,
>> - edge->count))
>> -return false;
>> +  if (profile_info && flag_branch_probabilities)
>> +return maybe_hot_count_p (NULL, edge->count);
>>if (edge->caller->frequency == NODE_FREQUENCY_UNLIKELY_EXECUTED
>>|| (edge->callee
>>&& edge->callee->frequency == NODE_FREQUENCY_UNLIKELY_EXECUTED))

Re: Apply attribute returns_nonnull in libiberty

[DJ Delorie]

I don't think there's an official list, but if you ask gdb, binutils,
newlib, and sid (I think), you've probably got it covered.  Basically,
everything in the src/ repository.

[PING][PATCH] Cilk Keywords (_Cilk_spawn and _Cilk_sync) for C (and C++)

[Iyer, Balaji V]

Hello Everyone,
I submitted this patch ~1 months ago. Did anyone get a chance to look 
into this patch? 

Thanks,

Balaji V. Iyer.

> -Original Message-
> From: Iyer, Balaji V
> Sent: Wednesday, September 11, 2013 2:18 PM
> To: r...@redhat.com; Jason Merrill (ja...@redhat.com); Jeff Law; Aldy
> Hernandez (al...@redhat.com)
> Cc: gcc-patches@gcc.gnu.org
> Subject: RE: [PATCH] Cilk Keywords (_Cilk_spawn and _Cilk_sync) for C (and 
> C++)
> 
> Hello Everyone,
>   Couple weeks back, I had submitted a patch for review that will
> implement Cilk keywords (_Cilk_spawn and _Cilk_sync) into the C compiler. I
> recently finished C++ implementation also. In this email, I am attaching 2
> patches: 1 for C (and the common parts for C and C++) and 1 for C++. The C++
> Changelog is labelled cp-ChangeLog.cilkplus and the other one is just
> ChangeLog.cilkplus. There isn't much changes in the C patch. Only noticeable
> changes would be moving functions to the common parts so that C++ can use
> them.
> 
>   It passes all the tests and does not affect  (by affect I mean fail a 
> passing
> test or pass a failing one) any of the other tests in the testsuite directory.
> 
>   Is this Ok for trunk?
> 
> Thanks,
> 
> Balaji V. Iyer.
> 
> > -Original Message-
> > From: Iyer, Balaji V
> > Sent: Friday, August 30, 2013 1:02 PM
> > To: gcc-patches@gcc.gnu.org
> > Subject: FW: [PATCH] Cilk Keywords (_Cilk_spawn and _Cilk_sync) for C
> >
> > The email seem to be bouncing gcc-patches. I have gzipped my patch.
> >
> > Thanks,
> >
> > Balaji V. Iyer.
> >
> >
> > > > -Original Message-
> > > > From: Iyer, Balaji V
> > > > Sent: Friday, August 30, 2013 11:42 AM
> > > > To: 'Aldy Hernandez'
> > > > Cc: r...@redhat.com; Jeff Law; gcc-patches@gcc.gnu.org
> > > > Subject: RE: [PATCH] Cilk Keywords (_Cilk_spawn and _Cilk_sync)
> > > > for C
> > > >
> > > > Hi Aldy,
> > > > Attached, please find a fixed patch and the changelog entries.
> > > >
> > > > > -Original Message-
> > > > > From: Aldy Hernandez [mailto:al...@redhat.com]
> > > > > Sent: Wednesday, August 28, 2013 2:36 PM
> > > > > To: Iyer, Balaji V
> > > > > Cc: r...@redhat.com; Jeff Law; gcc-patches@gcc.gnu.org
> > > > > Subject: Re: [PATCH] Cilk Keywords (_Cilk_spawn and _Cilk_sync)
> > > > > for C
> > > > >
> > > > > On 08/27/13 16:27, Iyer, Balaji V wrote:
> > > > > > Hello Aldy, I went through all the emails and here are the
> > > > > > major issues that I could gather (other than lowering the
> > > > > > keywords after gimplification, which I am skipping since it is
> > > > > > more of an optimization for now).
> > > > >
> > > > > Ok, for now I am fine with delaying handling all this as a
> > > > > gimple tuple since most of your code lives in it's only little world 
> > > > > :).
> > > > > But I will go on record saying that part of the reason that you
> > > > > have to handle CALL_EXPR, MODIFY_EXPR, INIT_EXPR and such is
> > > > > because you don't
> > > > have easy gimplified code to examine.
> > > > > Anyways, agreed, you can do this later.
> > > > >
> > > > > >
> > > > > > 1. Calling the gimplify_cilk_spawn on top of the gimplify_expr
> > > > > > before the switch-statement could slow the compiler down 2. I
> > > > > > need a CILK_SPAWN_STMT case in the switch statement in
> > > > > > gimplify_expr
> > (). 3.
> > > > > > No test for catching the suspicious spawned function warning 4.
> > > > > > Reasoning for expanding the 2 builtin functions in builtins.c
> > > > > > instead of just inserting the appropriate expanded-code when I
> > > > > > am inserting the function call.
> > > > > >
> > > > > > Did I miss anything else (or misunderstand anything you pointed 
> > > > > > out)?
> > > > > >
> > > > > > Here are my answers to those questions above and am attaching
> > > > > > a fixed patch with the changelog entries:
> > > > > >
> > > > > > 1 & 2(partial): There are 3 places where we could have _Cilk_spawn:
> > > > > > INIT_EXPR, CALL_EXPR and MODIFY_EXPR. INIT_EXPR and
> > MODIFY_EXPRS
> > > > are
> > > > > > both gimplified using gimplify_modify_expr. I have moved the
> > > > > > cilk_detect_spawn into this function. We will go into the
> > > > > > cilk_detect_spawn if cilk plus is enabled, and if there is a
> > > > > > cilk_frame (meaning the function has a Cilk_spawn in it)
> > > > > > thereby reducing the number of hits into this function 
> > > > > > significantly.
> > > > > > Inside this function, it will go into the function that has a
> > > > > > spawned function call and then unwrap the CILK_SPAWN_STMT
> > > > > > wrapper and returns true. This shouldn't cause a huge
> > > > > > compilation time
> > hit. 2.
> > > > > > To handle CALL_EXPR (e.g. _Cilk_spawn foo (x), where foo
> > > > > > returns a void or the return value of it is ignored), I have
> > > > > > added a CILK_SPAWN_STMT
> > > > case.
> > > > > > Again, I am calling the detect_cilk_spawn and we will only
> > > > > > step into this function if Cilk P

Re: Apply attribute returns_nonnull in libiberty

[Tom Tromey]

DJ> I don't think there's an official list, but if you ask gdb, binutils,
DJ> newlib, and sid (I think), you've probably got it covered.  Basically,
DJ> everything in the src/ repository.

FWIW, gdb doesn't mind.  While gdb does override xmalloc, it does so in
a way that avoids NULL returns.

Tom

Re: [PATCH] Introduce gcc::dump_manager class

[David Malcolm]

On Mon, 2013-10-14 at 12:13 +0200, Richard Biener wrote:
> On Sat, Oct 12, 2013 at 3:31 AM, David Malcolm  wrote:
> > When repeatedly compiling within one process, the dumpfile numbering
> > doesn't reset, leading to dumpfiles after the initial ones having
> > unpredictable numbers like here (-fdump-tree-all at -O0):
> >
> >   fake.c.000i.cgraph
> >   fake.c.004t.gimple
> >   fake.c.1477t.omplower
> >   fake.c.1478t.lower
> >   (etc)
> >
> > Note the large (and increasing) leap in the numbering from the base
> > dumpfiles which get consistent numbering (000, 004 here) to the
> > autonumbered ones (1477 in this example).  This was due to this implicit
> > state within dump_register:
> >
> >   static int next_dump = FIRST_AUTO_NUMBERED_DUMP;
> >   int num = next_dump++;
> >
> > messing up the numbering on subsequent in-process creation of passes.
> >
> > This patch introduces a new gcc::dump_manager class to hold such state,
> > with a singleton owned by the gcc::context, fixing the inconsistent
> > dumpfile numbering.
> >
> > Specifically, the following variables from dumpfile.c are moved from
> > being statically allocated to being fields of gcc::dump_manager (gaining
> > "m_" prefixes):
> >
> >   * next_dump
> >   * extra_dump_files
> >   * extra_dump_files_in_use
> >   * extra_dump_files_alloced
> >
> > Potentially other aspects of dumping could be moved here, but this
> > seemed like a logically self-contained change.
> >
> > Successfully bootstrapped and regtested on x86_64-unknown-linux.
> >
> > OK for trunk?
> 
> Why can't we have the dump numbering determined at the same time
> we build up the pass pipeline?  That is, why are gcc:dump_manager
> and gcc:pass_manager separate at all?

Not every dumpfile relates to a specific pass: statistics.c registers
and uses a dumpfile in ways that don't look like how the passes do.
Although this is obviously for recording events that happen within
passes, it covers *all* passes, rather than being a per-pass thing.
This is clearly a gray area, but the single responsibility principle
suggests that managing passes vs managing dumpfiles should be separate,
especially since I may want to make future dumpfile-handling cleanups.
(Also, I'm nervous about "blob" classes with too many responsibilities).

> That said, the patch is a trivial re-org and thus ok.

Thanks; committed to trunk as r203569.

[libiberty] xmalloc cannot return NULL

[Marc Glisse]

Hello,

libiberty provides a function xmalloc that never returns NULL. However, 
there are some hints that it might be ok if someone wants to supply their 
own xmalloc that can return NULL (though that would break a lot of things, 
including in libiberty itself).


I would like to remove that freedom, and the point of this email (I hope 
it doesn't bounce from too many of these addresses) is to ask all 
libiberty users if that would cause problems for them. I already heard 
from gcc and gdb that they are happy forbidding a null return value from 
xmalloc.


Why do I want to do that? I just added an attribute "returns_nonnull" to 
gcc and would like to mark relevant functions, to let the compiler 
optimize based on this property.


http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00817.html

--
Marc Glisse

Re: [PATCH][LTO] Move canonical type stuff out-of-GC land

[Tobias Burnus]

Richard Biener wrote:

This replaces the tree -> int hashtable caching hash values by
a pointer_map  and moves it out-of-GC.  Likewise
it moves the actual type hashtable out-of-GC.

LTO bootstrapped and tested on x86_64-unknown-linux-gnu, applied.



I think it's due to this patch that bootstrapping into an empty 
directory fails during Stage 1 for me with the following message.


Tobias

g++ -c  -DIN_GCC_FRONTEND -g -DIN_GCC   -fno-exceptions -fno-rtti 
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long 
-Wno-variadic-macros -Wno-overlength-strings -fno-common 
-DHAVE_CONFIG_H -I. -Ilto -I../../gcc -I../../gcc/lto 
-I../../gcc/../include -I../../gcc/../libcpp/include 
-I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/bid 
-I../libdecnumber -I../../gcc/../libbacktrace -DCLOOG_INT_GMP-o 
lto/lto.o -MT lto/lto.o -MMD -MP -MF lto/.deps/lto.TPo ../../gcc/lto/lto.c

In file included from ../../gcc/lto/lto.c:3258:0:
./gt-lto-lto.h:153:6: error: 'type_hash_cache' was not declared in this 
scope

 &type_hash_cache,
  ^
./gt-lto-lto.h:155:13: error: 'type_hash_cache' was not declared in this 
scope

 sizeof (type_hash_cache),
 ^
./gt-lto-lto.h:161:6: error: 'gimple_types' was not declared in this scope
 &gimple_types,
  ^
./gt-lto-lto.h:163:13: error: 'gimple_types' was not declared in this scope
 sizeof (gimple_types),
 ^
./gt-lto-lto.h:173:6: error: 'type_hash_cache' was not declared in this 
scope

 &type_hash_cache,
  ^
./gt-lto-lto.h:175:13: error: 'type_hash_cache' was not declared in this 
scope

 sizeof (type_hash_cache),
 ^
./gt-lto-lto.h:180:6: error: 'gimple_types' was not declared in this scope
 &gimple_types,
  ^
./gt-lto-lto.h:182:13: error: 'gimple_types' was not declared in this scope
 sizeof (gimple_types),
 ^
make[3]: *** [lto/lto.o] Error 1



2013-10-14  Richard Biener  

lto/
* lto.c (gimple_canonical_types): Move out-of GC space.
(canonical_type_hash_cache): Make a pointer-map.
(num_canonical_type_hash_entries, num_canonical_type_hash_queries):
New counters.
(iterative_hash_canonical_type): Adjust.
(read_cgraph_and_symbols): Likewise.
(print_lto_report_1): Likewise.

Re: [libiberty] xmalloc cannot return NULL

[Mike Frysinger]

On Monday 14 October 2013 13:59:16 Marc Glisse wrote:
> libiberty provides a function xmalloc that never returns NULL. However,
> there are some hints that it might be ok if someone wants to supply their
> own xmalloc that can return NULL (though that would break a lot of things,
> including in libiberty itself).
> 
> I would like to remove that freedom, and the point of this email (I hope
> it doesn't bounce from too many of these addresses) is to ask all
> libiberty users if that would cause problems for them. I already heard
> from gcc and gdb that they are happy forbidding a null return value from
> xmalloc.
> 
> Why do I want to do that? I just added an attribute "returns_nonnull" to
> gcc and would like to mark relevant functions, to let the compiler
> optimize based on this property.
> 
> http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00817.html

makes sense to me.  as you point out, we write code based on the assumption 
that NULL is never returned (although, perhaps phrased more accurately, that 
the pointer returned is always valid).
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH][LTO] Move canonical type stuff out-of-GC land

[Tobias Burnus]

Pilot error:
  rm -rf &
doesn't delete the build directory. With a really empty directory works.

Sorry for the noise!

(Besides, the correct patch would have been 
http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00939.html )


Tobias

Re: [PATCH] Fix PR58682

[Mike Stump]

On Oct 14, 2013, at 3:43 AM, Kyrill Tkachov  wrote:
> On 14/10/13 11:23, Paulo Matos wrote:
>>> -Original Message-
>>> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] 
>>> On
>>> Behalf Of Paulo Matos
>>> Sent: 14 October 2013 11:22
>>> To: Kyrill Tkachov
>>> Cc: gcc-patches@gcc.gnu.org
>>> Subject: RE: [PATCH] Fix PR58682
>>> 
>>> 
>>> OK, testcase generated. Patch attached but there are a few issues and need
>>> some comments.
>>> 
>> I am sorry, I forgot to attach the patch. Here it is.
>> OK, testcase generated. Patch attached but there are a few issues and need 
>> some comments.
> 
>>  * The test includes 6 additional sources and 3 headers. This feels like it 
>> pollutes the test
>> directory a lot. Should I at least submit preprocessed sources, so that the 
>> headers disappear?
>>  * The sources come from CoreMark, does anybody know if their license allows 
>> us to include this
>> test in GCC? Also, the code if formatted with CoreMark formatting, should I 
>> just use indent to
>> properly format the patch?
> I'd think there would be legal issues adding coremark to the testsuite but 
> I'm not an expert on this. In any case, I think it's too big of a testcase. 
> Any way we could reduce it?

In general, you can only submit software you personally wrote to gcc if you 
have papers on file with the FSF for contributions.  If someone else wrote it, 
you have to have them submit it.  Start there, and you can learn all the 
details an exceptions after that.  The test suite is slightly more lax, in that 
we don't require an assignment for contributions, but, copyrightable works 
still need approval from the owner of the works, if the works don't already 
come with distribution and modification clauses that would allow the 
contribution to be added to the test suite.  If in doubt, first, post the 
license and let's talk about it, before posting any code.

In this case, I've reviewed the license I suspect you have, and I suspect it 
does not have a grant of enough rights to allow it to be contributed to gcc.

>>  * Last, but not least, this patch only causes an ICE on 4_8, but not 
>> because trunk is fixed.
>> Instead trunk generates edge counts in such a way that they never happen to 
>> be higher than max_count
>> when a call is inlined. Is it still worth it to get it into trunk (even 
>> though trunk should
>> still be patched?)
> CC'ing one of the testsuite maintainers…

I'll punt this, as I think we're out into the weeds already.

Re: [PATCH] decide edge's hotness when there is profile info

[Jan Hubicka]

> Not for instrumented FDO (not as I know of). But for AutoFDO, this
> could be a potential risk because some callee is marked unlikely
> executed simply because they are inlined and eliminated in the O2
> binary. But in ipa-inline it will not get inlined because the edge is
> not hot from cgraph_maybe_hot_edge_p (because callee is
> UNLIKELY_EXECUTED), while the edge->count is actually hot.

Can't you prevent setting calle to UNLIKELY_EXECUTED in these cases instead?
It seems that having profile set incorrectly will lead to other problems later, 
too.
We discussed similar problem with Teresa about the missing profiles for comdat,
basically one should detect these cases as profile being lost and go with 
guessed
profile.  (I believe patch for that was posted, too, and so far it seems best 
approach
to this issue)

Honza

Re: [PATCH i386 3/8] [AVX512] [17/n] Add AVX-512 patterns: V8FI and V16FI iterators.

[Richard Henderson]

On 10/09/2013 03:30 AM, Kirill Yukhin wrote:
> Hello,
> 
>> This patch is still far too large.
>>
>> I think you should split it up based on every single mode iterator that
>> you need to add or change.
> 
> Here's 17th subpatch. It introduces V8FI and V16FI iterators.


Ok.


r~

Re: [PATCH i386 3/8] [AVX512] [18/n] Add AVX-512 patterns: various RCPs and SQRTs.

[Richard Henderson]

On 10/09/2013 03:31 AM, Kirill Yukhin wrote:
> Hello,
> 
>> This patch is still far too large.
>>
>> I think you should split it up based on every single mode iterator that
>> you need to add or change.
> 
> Here's 18th subpatch. It introduces various new insns.

Ok.


r~

Re: [PATCH i386 3/8] [AVX512] [18/n] Add AVX-512 patterns: various RCPs and SQRTs.

[Richard Henderson]

On 10/09/2013 03:31 AM, Kirill Yukhin wrote:
> +(define_mode_attr ssefixupmode
> +  [(V16SF "V16SI") (V4SF "V4SI") (V8DF "V8DI") (V2DF "V2DI")])
> +

Oh, I forgot.  How is this different from sseintvecmode?


r~

libgo patch committed: Don't clobber context when catching signal

[Ian Lance Taylor]

This patch to libgo fixes a dumb bug in which catching a signal via the
os/signal package could clobber the saved split-stack context, leading
to disaster if the signal arrived at the wrong time.  Bootstrapped and
ran Go testsuite on x86_64-unknown-linux-gnu.  Committed to mainline.
Will commit to 4.8 branch when it reopens.

Ian

diff -r 9c8c4538fce7 libgo/runtime/go-signal.c
--- a/libgo/runtime/go-signal.c	Sat Oct 12 21:13:58 2013 -0700
+++ b/libgo/runtime/go-signal.c	Mon Oct 14 14:00:36 2013 -0700
@@ -399,6 +399,7 @@
 {
   G *gp;
   M *mp;
+  void *stack_context[10];
 
   /* We are now running on the stack registered via sigaltstack.
  (Actually there is a small span of time between runtime_siginit
@@ -409,7 +410,7 @@
   if (gp != NULL)
 {
 #ifdef USING_SPLIT_STACK
-  __splitstack_getcontext (&gp->stack_context[0]);
+  __splitstack_getcontext (&stack_context[0]);
 #endif
 }
 
@@ -432,7 +433,7 @@
   if (gp != NULL)
 {
 #ifdef USING_SPLIT_STACK
-  __splitstack_setcontext (&gp->stack_context[0]);
+  __splitstack_setcontext (&stack_context[0]);
 #endif
 }
 }

Re: [PATCH] Fix comment in tree-prof.exp

[Mike Stump]

On Oct 14, 2013, at 2:35 AM, Paulo Matos  wrote:
>> -Original Message-
>> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On
>> Behalf Of Paulo Matos
>> Sent: 14 October 2013 10:31
>> To: gcc-patches@gcc.gnu.org
>> Subject: [PATCH] Fix comment in tree-prof.exp
>> 
>> Hi,
>> 
>> Here's a patch to fix a comment in tree-prof.exp. OK to apply?
>> 
>> 2013-10-14  Paulo Matos  
>> 
>>  * testsuite/gcc.dg/tree-prof/tree-prof.exp: Fix comment.
> 
> Just noticed a patch by Richard where his changelog didn't include the 
> testsuite/ bit so it should be:
> 
> 2013-10-14  Paulo Matos  
> 
>   * gcc.dg/tree-prof/tree-prof.exp: Fix comment.

Ok.

Re: [PATCH] Move effective target check after other directives in c-c++-common/cpp/openmp-define-3.c

[Mike Stump]

On Oct 14, 2013, at 3:26 AM, Kyrill Tkachov  wrote:
> This minuscule patch moves the dg-require-effective-target fopenmp line after 
> the other directives in the c-c++-common/cpp/openmp-define-3.c test. 
> Otherwise dejagnu still proceeds to add -fopenmp to the options which fails 
> on bare metal arm and aarch64 targets.
> 
> [cc'ing Thomas because he added the test and Jakub because he merged the 
> OpenMP support recently]
> 
> Ok to commit to trunk?

Ok.

Re: [PATCH] decide edge's hotness when there is profile info

[Dehao Chen]

On Mon, Oct 14, 2013 at 12:49 PM, Jan Hubicka  wrote:
>> Not for instrumented FDO (not as I know of). But for AutoFDO, this
>> could be a potential risk because some callee is marked unlikely
>> executed simply because they are inlined and eliminated in the O2
>> binary. But in ipa-inline it will not get inlined because the edge is
>> not hot from cgraph_maybe_hot_edge_p (because callee is
>> UNLIKELY_EXECUTED), while the edge->count is actually hot.
>
> Can't you prevent setting calle to UNLIKELY_EXECUTED in these cases instead?
> It seems that having profile set incorrectly will lead to other problems 
> later, too.
> We discussed similar problem with Teresa about the missing profiles for 
> comdat,
> basically one should detect these cases as profile being lost and go with 
> guessed
> profile.  (I believe patch for that was posted, too, and so far it seems best 
> approach
> to this issue)

The current AutoFDO implementation will take all functions that do not
have have profile as normally executed, thus use guessed profile for
it. This is like using profile for truly hot functions, and using O2
for other functions. This works fine. However, it leads to larger code
size (approximately 10%~20% larger than FDO).

I'd like to introduce another mode for users who care about both
performance and code size, and can be sure that profile is
representative. In this mode, we will mark all functions without
sample as "unlikely executed". However, because AutoFDO use debug info
(of optimized code) to represent profile, it's possible that some hot
functions (say foo) are inlined and fully eliminated into another hot
function (say bar). So in the profile, bar is cold, and because the
profile for foo::bar is eliminated, bar will not be inlined into foo
before the profile annotation. However, after profile annotate, we can
infer from the bb count that foo->bar is hot, thus it should be
inlined in ipa-inline phase. However, because bar itself is marked
UNLIKELY_EXECUTED, it will not be inlined.

One possible workaround would be that during rebuild_cgraph_edges, if
we find an edge's callee is unlikely executed, add the edge count to
the callee's count and recalculate callee's frequency.

Dehao

>
> Honza

Go testsuite updated to 1.1.2 testsuite

[Ian Lance Taylor]

I've committed a patch to update the Go testsuite to a copy of the Go
1.1.2 testsuite.  I added some local changes to match gccgo error
messages.  Some of those changes were already made in Go mainline,
thanks to Rémy Oudompheng.  I made some others, and I will commit them
to Go mainline, but probably not until after the Go 1.2 release process
is complete.

The patch is large and, since it is just a copy of existing sources,
uninteresting.  The e-mail only contains the related changes to
go-test.exp, the testsuite driver.

Ran Go testsuite on x86_64-unknown-linux-gnu.  Committed to mainline.

As this patch is only testsuite changes, and mostly uninteresting ones
at that, I don't plan to commit it to the 4.8 branch.  With this patch
gccgo is wholly up to date with the Go 1.1.2 release.  After this I will
start working on updating gccgo to the upcoming Go 1.2 release.  Those
changes will go only on mainline, not on the GCC 4.8 branch.

The intent is that GCC 4.8.2 and later will be complete implementations
of Go 1.1.2 and that GCC 4.9.0 will be a complete implementation of Go
1.2.  (There are some gccgo changes on the 4.8 branch after the 4.8.2
release freeze, but they are minor bug fixes that will appear in 4.8.3
and later.)

Ian


2013-10-14  Ian Lance Taylor  

* go.test/go-test.exp (go-find-packages): New proc.
(go-gc-tests): Skip stress and safe tests.  Skip *.dir
subdirectories.  Do simple +build line matching.  Handle run with
arguments.  Handle errorcheckdir and rundircmpout.  Use packages
for rundir.  Remove special handling for bug191 and dwarf.


Index: go-test.exp
===
--- go-test.exp	(revision 203039)
+++ go-test.exp	(working copy)
@@ -242,6 +242,42 @@ proc go-set-goarch { } {
 setenv GOARCH $goarch
 }
 
+# Take a list of files and return a lists of lists, where each list is
+# the set of files in the same package.
+proc go-find-packages { test name files } {
+set packages [list]
+foreach f $files {
+	set fd [open $f r]
+	while 1 {
+	if { [gets $fd line] < 0 } {
+		close $fd
+		clone_output "$test: could not read $f"
+		unresolved $name
+		return [list]
+	}
+
+	if { [regexp "^package (\\w+)" $line match package] } {
+		set len [llength $packages]
+		for { set i 0 } { $i < $len } { incr i } {
+		set p [lindex $packages $i]
+		if { [lindex $p 0] == $package } {
+			lappend p $f
+			lset packages $i $p
+			break
+		}
+		}
+		if { $i >= $len } {
+		lappend packages [list $package $f]
+		}
+
+		close $fd
+		break
+	}
+	}
+}
+return $packages
+}
+
 proc go-gc-tests { } {
 global srcdir subdir
 global runtests
@@ -286,12 +322,28 @@ proc go-gc-tests { } {
 	continue
 	}
 
+	# Skip the files in stress; they are not tests.
+	if [string match "*go.test/test/stress/*" $test] {
+	continue
+	}
+
+	# Skip the files in safe; gccgo does not support safe mode.
+	if [string match "*go.test/test/safe/*" $test] {
+	continue
+	}
+
 	# Skip files in sub-subdirectories: they are components of
 	# other tests.
 	if [string match "*go.test/test/*/*/*" $test] {
 	continue
 	}
 
+	# Skip files in *.dir subdirectories: they are components of
+	# other tests.
+	if [string match "*go.test/test/*.dir/*" $test] {
+	continue
+	}
+
 	set name [dg-trim-dirname $srcdir $test]
 
 	# Skip certain tests if target is RTEMS OS.
@@ -379,6 +431,21 @@ proc go-gc-tests { } {
 		continue
 	}
 
+	if { [ string match "// +build *" $test_line ] } {
+		if { [ string match "*[getenv GOARCH]*" $test_line ] } {
+		continue
+		}
+		if { [ string match "*linux*" $test_line ] } {
+		continue
+		}
+		if { [ string match "*!windows*" $test_line ] } {
+		continue
+		}
+		close $fd
+		unsupported $name
+		set lines_ok 0
+	}
+
 	break
 	}
 
@@ -407,7 +474,8 @@ proc go-gc-tests { } {
 
 	set go_compile_args ""
 	set go_execute_args ""
-	if { [regexp ".*\\\$A.out (\[^|&>2\].*)\$" $test_line match progargs] } {
+	if { [regexp "// run (\[^|&>2\].*)\$" $test_line match progargs] \
+		 && ! [string match "*.go*" "$progargs"] } {
 	set go_execute_args $progargs
 	verbose -log "$test: go_execute_args is $go_execute_args"
 	set index [string last " $progargs" $test_line]
@@ -515,6 +583,27 @@ proc go-gc-tests { } {
 	go-execute-xfail $test
 	} elseif { $test_line == "// errorcheck" } {
 	errchk $test ""
+	} elseif { $test_line == "// errorcheckdir" } {
+	set hold_runtests $runtests
+	set runtests "go-test.exp"
+	set dir "[file rootname $test].dir"
+	set files [lsort [glob "$dir/*.go"]]
+	set packages [go-find-packages $test $name $files]
+	if { [llength $packages] > 0 } {
+		set dg-do-what-default "assemble"
+		set del [list]
+		set last [lindex $packages end]
+		set packages [lreplace $packages end end]
+		foreach p $packages {
+		dg-test -keep-output [lrange $p 1 end] "-O" "-w $DEFAULT_GOCFLAGS"
+		lappend

Re: [PATCH] decide edge's hotness when there is profile info

[Xinliang David Li]

Is it possible to update the callee node summary after profile
annotate (using information from inline instances which are not
inlined in early inline)?

David

On Mon, Oct 14, 2013 at 2:18 PM, Dehao Chen  wrote:
> On Mon, Oct 14, 2013 at 12:49 PM, Jan Hubicka  wrote:
>>> Not for instrumented FDO (not as I know of). But for AutoFDO, this
>>> could be a potential risk because some callee is marked unlikely
>>> executed simply because they are inlined and eliminated in the O2
>>> binary. But in ipa-inline it will not get inlined because the edge is
>>> not hot from cgraph_maybe_hot_edge_p (because callee is
>>> UNLIKELY_EXECUTED), while the edge->count is actually hot.
>>
>> Can't you prevent setting calle to UNLIKELY_EXECUTED in these cases instead?
>> It seems that having profile set incorrectly will lead to other problems 
>> later, too.
>> We discussed similar problem with Teresa about the missing profiles for 
>> comdat,
>> basically one should detect these cases as profile being lost and go with 
>> guessed
>> profile.  (I believe patch for that was posted, too, and so far it seems 
>> best approach
>> to this issue)
>
> The current AutoFDO implementation will take all functions that do not
> have have profile as normally executed, thus use guessed profile for
> it. This is like using profile for truly hot functions, and using O2
> for other functions. This works fine. However, it leads to larger code
> size (approximately 10%~20% larger than FDO).
>
> I'd like to introduce another mode for users who care about both
> performance and code size, and can be sure that profile is
> representative. In this mode, we will mark all functions without
> sample as "unlikely executed". However, because AutoFDO use debug info
> (of optimized code) to represent profile, it's possible that some hot
> functions (say foo) are inlined and fully eliminated into another hot
> function (say bar). So in the profile, bar is cold, and because the
> profile for foo::bar is eliminated, bar will not be inlined into foo
> before the profile annotation. However, after profile annotate, we can
> infer from the bb count that foo->bar is hot, thus it should be
> inlined in ipa-inline phase. However, because bar itself is marked
> UNLIKELY_EXECUTED, it will not be inlined.
>
> One possible workaround would be that during rebuild_cgraph_edges, if
> we find an edge's callee is unlikely executed, add the edge count to
> the callee's count and recalculate callee's frequency.
>
> Dehao
>
>>
>> Honza

Re: [PATCH] decide edge's hotness when there is profile info

[Dehao Chen]

For my test case, the entire inline instance is optimized away, so
there is no info about it in the profile. I can do some fixup in the
rebuild_cgraph_edge though.

Dehao

On Mon, Oct 14, 2013 at 2:27 PM, Xinliang David Li  wrote:
> Is it possible to update the callee node summary after profile
> annotate (using information from inline instances which are not
> inlined in early inline)?
>
> David
>
> On Mon, Oct 14, 2013 at 2:18 PM, Dehao Chen  wrote:
>> On Mon, Oct 14, 2013 at 12:49 PM, Jan Hubicka  wrote:
 Not for instrumented FDO (not as I know of). But for AutoFDO, this
 could be a potential risk because some callee is marked unlikely
 executed simply because they are inlined and eliminated in the O2
 binary. But in ipa-inline it will not get inlined because the edge is
 not hot from cgraph_maybe_hot_edge_p (because callee is
 UNLIKELY_EXECUTED), while the edge->count is actually hot.
>>>
>>> Can't you prevent setting calle to UNLIKELY_EXECUTED in these cases instead?
>>> It seems that having profile set incorrectly will lead to other problems 
>>> later, too.
>>> We discussed similar problem with Teresa about the missing profiles for 
>>> comdat,
>>> basically one should detect these cases as profile being lost and go with 
>>> guessed
>>> profile.  (I believe patch for that was posted, too, and so far it seems 
>>> best approach
>>> to this issue)
>>
>> The current AutoFDO implementation will take all functions that do not
>> have have profile as normally executed, thus use guessed profile for
>> it. This is like using profile for truly hot functions, and using O2
>> for other functions. This works fine. However, it leads to larger code
>> size (approximately 10%~20% larger than FDO).
>>
>> I'd like to introduce another mode for users who care about both
>> performance and code size, and can be sure that profile is
>> representative. In this mode, we will mark all functions without
>> sample as "unlikely executed". However, because AutoFDO use debug info
>> (of optimized code) to represent profile, it's possible that some hot
>> functions (say foo) are inlined and fully eliminated into another hot
>> function (say bar). So in the profile, bar is cold, and because the
>> profile for foo::bar is eliminated, bar will not be inlined into foo
>> before the profile annotation. However, after profile annotate, we can
>> infer from the bb count that foo->bar is hot, thus it should be
>> inlined in ipa-inline phase. However, because bar itself is marked
>> UNLIKELY_EXECUTED, it will not be inlined.
>>
>> One possible workaround would be that during rebuild_cgraph_edges, if
>> we find an edge's callee is unlikely executed, add the edge count to
>> the callee's count and recalculate callee's frequency.
>>
>> Dehao
>>
>>>
>>> Honza

Re: [PATCH] decide edge's hotness when there is profile info

[Jan Hubicka]

> For my test case, the entire inline instance is optimized away, so
> there is no info about it in the profile. I can do some fixup in the
> rebuild_cgraph_edge though.

Yep, I understand that.  In this case we should turn PROFILE_READ to 
PROFILE_GUESSED
and guess the profile when we detect this (i.e. we have edges with non-0 counts 
into
functions with 0 profile).  That should prvent these from getting 
UNLIKELY_EXECUTED
and they will be inlined normal way.

Honza
> 
> Dehao
> 
> On Mon, Oct 14, 2013 at 2:27 PM, Xinliang David Li  wrote:
> > Is it possible to update the callee node summary after profile
> > annotate (using information from inline instances which are not
> > inlined in early inline)?
> >
> > David
> >
> > On Mon, Oct 14, 2013 at 2:18 PM, Dehao Chen  wrote:
> >> On Mon, Oct 14, 2013 at 12:49 PM, Jan Hubicka  wrote:
>  Not for instrumented FDO (not as I know of). But for AutoFDO, this
>  could be a potential risk because some callee is marked unlikely
>  executed simply because they are inlined and eliminated in the O2
>  binary. But in ipa-inline it will not get inlined because the edge is
>  not hot from cgraph_maybe_hot_edge_p (because callee is
>  UNLIKELY_EXECUTED), while the edge->count is actually hot.
> >>>
> >>> Can't you prevent setting calle to UNLIKELY_EXECUTED in these cases 
> >>> instead?
> >>> It seems that having profile set incorrectly will lead to other problems 
> >>> later, too.
> >>> We discussed similar problem with Teresa about the missing profiles for 
> >>> comdat,
> >>> basically one should detect these cases as profile being lost and go with 
> >>> guessed
> >>> profile.  (I believe patch for that was posted, too, and so far it seems 
> >>> best approach
> >>> to this issue)
> >>
> >> The current AutoFDO implementation will take all functions that do not
> >> have have profile as normally executed, thus use guessed profile for
> >> it. This is like using profile for truly hot functions, and using O2
> >> for other functions. This works fine. However, it leads to larger code
> >> size (approximately 10%~20% larger than FDO).
> >>
> >> I'd like to introduce another mode for users who care about both
> >> performance and code size, and can be sure that profile is
> >> representative. In this mode, we will mark all functions without
> >> sample as "unlikely executed". However, because AutoFDO use debug info
> >> (of optimized code) to represent profile, it's possible that some hot
> >> functions (say foo) are inlined and fully eliminated into another hot
> >> function (say bar). So in the profile, bar is cold, and because the
> >> profile for foo::bar is eliminated, bar will not be inlined into foo
> >> before the profile annotation. However, after profile annotate, we can
> >> infer from the bb count that foo->bar is hot, thus it should be
> >> inlined in ipa-inline phase. However, because bar itself is marked
> >> UNLIKELY_EXECUTED, it will not be inlined.
> >>
> >> One possible workaround would be that during rebuild_cgraph_edges, if
> >> we find an edge's callee is unlikely executed, add the edge count to
> >> the callee's count and recalculate callee's frequency.
> >>
> >> Dehao
> >>
> >>>
> >>> Honza

[google gcc-4_8] LIPO: insert static vars to varpool

[Rong Xu]

Hi,

For google gcc-4_8 branch only.

This is fixes the NULL pointer dereference in copy_tree_r due to empty
varpool_node returned.

Passed the ICE compilation. Other tests are ongoing.

Thanks,

-Rong


2013-10-14  Rong Xu  

* cp/semantics.c (finish_compound_literal): Put static var to
varpool. This is for LIPO only.
* cp/call.c (make_temporary_var_for_ref_to_temp): Ditto.

Index: cp/semantics.c
===
--- cp/semantics.c  (revision 203471)
+++ cp/semantics.c  (working copy)
@@ -2486,6 +2486,10 @@ finish_compound_literal (tree type, tree compound_
   decl = pushdecl_top_level (decl);
   DECL_NAME (decl) = make_anon_name ();
   SET_DECL_ASSEMBLER_NAME (decl, DECL_NAME (decl));
+  /* Capture the current module info for statics.  */
+  if (L_IPO_COMP_MODE)
+varpool_node_for_decl (decl);
+
   return decl;
 }
   else
Index: cp/call.c
===
--- cp/call.c   (revision 203471)
+++ cp/call.c   (working copy)
@@ -9047,6 +9047,9 @@ make_temporary_var_for_ref_to_temp (tree decl, tre
   tree name;

   TREE_STATIC (var) = TREE_STATIC (decl);
+  /* Capture the current module info for statics.  */
+  if (L_IPO_COMP_MODE && TREE_STATIC (var))
+varpool_node_for_decl (var);
   DECL_TLS_MODEL (var) = DECL_TLS_MODEL (decl);
   name = mangle_ref_init_variable (decl);
   DECL_NAME (var) = name;

Re: [google gcc-4_8] LIPO: insert static vars to varpool.

[Xinliang David Li]

ok.

David

On Mon, Oct 14, 2013 at 2:58 PM, Rong Xu  wrote:
> Hi,
>
> For google gcc-4_8 branch only.
>
> This is fixes the NULL pointer dereference in copy_tree_r due to empty
> varpool_node returned.
>
> Passed the ICE compilation. Other tests are ongoing.
>
> Thanks,
>
> -Rong
>
>
> 2013-10-14  Rong Xu  
>
> * cp/semantics.c (finish_compound_literal): Put static var to
> varpool. This is for LIPO only.
> * cp/call.c (make_temporary_var_for_ref_to_temp): Ditto.
>
> Index: cp/semantics.c
> ===
> --- cp/semantics.c  (revision 203471)
> +++ cp/semantics.c  (working copy)
> @@ -2486,6 +2486,10 @@ finish_compound_literal (tree type, tree compound_
>decl = pushdecl_top_level (decl);
>DECL_NAME (decl) = make_anon_name ();
>SET_DECL_ASSEMBLER_NAME (decl, DECL_NAME (decl));
> +  /* Capture the current module info for statics.  */
> +  if (L_IPO_COMP_MODE)
> +varpool_node_for_decl (decl);
> +
>return decl;
>  }
>else
> Index: cp/call.c
> ===
> --- cp/call.c   (revision 203471)
> +++ cp/call.c   (working copy)
> @@ -9047,6 +9047,9 @@ make_temporary_var_for_ref_to_temp (tree decl, tre
>tree name;
>
>TREE_STATIC (var) = TREE_STATIC (decl);
> +  /* Capture the current module info for statics.  */
> +  if (L_IPO_COMP_MODE && TREE_STATIC (var))
> +varpool_node_for_decl (var);
>DECL_TLS_MODEL (var) = DECL_TLS_MODEL (decl);
>name = mangle_ref_init_variable (decl);
>DECL_NAME (var) = name;
>

Re: [PATCH] decide edge's hotness when there is profile info

[Xinliang David Li]

On Mon, Oct 14, 2013 at 2:34 PM, Dehao Chen  wrote:
> For my test case, the entire inline instance is optimized away,

do you mean there is no out of line instance for the target function
in the profile binary?

David

> so
> there is no info about it in the profile. I can do some fixup in the
> rebuild_cgraph_edge though.
>
> Dehao
>
> On Mon, Oct 14, 2013 at 2:27 PM, Xinliang David Li  wrote:
>> Is it possible to update the callee node summary after profile
>> annotate (using information from inline instances which are not
>> inlined in early inline)?
>>
>> David
>>
>> On Mon, Oct 14, 2013 at 2:18 PM, Dehao Chen  wrote:
>>> On Mon, Oct 14, 2013 at 12:49 PM, Jan Hubicka  wrote:
> Not for instrumented FDO (not as I know of). But for AutoFDO, this
> could be a potential risk because some callee is marked unlikely
> executed simply because they are inlined and eliminated in the O2
> binary. But in ipa-inline it will not get inlined because the edge is
> not hot from cgraph_maybe_hot_edge_p (because callee is
> UNLIKELY_EXECUTED), while the edge->count is actually hot.

 Can't you prevent setting calle to UNLIKELY_EXECUTED in these cases 
 instead?
 It seems that having profile set incorrectly will lead to other problems 
 later, too.
 We discussed similar problem with Teresa about the missing profiles for 
 comdat,
 basically one should detect these cases as profile being lost and go with 
 guessed
 profile.  (I believe patch for that was posted, too, and so far it seems 
 best approach
 to this issue)
>>>
>>> The current AutoFDO implementation will take all functions that do not
>>> have have profile as normally executed, thus use guessed profile for
>>> it. This is like using profile for truly hot functions, and using O2
>>> for other functions. This works fine. However, it leads to larger code
>>> size (approximately 10%~20% larger than FDO).
>>>
>>> I'd like to introduce another mode for users who care about both
>>> performance and code size, and can be sure that profile is
>>> representative. In this mode, we will mark all functions without
>>> sample as "unlikely executed". However, because AutoFDO use debug info
>>> (of optimized code) to represent profile, it's possible that some hot
>>> functions (say foo) are inlined and fully eliminated into another hot
>>> function (say bar). So in the profile, bar is cold, and because the
>>> profile for foo::bar is eliminated, bar will not be inlined into foo
>>> before the profile annotation. However, after profile annotate, we can
>>> infer from the bb count that foo->bar is hot, thus it should be
>>> inlined in ipa-inline phase. However, because bar itself is marked
>>> UNLIKELY_EXECUTED, it will not be inlined.
>>>
>>> One possible workaround would be that during rebuild_cgraph_edges, if
>>> we find an edge's callee is unlikely executed, add the edge count to
>>> the callee's count and recalculate callee's frequency.
>>>
>>> Dehao
>>>

 Honza

Re: [PATCH] decide edge's hotness when there is profile info

[Dehao Chen]

On Mon, Oct 14, 2013 at 3:04 PM, Xinliang David Li  wrote:
> On Mon, Oct 14, 2013 at 2:34 PM, Dehao Chen  wrote:
>> For my test case, the entire inline instance is optimized away,
>
> do you mean there is no out of line instance for the target function
> in the profile binary?

Yes, and there is no inline instance either.

Dehao

>
> David
>
>> so
>> there is no info about it in the profile. I can do some fixup in the
>> rebuild_cgraph_edge though.
>>
>> Dehao
>>
>> On Mon, Oct 14, 2013 at 2:27 PM, Xinliang David Li  
>> wrote:
>>> Is it possible to update the callee node summary after profile
>>> annotate (using information from inline instances which are not
>>> inlined in early inline)?
>>>
>>> David
>>>
>>> On Mon, Oct 14, 2013 at 2:18 PM, Dehao Chen  wrote:
 On Mon, Oct 14, 2013 at 12:49 PM, Jan Hubicka  wrote:
>> Not for instrumented FDO (not as I know of). But for AutoFDO, this
>> could be a potential risk because some callee is marked unlikely
>> executed simply because they are inlined and eliminated in the O2
>> binary. But in ipa-inline it will not get inlined because the edge is
>> not hot from cgraph_maybe_hot_edge_p (because callee is
>> UNLIKELY_EXECUTED), while the edge->count is actually hot.
>
> Can't you prevent setting calle to UNLIKELY_EXECUTED in these cases 
> instead?
> It seems that having profile set incorrectly will lead to other problems 
> later, too.
> We discussed similar problem with Teresa about the missing profiles for 
> comdat,
> basically one should detect these cases as profile being lost and go with 
> guessed
> profile.  (I believe patch for that was posted, too, and so far it seems 
> best approach
> to this issue)

 The current AutoFDO implementation will take all functions that do not
 have have profile as normally executed, thus use guessed profile for
 it. This is like using profile for truly hot functions, and using O2
 for other functions. This works fine. However, it leads to larger code
 size (approximately 10%~20% larger than FDO).

 I'd like to introduce another mode for users who care about both
 performance and code size, and can be sure that profile is
 representative. In this mode, we will mark all functions without
 sample as "unlikely executed". However, because AutoFDO use debug info
 (of optimized code) to represent profile, it's possible that some hot
 functions (say foo) are inlined and fully eliminated into another hot
 function (say bar). So in the profile, bar is cold, and because the
 profile for foo::bar is eliminated, bar will not be inlined into foo
 before the profile annotation. However, after profile annotate, we can
 infer from the bb count that foo->bar is hot, thus it should be
 inlined in ipa-inline phase. However, because bar itself is marked
 UNLIKELY_EXECUTED, it will not be inlined.

 One possible workaround would be that during rebuild_cgraph_edges, if
 we find an edge's callee is unlikely executed, add the edge count to
 the callee's count and recalculate callee's frequency.

 Dehao

>
> Honza

Re: [PATCH] decide edge's hotness when there is profile info

[Dehao Chen]

On Mon, Oct 14, 2013 at 2:50 PM, Jan Hubicka  wrote:
>> For my test case, the entire inline instance is optimized away, so
>> there is no info about it in the profile. I can do some fixup in the
>> rebuild_cgraph_edge though.
>
> Yep, I understand that.  In this case we should turn PROFILE_READ to 
> PROFILE_GUESSED
> and guess the profile when we detect this (i.e. we have edges with non-0 
> counts into
> functions with 0 profile).  That should prvent these from getting 
> UNLIKELY_EXECUTED
> and they will be inlined normal way.

Oh, actually in AutoFDO, only functions with samples will be marked as
PROFILE_READ. Others will all be marked as PROFILE_GUESSED.

Dehao

>
> Honza
>>
>> Dehao
>>
>> On Mon, Oct 14, 2013 at 2:27 PM, Xinliang David Li  
>> wrote:
>> > Is it possible to update the callee node summary after profile
>> > annotate (using information from inline instances which are not
>> > inlined in early inline)?
>> >
>> > David
>> >
>> > On Mon, Oct 14, 2013 at 2:18 PM, Dehao Chen  wrote:
>> >> On Mon, Oct 14, 2013 at 12:49 PM, Jan Hubicka  wrote:
>>  Not for instrumented FDO (not as I know of). But for AutoFDO, this
>>  could be a potential risk because some callee is marked unlikely
>>  executed simply because they are inlined and eliminated in the O2
>>  binary. But in ipa-inline it will not get inlined because the edge is
>>  not hot from cgraph_maybe_hot_edge_p (because callee is
>>  UNLIKELY_EXECUTED), while the edge->count is actually hot.
>> >>>
>> >>> Can't you prevent setting calle to UNLIKELY_EXECUTED in these cases 
>> >>> instead?
>> >>> It seems that having profile set incorrectly will lead to other problems 
>> >>> later, too.
>> >>> We discussed similar problem with Teresa about the missing profiles for 
>> >>> comdat,
>> >>> basically one should detect these cases as profile being lost and go 
>> >>> with guessed
>> >>> profile.  (I believe patch for that was posted, too, and so far it seems 
>> >>> best approach
>> >>> to this issue)
>> >>
>> >> The current AutoFDO implementation will take all functions that do not
>> >> have have profile as normally executed, thus use guessed profile for
>> >> it. This is like using profile for truly hot functions, and using O2
>> >> for other functions. This works fine. However, it leads to larger code
>> >> size (approximately 10%~20% larger than FDO).
>> >>
>> >> I'd like to introduce another mode for users who care about both
>> >> performance and code size, and can be sure that profile is
>> >> representative. In this mode, we will mark all functions without
>> >> sample as "unlikely executed". However, because AutoFDO use debug info
>> >> (of optimized code) to represent profile, it's possible that some hot
>> >> functions (say foo) are inlined and fully eliminated into another hot
>> >> function (say bar). So in the profile, bar is cold, and because the
>> >> profile for foo::bar is eliminated, bar will not be inlined into foo
>> >> before the profile annotation. However, after profile annotate, we can
>> >> infer from the bb count that foo->bar is hot, thus it should be
>> >> inlined in ipa-inline phase. However, because bar itself is marked
>> >> UNLIKELY_EXECUTED, it will not be inlined.
>> >>
>> >> One possible workaround would be that during rebuild_cgraph_edges, if
>> >> we find an edge's callee is unlikely executed, add the edge count to
>> >> the callee's count and recalculate callee's frequency.
>> >>
>> >> Dehao
>> >>
>> >>>
>> >>> Honza

Re: [PATCH v4 04/20] add configury

[Gerald Pfeifer]

On Fri, 27 Sep 2013, Tom Tromey wrote:
> Look a little further down in the patch:
> 
>  .cc.o .c.o:
> - $(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $< $(OUTPUT_OPTION)
> + $(COMPILE) $<
> + $(POSTCOMPILE)
> 
> ... that is, the patches didn't change this part.  ALL_COMPILERFLAGS was
> used before and it is used now.  I don't think this series touched how
> this variable is computed, either.

Looks like this was a red herring.  Sorry for that.

> If I were debugging this then I think I would start by looking in
> config.log to see why the compiler accepted -Wno-narrowing.

On Mon, 30 Sep 2013, Paolo Bonzini wrote:
> Why is install building anything?

I believe this may be the key element.  Configury really is _not_
an area I am an expert in, but I did some experiments:

 - Revision r202892 | law | 2013-09-25 15:33:34 + (Wed, 25 Sep 2013)
   builds just fine on my tester(s).

   Revision r202912 | tromey | 2013-09-25 16:33:30 + (Wed, 25 Sep 2013)
   fails.  So, this definitely was introduced by this patch set.

 - When I do a gmake at the top level of the build tree, nothing is 
   rebuilt at all.  This only happens during `gmake install`

 - The problem is not actually the set of flags being used.  On a 
   different tester clang is the bootstrap compiler, and this is
   also the one invoked for `gmake install`.  If anything, shouldn't
   the just built compiler be used _if_ anything is left to compile?

Is nobody else seeing this?  Or is everyone just lucky enough to have
a recent version of GCC as the default compiler?

Gerald