Re: GCC stack backtraces

[Richard Guenther]

On Thu, 13 Sep 2012, Diego Novillo wrote:

> 
> 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;
> }

Indeed - like the following, bootstrapped / tested on 
x86_64-unknown-linux-gnu, applied.

Richard.

2012-09-14  Richard Guenther  

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

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

Index: gcc/builtin-types.def
===
*** gcc/builtin-types.def.orig  2012-09-14 10:29:09.0 +0200
--- gcc/builtin-types.def   2012-09-14 10:36:56.980591201 +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-09-14 10:29:09.0 +0200
--- gcc/builtins.def2012-09-14 10:36:56.980591201 +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, "FILE", BT_FN_CONST_STRING, 
ATTR_NOTHROW_LEAF_LIST)
+ DEF_GCC_BUILTIN (BUILT_IN_FUNCTION, "FUNCTION", BT_FN_CONST_STRING, 
ATTR_NOTHROW_LEAF_LIST)
+ DEF_GCC_BUILTIN (BUILT_IN_LINE, "LINE", BT_FN_INT, ATTR_NOTHROW_LEAF_LIST)
+ 
  /* Synchronization Primitives.  */
  #include "sync-builtins.def"
  
Index: gcc/gimplify.c
===
*** gcc/gimplify.c.orig 2012-09-14 10:29:09.0 +0200
--- gcc/gimplify.c  2012-09-14 10:36:56.983591201 +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));
   

Re: GCC stack backtraces

[Pedro Larroy]

If you link with -rdynamic you can show a backtrace with something
like the attached code.

