Re: GCC stack backtraces

2012-09-13 Thread Richard Guenther 
On Wed, 12 Sep 2012, Gabriel Dos Reis wrote:

> On Wed, Sep 12, 2012 at 11:50 AM, Diego Novillo  wrote:
> 
> > Alternately, we could use Richi's approach I suppose (what happened to that
> > patch, btw)?
> 
> I was under the impression that the patch was good to go in; Richard?

Yes.  I've made the name adjustment agreed to - it's __builtin_FILE, etc.,
now and removed the const attribute from the builtins - they are not
really const.

Bootstrap & testing in progress, I will commit this patch if that
succeeds unless somebody objects quickly.

That allows us to get rid of the macros in vec.h that wrap the
functions using the default argument trick for -fmem-report.  Note
that --enable-gather-detailed-mem-stats use of the builtins needs
to be conditional on support for them - so beware of some more
#ifdefery or configury before you do this change.

Thanks,
Richard.

2012-09-13  Richard Guenther  

* builtin-types.def (BT_FN_CONST_STRING): Add.
* builtins.def (BUILT_IN_FILE_LOCATION, BUILT_IN_FUNCTION_LOCATION,
BUILT_IN_LINE_LOCATION): New builtins.
* gimplify.c (gimplify_call_expr): Expand them.
* doc/extend.texi (__builtin_LINE, __builtin_FUNCTION,
__builtin_FILE): Document.

* g++.dg/ext/builtin-location.C: New testcase.

Index: gcc/builtin-types.def
===
*** gcc/builtin-types.def.orig  2012-08-15 15:39:49.0 +0200
--- gcc/builtin-types.def   2012-09-13 14:27:34.815103538 +0200
*** DEF_POINTER_TYPE (BT_PTR_PTR, BT_PTR)
*** 140,145 
--- 140,146 
  DEF_FUNCTION_TYPE_0 (BT_FN_VOID, BT_VOID)
  DEF_FUNCTION_TYPE_0 (BT_FN_BOOL, BT_BOOL)
  DEF_FUNCTION_TYPE_0 (BT_FN_PTR, BT_PTR)
+ DEF_FUNCTION_TYPE_0 (BT_FN_CONST_STRING, BT_CONST_STRING)
  DEF_FUNCTION_TYPE_0 (BT_FN_PID, BT_PID)
  DEF_FUNCTION_TYPE_0 (BT_FN_INT, BT_INT)
  DEF_FUNCTION_TYPE_0 (BT_FN_UINT, BT_UINT)