On Wed, Aug 29, 2012 at 9:22 AM, Ian Lance Taylor  wrote:
> I've spent the last couple of days working on a stack backtrace library.
>
> It uses the GCC unwind interface to collect a stack trace, and parses
> DWARF debug info to get file/line/function information.  (Of course it's
> silly to write yet another DWARF reader, but I didn't find an existing
> reader that seemed wholly suitable.)  The code currently only works for
> ELF/DWARF, but it's designed to support other object file and debug
> formats should anybody care to write them.  Since its use in GCC would
> be purely for GCC developers, it's not essential that it be fully
> portable.
>
>
> I picked a random PR that causes an ICE.  Here is the final output of
> g++ -c foo.cc:
>
> foo.cc:6:6: internal compiler error: in cp_lexer_new_from_tokens, at 
> cp/parser.c:638
> 0xed6e77 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
> ../../trunk/gcc/diagnostic.c:700
> 0xed7c2f internal_error(char const*, ...)
> ../../trunk/gcc/diagnostic.c:1003
> 0xed6703 fancy_abort(char const*, int, char const*)
> ../../trunk/gcc/diagnostic.c:1057
> 0x5bc3ee cp_lexer_new_from_tokens
> ../../trunk/gcc/cp/parser.c:638
> 0x5bc3ee cp_parser_push_lexer_for_tokens
> ../../trunk/gcc/cp/parser.c:3293
> 0x5c5510 cp_parser_late_parsing_for_member
> ../../trunk/gcc/cp/parser.c:21741
> 0x5c5510 cp_parser_class_specifier_1
> ../../trunk/gcc/cp/parser.c:18210
> 0x5c5510 cp_parser_class_specifier
> ../../trunk/gcc/cp/parser.c:18234
> 0x5c5510 cp_parser_type_specifier
> ../../trunk/gcc/cp/parser.c:13393
> 0x5dd56d cp_parser_decl_specifier_seq
> ../../trunk/gcc/cp/parser.c:10734
> 0x5e00d7 cp_parser_single_declaration
> ../../trunk/gcc/cp/parser.c:21344
> 0x5e1211 cp_parser_template_declaration_after_export
> ../../trunk/gcc/cp/parser.c:21231
> 0x5ea9f9 cp_parser_declaration
> ../../trunk/gcc/cp/parser.c:10186
> 0x5e9507 cp_parser_declaration_seq_opt
> ../../trunk/gcc/cp/parser.c:10108
> 0x5eae92 cp_parser_translation_unit
> ../../trunk/gcc/cp/parser.c:3760
> 0x5eae92 c_parse_file()
> ../../trunk/gcc/cp/parser.c:27585
> 0x6ed0c4 c_common_parse_file()
> ../../trunk/gcc/c-family/c-opts.c:1137
> 0xa2017b compile_file
> ../../trunk/gcc/toplev.c:546
> 0xa21d89 do_compile
> ../../trunk/gcc/toplev.c:1863
> 0xa21d89 toplev_main(int, char**)
> ../../trunk/gcc/toplev.c:1939
> 0x7fb0a50d8c4c ???
> ???:0
> 0x4c6db8 ???
> ???:0
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
>
>
> So, big deal.  You can get a stack backtrace from gdb anyhow.
>
> For a more interesting use I hacked ggc-common.c to collect detailed
> statistics when used with -fmem-report.  This gives us data similar to,
> and better than, that you get when you configure GCC with
> --enable-gather-detailed-mem-stats.  However, with this approach you do
> not need to recompile GCC.  Running this modified GCC with -fmem-report
> -O2 -g combine.ii took 36 seconds.  The full report is too large to
> attach here, but here are the last few entries of the ggc-common.c.
> Note that I spent exactly 0 seconds making the report pretty.
>
> 0xbf1151 ../../trunk/gcc/tree.c:7607 build_function_type(tree_node*, 
> tree_node*)
> 0x50f1c0 ../../trunk/gcc/cp/decl.c:9346 grokdeclarator(cp_declarator const*, 
> cp_decl_specifier_seq const*, decl_context, int, tree_node**)
> 0x514a75 ../../trunk/gcc/cp/decl.c:4366 start_decl(cp_declarator const*, 
> cp_decl_specifier_seq*, int, tree_node*, tree_node*, tree_node**)
> 0x5dbeca ../../trunk/gcc/cp/parser.c:15720 cp_parser_init_declarator
> 0x5de4ba ../../trunk/gcc/cp/parser.c:10445 cp_parser_simple_declaration
> 0x5e6337 ../../trunk/gcc/cp/parser.c:10326 cp_parser_block_declaration
> 0x5ea8fb ../../trunk/gcc/cp/parser.c:10222 cp_parser_declaration
> 0x5e9507 ../../trunk/gcc/cp/parser.c:10108 cp_parser_declaration_seq_opt
> 0x5eae92 ../../trunk/gcc/cp/parser.c:3760 cp_parser_translation_unit
> 0x5eae92 ../../trunk/gcc/cp/parser.c:27585 c_parse_file()
> 0x6ed0c4 ../../trunk/gcc/c-family/c-opts.c:1137 c_common_parse_file()
> 0xa2017b ../../trunk/gcc/toplev.c:546 compile_file
> 0xa21d89 ../../trunk/gcc/toplev.c:1863 do_compile
> 0xa21d89 ../../trunk/gcc/toplev.c:1939 toplev_main(int, char**)
> 0x7f4044f36c4c ???:0 ???
> 0x4c6db8 ???:0 ???
> 611352: 1.0%  0: 0.0% 181776: 0.6%  0: 0.0%   4721
> 0xbf342f ../../trunk/gcc/tree.c:1224 build_int_cst_wide(tree_node*, unsigned 
> long, long)
> 0xbf37a5 ../../trunk/gcc/tree.c:1065 double_int_to_tree(tree_node*, 
> double_int)
> 0xbf37ea ../../trunk/gcc/tree.c:1042 build_int_cst(tree_node*, long)
> 0xa19fee ../../trunk/gcc/stor-layout.c:2545 
> set_min_and_max_values_for_integral_

Re: Are Decimal operations are fully implemented/tested ?

[Vincent Lefevre]

On 2012-09-13 16:46:04 +, Joseph S. Myers wrote:
> 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).  

Note however that efficiency is important. If one had to choose to
spend time on compiling/implementing these operations, the focus
should be on the compiler first (actually, that's particularly
true for binary on IA-64, where these operations are part of the
instruction set and implemented in hardware on the Itanium).

Also if the (software) implementation of _Decimal64 operations and
_Decimal128 operations is done by GCC, it would be better to have
the implementation of the corresponding formatOf operations done
by GCC too (keep similar code at the same place).

> (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

round-to-odd would be a good solution if it were provided directly
in hardware. Otherwise a "direct" implementation would probably be
more efficient (in particular when the implementation of the usual
operation is done in software, like for decimal arithmetic).

Note: What makes round-to-odd work is that one gets a good enough
approximation to the exact result, and the sign of the error w.r.t.
a format with less precision is "encoded" in the result itself;
and all this information is kept in a single floating-point number.
But if you need to implement a formatOf operation and round-to-odd
isn't directly available, it may be better to get the approximation
and the error (or just its sign) in some more usual way, and work
with them without "packing" them in a single floating-point number.

> - and some processors (ia64?) may have direct support for it.

In binary only (because it doesn't have decimal support at all).

> But there are lots of new functions, that's just one.)

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

GCC 4.7.2 Release Candidate available from gcc.gnu.org

[Jakub Jelinek]

The first release candidate for GCC 4.7.2 is available from

 ftp://gcc.gnu.org/pub/gcc/snapshots/4.7.2-RC-20120914

and shortly its mirrors.  It has been generated from SVN revision 191287.

I have so far bootstrapped and tested the release candidate on
x86_64-linux.  Please test it and report any issues to bugzilla.

If all goes well, I'd like to release 4.7.2 at the end of next week.

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

[Jakub Jelinek]

The GCC 4.7 branch is now frozen for creating a first release candidate
of the GCC 4.7.2 release.

All changes need explicit release manager approval until the final
release of GCC 4.7.2 which should happen roughly one week after
the release candidate if no issues show up with it.



Previous Report
===

http://gcc.gnu.org/ml/gcc/2012-06/msg00195.html

Re: Are Decimal operations are fully implemented/tested ?

[Joseph S. Myers]

On Fri, 14 Sep 2012, Vincent Lefevre wrote:

> round-to-odd would be a good solution if it were provided directly
> in hardware. Otherwise a "direct" implementation would probably be
> more efficient (in particular when the implementation of the usual
> operation is done in software, like for decimal arithmetic).

It's the case for a lot of libm operations that the best implementation 
for software floating point is not the same as for hardware floating point 
(anything implemented using Dekker's algorithms or similar precision 
extension techniques would probably better use higher precision more 
directly on integers, for example).  It's also the case that there hasn't 
been any actual interest in optimal software implementations for these 
cases in glibc (I guess people concerned about floating-point performance 
are generally using hardware floating point).

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

C++ code in cgraph.h breaking Ada builds?

[Lawrence Crowl]

I added some reference returning member functions in cgraph.h,
and now Ada appears to break while including cgraph.h.  Huh?

gnatbind -nostdinc -I- -I. -Iada -I../../src2/gcc/ada
-I../../src2/gcc/ada/gcc-interface -o b_gnat1.adb -n ada/gnat1drv.ali
mv b_gnat1.adb b_gnat1.ads ada/
build/gengtype -S ../../src2/gcc -I gtyp-input.list -w tmp-gtype.state
gcc -c -g  -gnatp -gnatws -nostdinc -I- -I. -Iada -I../../src2/gcc/ada
-I../../src2/gcc/ada/gcc-interface ada/b_gnat1.adb -o ada/b_gnat1.o
../../src2/gcc/cgraph.h:200: unexpected character `&'
../../src2/gcc/cgraph.h:428: unexpected character `&'
../../src2/gcc/cgraph.h:467: unexpected character `&'


-- 
Lawrence Crowl

Re: C++ code in cgraph.h breaking Ada builds?

[Arnaud Charlet]

> I added some reference returning member functions in cgraph.h,
> and now Ada appears to break while including cgraph.h.  Huh?

I suspect you are doing a parallel build (make -jxx), and the error is actually
unrelated to the lines you quoted, but occurs above.

Do a 'make' and you'll see the error more clearly.

Arno

[OT] Control Flow Graph(CFG) into Abstract Syntax Tree(AST)

[James Courtier-Dutton]

Hi,

I know most compilers go from AST to CFG.
I am writing a decompiler, so I was wondering if anyone knew of any
documents describing how best to get from CFG to AST.
The decompiler project is open source.
https://github.com/jcdutton/libbeauty

The decompiler already contains a disassembler and a virtual machine
resulting in an annotated CFG. It uses information gained from using a
virtual machine to annotate the CFG. Another use of the VM will be to
help analyze self modifying code.

The decompiler can output C source code form the CFG, but it is not
easy to understand the result due to lack of structure such as for {}
loops.
I wish to create an AST from the CFG in order to be able to output for
{}, while {}  and if...then...else structure.

The CFG to AST step seems a little complicated, so I was looking for
some pointers to how best to do it to save me re-inventing the wheel.

Kind Regards

James

Re: C++ code in cgraph.h breaking Ada builds?

[Lawrence Crowl]

On 9/14/12, Arnaud Charlet  wrote:
>> I added some reference returning member functions in cgraph.h,
>> and now Ada appears to break while including cgraph.h.  Huh?
>
> I suspect you are doing a parallel build (make -jxx), and the error
> is actually unrelated to the lines you quoted, but occurs above.
>
> Do a 'make' and you'll see the error more clearly.

You are correct.  It appears that gengtype is falling over, which is
at least sensible!

Sorry for the confusion.

-- 
Lawrence Crowl

Re: [OT] Control Flow Graph(CFG) into Abstract Syntax Tree(AST)

[Mike Dupont]

thanks for sharing, will check this out.
mike

On Fri, Sep 14, 2012 at 9:05 PM, James Courtier-Dutton
 wrote:
> Hi,
>
> I know most compilers go from AST to CFG.
> I am writing a decompiler, so I was wondering if anyone knew of any
> documents describing how best to get from CFG to AST.
> The decompiler project is open source.
> https://github.com/jcdutton/libbeauty
>
> The decompiler already contains a disassembler and a virtual machine
> resulting in an annotated CFG. It uses information gained from using a
> virtual machine to annotate the CFG. Another use of the VM will be to
> help analyze self modifying code.
>
> The decompiler can output C source code form the CFG, but it is not
> easy to understand the result due to lack of structure such as for {}
> loops.
> I wish to create an AST from the CFG in order to be able to output for
> {}, while {}  and if...then...else structure.
>
> The CFG to AST step seems a little complicated, so I was looking for
> some pointers to how best to do it to save me re-inventing the wheel.
>
> Kind Regards
>
> James



-- 
James Michael DuPont
Member of Free Libre Open Source Software Kosova http://flossk.org
Saving wikipedia(tm) articles from deletion http://SpeedyDeletion.wikia.com
Contributor FOSM, the CC-BY-SA map of the world http://fosm.org
Mozilla Rep https://reps.mozilla.org/u/h4ck3rm1k3

gcc-4.6-20120914 is now available

[gccadmin]

Snapshot gcc-4.6-20120914 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20120914/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_6-branch 
revision 191314

You'll find:

 gcc-4.6-20120914.tar.bz2 Complete GCC

  MD5=52d0618b87e757f7a1513a217cf1d397
  SHA1=887c429b2b31c5090b535657d8cc8c4cd0d100df

Diffs from 4.6-20120907 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.6
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.