Index: gcc/builtins.def
===
*** gcc/builtins.def.orig   2012-08-15 15:39:49.0 +0200
--- gcc/builtins.def2012-09-13 14:30:48.822096864 +0200
*** DEF_BUILTIN_STUB (BUILT_IN_EH_POINTER, "
*** 801,806 
--- 801,811 
  DEF_BUILTIN_STUB (BUILT_IN_EH_FILTER, "__builtin_eh_filter")
  DEF_BUILTIN_STUB (BUILT_IN_EH_COPY_VALUES, "__builtin_eh_copy_values")
  
+ /* __FILE__, __LINE__, __FUNCTION__ as builtins.  */
+ DEF_GCC_BUILTIN (BUILT_IN_FILE_LOCATION, "FILE", BT_FN_CONST_STRING, 
ATTR_NOTHROW_LEAF_LIST)
+ DEF_GCC_BUILTIN (BUILT_IN_FUNCTION_LOCATION, "FUNCTION", BT_FN_CONST_STRING, 
ATTR_NOTHROW_LEAF_LIST)
+ DEF_GCC_BUILTIN (BUILT_IN_LINE_LOCATION, "LINE", BT_FN_INT, 
ATTR_NOTHROW_LEAF_LIST)
+ 
  /* Synchronization Primitives.  */
  #include "sync-builtins.def"
  
Index: gcc/gimplify.c
===
*** gcc/gimplify.c.orig 2012-09-04 15:24:24.0 +0200
--- gcc/gimplify.c  2012-09-13 14:27:34.825103540 +0200
*** gimplify_call_expr (tree *expr_p, gimple
*** 2498,2518 
   transform all calls in the same manner as the expanders do, but
   we do transform most of them.  */
fndecl = get_callee_fndecl (*expr_p);
!   if (fndecl && DECL_BUILT_IN (fndecl))
! {
!   tree new_tree = fold_call_expr (input_location, *expr_p, !want_value);
! 
!   if (new_tree && new_tree != *expr_p)
!   {
! /* There was a transformation of this call which computes the
!same value, but in a more efficient way.  Return and try
!again.  */
! *expr_p = new_tree;
! return GS_OK;
!   }
! 
!   if (DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_NORMAL
! && DECL_FUNCTION_CODE (fndecl) == BUILT_IN_VA_START)
  {
  builtin_va_start_p = TRUE;
  if (call_expr_nargs (*expr_p) < 2)
--- 2498,2508 
   transform all calls in the same manner as the expanders do, but
   we do transform most of them.  */
fndecl = get_callee_fndecl (*expr_p);
!   if (fndecl
!   && DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_NORMAL)
! switch (DECL_FUNCTION_CODE (fndecl))
!   {
!   case BUILT_IN_VA_START:
  {
  builtin_va_start_p = TRUE;
  if (call_expr_nargs (*expr_p) < 2)
*** gimplify_call_expr (tree *expr_p, gimple
*** 2527,2532 
--- 2517,2556 
  *expr_p = build_empty_stmt (EXPR_LOCATION (*expr_p));
  return GS_OK;
}
+ break;
+   }
+   case BUILT_IN_LINE_LOCATION:
+   {
+ expanded_location loc = expand_location (EXPR_LOCATION (*expr_p));
+ *expr_p = build_int_cst (TREE_TYPE (*expr_p), loc.line);
+ return GS_OK;
+   }
+   case BUILT_IN_FILE_LOCATION:
+   {
+ expanded_location loc = expand_location (EXPR_LOCATION (*expr_p));
+ *expr_p = build_string_literal (strlen (loc.file) + 1, loc.file);
+ return GS_OK;
+   }
+

Re: GCC stack backtraces

2012-09-13 Thread Richard Guenther 
On Thu, 13 Sep 2012, Richard Guenther wrote:

> On Wed, 12 Sep 2012, Gabriel Dos Reis wrote:
> 
> > On Wed, Sep 12, 2012 at 11:50 AM, Diego Novillo  wrote:
> > 
> > > Alternately, we could use Richi's approach I suppose (what happened to 
> > > that
> > > patch, btw)?
> > 
> > I was under the impression that the patch was good to go in; Richard?
> 
> Yes.  I've made the name adjustment agreed to - it's __builtin_FILE, etc.,
> now and removed the const attribute from the builtins - they are not
> really const.
> 
> Bootstrap & testing in progress, I will commit this patch if that
> succeeds unless somebody objects quickly.
> 
> That allows us to get rid of the macros in vec.h that wrap the
> functions using the default argument trick for -fmem-report.  Note
> that --enable-gather-detailed-mem-stats use of the builtins needs
> to be conditional on support for them - so beware of some more
> #ifdefery or configury before you do this change.

Just noticed missing s/BUILT_IN_FILE_LOCATION/BUILT_IN_FILE/ etc.,
consider that fixed.

Richard.

> Thanks,
> Richard.
> 
> 2012-09-13  Richard Guenther  
> 
>   * builtin-types.def (BT_FN_CONST_STRING): Add.
>   * builtins.def (BUILT_IN_FILE_LOCATION, BUILT_IN_FUNCTION_LOCATION,
>   BUILT_IN_LINE_LOCATION): New builtins.
>   * gimplify.c (gimplify_call_expr): Expand them.
>   * doc/extend.texi (__builtin_LINE, __builtin_FUNCTION,
>   __builtin_FILE): Document.
> 
>   * g++.dg/ext/builtin-location.C: New testcase.
> 
> Index: gcc/builtin-types.def
> ===
> *** gcc/builtin-types.def.orig2012-08-15 15:39:49.0 +0200
> --- gcc/builtin-types.def 2012-09-13 14:27:34.815103538 +0200
> *** DEF_POINTER_TYPE (BT_PTR_PTR, BT_PTR)
> *** 140,145 
> --- 140,146 
>   DEF_FUNCTION_TYPE_0 (BT_FN_VOID, BT_VOID)
>   DEF_FUNCTION_TYPE_0 (BT_FN_BOOL, BT_BOOL)
>   DEF_FUNCTION_TYPE_0 (BT_FN_PTR, BT_PTR)
> + DEF_FUNCTION_TYPE_0 (BT_FN_CONST_STRING, BT_CONST_STRING)
>   DEF_FUNCTION_TYPE_0 (BT_FN_PID, BT_PID)
>   DEF_FUNCTION_TYPE_0 (BT_FN_INT, BT_INT)
>   DEF_FUNCTION_TYPE_0 (BT_FN_UINT, BT_UINT)
> Index: gcc/builtins.def
> ===
> *** gcc/builtins.def.orig 2012-08-15 15:39:49.0 +0200
> --- gcc/builtins.def  2012-09-13 14:30:48.822096864 +0200
> *** DEF_BUILTIN_STUB (BUILT_IN_EH_POINTER, "
> *** 801,806 
> --- 801,811 
>   DEF_BUILTIN_STUB (BUILT_IN_EH_FILTER, "__builtin_eh_filter")
>   DEF_BUILTIN_STUB (BUILT_IN_EH_COPY_VALUES, "__builtin_eh_copy_values")
>   
> + /* __FILE__, __LINE__, __FUNCTION__ as builtins.  */
> + DEF_GCC_BUILTIN (BUILT_IN_FILE_LOCATION, "FILE", BT_FN_CONST_STRING, 
> ATTR_NOTHROW_LEAF_LIST)
> + DEF_GCC_BUILTIN (BUILT_IN_FUNCTION_LOCATION, "FUNCTION", 
> BT_FN_CONST_STRING, ATTR_NOTHROW_LEAF_LIST)
> + DEF_GCC_BUILTIN (BUILT_IN_LINE_LOCATION, "LINE", BT_FN_INT, 
> ATTR_NOTHROW_LEAF_LIST)
> + 
>   /* Synchronization Primitives.  */
>   #include "sync-builtins.def"
>   
> Index: gcc/gimplify.c
> ===
> *** gcc/gimplify.c.orig   2012-09-04 15:24:24.0 +0200
> --- gcc/gimplify.c2012-09-13 14:27:34.825103540 +0200
> *** gimplify_call_expr (tree *expr_p, gimple
> *** 2498,2518 
>transform all calls in the same manner as the expanders do, but
>we do transform most of them.  */
> fndecl = get_callee_fndecl (*expr_p);
> !   if (fndecl && DECL_BUILT_IN (fndecl))
> ! {
> !   tree new_tree = fold_call_expr (input_location, *expr_p, !want_value);
> ! 
> !   if (new_tree && new_tree != *expr_p)
> ! {
> !   /* There was a transformation of this call which computes the
> !  same value, but in a more efficient way.  Return and try
> !  again.  */
> !   *expr_p = new_tree;
> !   return GS_OK;
> ! }
> ! 
> !   if (DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_NORMAL
> !   && DECL_FUNCTION_CODE (fndecl) == BUILT_IN_VA_START)
>   {
> builtin_va_start_p = TRUE;
> if (call_expr_nargs (*expr_p) < 2)
> --- 2498,2508 
>transform all calls in the same manner as the expanders do, but
>we do transform most of them.  */
> fndecl = get_callee_fndecl (*expr_p);
> !   if (fndecl
> !   && DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_NORMAL)
> ! switch (DECL_FUNCTION_CODE (fndecl))
> !   {
> !   case BUILT_IN_VA_START:
>   {
> builtin_va_start_p = TRUE;
> if (call_expr_nargs (*expr_p) < 2)
> *** gimplify_call_expr (tree *expr_p, gimple
> *** 2527,2532 
> --- 2517,2556 
> *expr_p = build_empty_stmt (EXPR_LOCATION (*expr_p));
> return GS_OK;
>   }
> +   break;
> + }
> +   case BUILT_IN_LINE_LOCATION:
> + {
> +   expanded_location loc = expand_location (EXPR_LOCATION (*exp

Re: Are Decimal operations are fully implemented/tested ?

2012-09-13 Thread Vincent Lefevre 
On 2012-09-12 15:55:16 +0300, Hesham Moustafa wrote:
> If exist, what are the known bugs in the current implementation of
> Decimal / IEEE 754-2008 standard ?

I don't know any reported bug of the decimal implementation (though
PR 37845 about the FP_CONTRACT pragma, which affects binary on some
machines, might also affect decimal in some distant future if it is
still not fixed).

But if you want an example, I don't think that the formatOf
arithmetic operations (IEEE 754-2008 §5.4.1 -- that's a "shall")
are implemented by GCC, either for binary or for decimal, say
add two _Decimal128 numbers and round to _Decimal64 directly
(with a single rounding).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Cgraph Modification Plan

2012-09-13 Thread Michael Matz 
Hi,

On Tue, 11 Sep 2012, Lawrence Crowl wrote:

> change
> node->symbol.whatever
> to
> node->ref_symbol().whatever

Please don't uglify the compiler with this.  If GTY deficiencies force you 
to do that, then hold off on it until GTY doesn't force you anymore.


Ciao,
Michael.

Re: Are Decimal operations are fully implemented/tested ?

2012-09-13 Thread Joseph S. Myers 
On Thu, 13 Sep 2012, Vincent Lefevre wrote:

> But if you want an example, I don't think that the formatOf
> arithmetic operations (IEEE 754-2008 §5.4.1 -- that's a "shall")
> are implemented by GCC, either for binary or for decimal, say
> add two _Decimal128 numbers and round to _Decimal64 directly
> (with a single rounding).

For binary floating point, the draft C bindings (I'm looking at WG14 
N1605, which is just a draft of the first part of what's supposed to end 
up as a five-part document) defines such operations as library operations 
(e.g. float fadd(double x, double y);) rather than compiler ones (although 
of course the compiler might have corresponding built-in functions).  
N1582 indicates that names such as _Float32 f32addf64(_Float64 x, _Float64 
y); would be used for the functions with specific IEEE types - so I guess 
d64addd128 for the example you give.

The draft C bindings for IEEE 754-2008 are at a sufficiently early stage 
that before putting anything in mainline glibc it would be important to 
look carefully at how likely any incompatible changes would be (more 
likely for some functions than for others, I expect).  Of course they will 
only go in (for either GCC or glibc) if someone contributes 
implementations, and they would be a sufficiently large project that they 
aren't particularly likely to be done as a spare-time project.

(Implementing fadd itself probably isn't hard; given exception and 
rounding mode support you should be able to do it with round-to-odd as 
described by Boldo and Melquiond - and some processors (ia64?) may have 
direct support for it.  But there are lots of new functions, that's just 
one.)

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

Re: GCC stack backtraces

2012-09-13 Thread Diego Novillo 


Thanks for the patch!


On 2012-09-13 08:46 , Richard Guenther wrote:


Index: gcc/testsuite/g++.dg/ext/builtin-location.C
===
*** /dev/null   1970-01-01 00:00:00.0 +
--- gcc/testsuite/g++.dg/ext/builtin-location.C 2012-09-13 14:27:34.868103539 
+0200
***
*** 0 
--- 1,20 
+ // { dg-do link }
+
+ #include 
+
+ void bar (const char *file = __builtin_FILE (),
+ const char *function = __builtin_FUNCTION (),
+ int line = __builtin_LINE ())
+ {
+   printf ("%s (%s): %d\n", file, function, line);


Shouldn't this test that it is getting the file, function and line for 
the call to bar() inside of main?


Maybe something like:

const char *FILE;
const char *FN;
int LINE;

void bar (const char *file = __builtin_FILE (),
const char *function = __builtin_FUNCTION (),
int line = __builtin_LINE ())
{
  FILE = file;
  FN = function;
  LINE = line;
}

int main()
{
  bar();
  if (LINE != __LINE__ - 1)
return 1;
  if (strcmp (function, "main") != 0)
return 1;
  if (strcmp (file, "builtin-location.C") != 0)
return 1;
  return 0;
}



Diego.

INSN_EXACT_TICK & scheduler backtrack

2012-09-13 Thread Greg McGary 
When the timing requirements are not met upon queueing an insn with
INSN_EXACT_TICK, the scheduler backtracks.  This seems wasteful.
Why not prioritize INSN_EXACT_TICK insns so that we queue them
first on the cycle they need?