Re: [GSOC] LTO dump tool project
On 06/26/2018 09:45 PM, Hrishikesh Kulkarni wrote: > Hi, > > I have created another branch lto-dump-tool-improved as suggested. > I have applied the patch for separation to lto-dump binary, made a few > necessary changes in other files and it is running successfully. > I will keep on adding previous work to this branch incrementally. > > Please find the diff file attached for dumping of TREE statistics and > GIMPLE statistics. > > for example: > (after configuring with --enable-gather-detailed-mem-stats) > -fdump-lto-gimple-stats will dump > GIMPLE statements > Kind Stmts Bytes > --- > assignments0 0 > phi nodes 0 0 > conditionals 0 0 > everything else0 0 > --- > Total 0 0 > --- > > -fdump-lto-tree-stats will dump > > Tree Statistics > > Kind Nodes Bytes > > decls 4327 932672 > types 1531 257208 > blocks 0 0 > stmts 0 0 > refs 0 0 > exprs 4128 > constants 82 2060 > identifiers 4430 177200 > vecs 16 28544 > binfos 0 0 > ssa names 0 0 > constructors 0 0 > random kinds7301 291952 > lang_decl kinds0 0 > lang_type kinds0 0 > omp clauses0 0 > > Total 176911689764 > > > > Please advise, > > Hrishikesh > > On Wed, Jun 27, 2018 at 1:00 AM, Hrishikesh Kulkarni > wrote: >> Hi, >> >> I have created another branch lto-dump-tool-improved as suggested. Hi. Great, it's now much more readable! >> I have applied the patch for separation to lto-dump binary, made a few >> necessary changes in other files and it is running successfully. >> I will keep on adding previous work to this branch incrementally. Good. >> >> Please find the diff file attached for dumping of TREE statistics and GIMPLE >> statistics. >> >> for example: >> (after configuring with --enable-gather-detailed-mem-stats) >> -fdump-lto-gimple-stats will dump >> GIMPLE statements >> Kind Stmts Bytes >> --- >> assignments0 0 >> phi nodes 0 0 >> conditionals 0 0 >> everything else0 0 >> --- >> Total 0 0 >> --- I guess problem is that all numbers are zeros. Easiest what you can do is to run normal GCC with -fmem-report and add '-wrapper gdb,--args'. That will open GCC in debugger, that you can place a breapoint and you'll see a backtrace. >> >> -fdump-lto-tree-stats will dump >> >> Tree Statistics >> >> Kind Nodes Bytes >> >> decls 4327 932672 >> types 1531 257208 >> blocks 0 0 >> stmts 0 0 >> refs 0 0 >> exprs 4128 >> constants 82 2060 >> identifiers 4430 177200 >> vecs 16 28544 >> binfos 0 0 >> ssa names 0 0 >> constructors 0 0 >> random kinds7301 291952 >> lang_decl kinds0 0 >> lang_type kinds0 0 >> omp clauses0 0 >> >> Total 176911689764 >> The output looks good for trees. >> >> >> Please advise, Next time, please specify where is problem for which you need advise ;) Martin >> >> Hrishikesh >> >> >> On Fri, Jun 22, 2018 at 2:29 PM, Martin Liška wrote: >>> >>> On 06/18/2018 10:45 AM, Martin Jambor wrote: Hi, On Sun, Jun 17 2018, Hrishikesh Kulkarni wrote: > Hi, > > I am trying to isolate the dump tool into real lto-dump tool. I have > started with the copy&paste of lto.c into lto-dump.c and done the > changes to Make-lang.in and config-lang.in suggested by Martin (patch > attached). However when I try to build, I get the following error: > > In file included from ../../gcc/gcc/lto/lto-dump.c:24:0: > > ../../gcc/gcc/coretypes.h:397:24: fatal error: insn-modes.h: No such > > file or directory > > compilation terminated. > > > I am unable to find the
Re: [GSOC] LTO dump tool project
On 06/27/2018 10:06 PM, Hrishikesh Kulkarni wrote: > Hi, > > I have added new command line options: > -no-demangle -> for the default non demangled output > -no-sort -> for the list of symbols in order of their occurrence > -alpha-sort -> for the list of symbols in their alphabetical order > -reverse-sort -> for the list of symbols in reversed order > -defined-only -> for only the defined symbols Hi. Good progress. > > for example: > > ../stage1-build/gcc/lto-dump test_hello.o -fdump-lto-list -alpha-sort > -demangle -defined-only -reverse-sort Now as you have a separate tool (lto-dump), you can strip 'fdump-lto' prefix from the older options. > > will dump > > Symbol Table > Name Type Visibility Size > mainfunctiondefault > kvariabledefault > foofunctiondefault > barfunctiondefault > > It is a reversed alphabetical order of demangled symbol names which > have been defined(hence printf excluded). > Along with this I have also added all previous progress with reference > to symbol table to the new branch. > > For further options to add like -size-sort and -print-size I tried to > access size of the symbol with symtab node using > TREE_INT_CST_LOW(DECL_SIZE(node->decl)); > but I am unable to do so. > So how should I proceed with it? Sent advises via instant messaging. Martin > > Please find the diff file attached herewith. I have also pushed the > changes to the new branch. > > Please advise, > > Hrishikesh> > On Wed, Jun 27, 2018 at 1:15 AM, Hrishikesh Kulkarni > wrote: >> Hi, >> >> I have created another branch lto-dump-tool-improved as suggested. >> I have applied the patch for separation to lto-dump binary, made a few >> necessary changes in other files and it is running successfully. >> I will keep on adding previous work to this branch incrementally. >> >> Please find the diff file attached for dumping of TREE statistics and >> GIMPLE statistics. >> >> for example: >> (after configuring with --enable-gather-detailed-mem-stats) >> -fdump-lto-gimple-stats will dump >> GIMPLE statements >> Kind Stmts Bytes >> --- >> assignments0 0 >> phi nodes 0 0 >> conditionals 0 0 >> everything else0 0 >> --- >> Total 0 0 >> --- >> >> -fdump-lto-tree-stats will dump >> >> Tree Statistics >> >> Kind Nodes Bytes >> >> decls 4327 932672 >> types 1531 257208 >> blocks 0 0 >> stmts 0 0 >> refs 0 0 >> exprs 4128 >> constants 82 2060 >> identifiers 4430 177200 >> vecs 16 28544 >> binfos 0 0 >> ssa names 0 0 >> constructors 0 0 >> random kinds7301 291952 >> lang_decl kinds0 0 >> lang_type kinds0 0 >> omp clauses0 0 >> >> Total 176911689764 >> >> >> >> Please advise, >> >> Hrishikesh >> >> On Wed, Jun 27, 2018 at 1:00 AM, Hrishikesh Kulkarni >> wrote: >>> Hi, >>> >>> I have created another branch lto-dump-tool-improved as suggested. >>> I have applied the patch for separation to lto-dump binary, made a few >>> necessary changes in other files and it is running successfully. >>> I will keep on adding previous work to this branch incrementally. >>> >>> Please find the diff file attached for dumping of TREE statistics and GIMPLE >>> statistics. >>> >>> for example: >>> (after configuring with --enable-gather-detailed-mem-stats) >>> -fdump-lto-gimple-stats will dump >>> GIMPLE statements >>> Kind Stmts Bytes >>> --- >>> assignments0 0 >>> phi nodes 0 0 >>> conditionals 0 0 >>> everything else0 0 >>> --- >>> Total 0 0 >>> --- >>> >>> -fdump-lto-tree-stats will dump >>> >>> Tree Statistics >>> >>> Kind Nodes Bytes >>> >>> decls 4327 932672 >>> types 1531 257208 >>> blocks 0 0 >>> stmts 0 0 >>> refs 0 0 >>> exprs 4128 >>> constants 82 2060
[PATCH] Add new tests for --completion option.
Hi.
I would like to add some DejaGNU tests for completion option.
Ready for trunk?
Martin
>From a735068032aa9ce82e5f56172f1b99bc2c90ac0f Mon Sep 17 00:00:00 2001
From: marxin
Date: Fri, 29 Jun 2018 11:18:21 +0200
Subject: [PATCH] Add new tests for --completion option.
gcc/testsuite/ChangeLog:
2018-06-29 Martin Liska
* gcc.dg/completion-1.c: New test.
* gcc.dg/completion-2.c: New test.
* gcc.dg/completion-3.c: New test.
---
gcc/testsuite/gcc.dg/completion-1.c | 8
gcc/testsuite/gcc.dg/completion-2.c | 10 ++
gcc/testsuite/gcc.dg/completion-3.c | 13 +
3 files changed, 31 insertions(+)
create mode 100644 gcc/testsuite/gcc.dg/completion-1.c
create mode 100644 gcc/testsuite/gcc.dg/completion-2.c
create mode 100644 gcc/testsuite/gcc.dg/completion-3.c
diff --git a/gcc/testsuite/gcc.dg/completion-1.c b/gcc/testsuite/gcc.dg/completion-1.c
new file mode 100644
index 000..64da64f1c69
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/completion-1.c
@@ -0,0 +1,8 @@
+/* { dg-do compile } */
+/* { dg-options "--completion=-fipa-ic" } */
+
+/* { dg-begin-multiline-output "" }
+-fipa-icf
+-fipa-icf-functions
+-fipa-icf-variables
+ { dg-end-multiline-output "" } */
diff --git a/gcc/testsuite/gcc.dg/completion-2.c b/gcc/testsuite/gcc.dg/completion-2.c
new file mode 100644
index 000..ac7508591de
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/completion-2.c
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-options "--completion=-flto-parti" } */
+
+/* { dg-begin-multiline-output "" }
+-flto-partition=1to1
+-flto-partition=balanced
+-flto-partition=max
+-flto-partition=none
+-flto-partition=one
+ { dg-end-multiline-output "" } */
diff --git a/gcc/testsuite/gcc.dg/completion-3.c b/gcc/testsuite/gcc.dg/completion-3.c
new file mode 100644
index 000..3c4a89ffdd5
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/completion-3.c
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options "--completion=--param=asan-" } */
+
+/* { dg-begin-multiline-output "" }
+--param=asan-stack
+--param=asan-instrument-allocas
+--param=asan-globals
+--param=asan-instrument-writes
+--param=asan-instrument-reads
+--param=asan-memintrin
+--param=asan-use-after-return
+--param=asan-instrumentation-with-call-threshold
+ { dg-end-multiline-output "" } */
--
2.17.1
Re: [PATCH] Add new tests for --completion option.
On 06/29/2018 03:20 AM, Martin Liška wrote: > Hi. > > I would like to add some DejaGNU tests for completion option. > > Ready for trunk? > Martin > > > 0001-Add-new-tests-for-completion-option.patch > > > From a735068032aa9ce82e5f56172f1b99bc2c90ac0f Mon Sep 17 00:00:00 2001 > From: marxin > Date: Fri, 29 Jun 2018 11:18:21 +0200 > Subject: [PATCH] Add new tests for --completion option. > > gcc/testsuite/ChangeLog: > > 2018-06-29 Martin Liska > > * gcc.dg/completion-1.c: New test. > * gcc.dg/completion-2.c: New test. > * gcc.dg/completion-3.c: New test. OK jeff
Re: [PATCH] Add new tests for --completion option.
On 6/29/18, Martin Liška wrote: > Hi. > > I would like to add some DejaGNU tests for completion option. > > Ready for trunk? > Martin > So, correct me if I'm wrong, but these tests would need to be updated every time a new option starting like one of those is added, right? If so, can you think of any ways to ease the increased maintenance efforts?
Re: [PATCH] Add new tests for --completion option.
On Fri, 2018-06-29 at 13:19 -0400, Eric Gallager wrote: > On 6/29/18, Martin Liška wrote: > > Hi. > > > > I would like to add some DejaGNU tests for completion option. > > > > Ready for trunk? > > Martin Presumably the point of the DejaGnu tests is: (a) to give us some integration testing, to complement the unit-tests expressed via "selftest::" in the code (b) in future, to allow for target-specific tests for the aspects of completion (some target-specific options have non-standard arg-parsing, iirc, so might need special-casing if the completion code is to be perfect). Also, it allows for other DejaGnu-based filters to be used. > So, correct me if I'm wrong, but these tests would need to be updated > every time a new option starting like one of those is added, right? You're correct. > If > so, can you think of any ways to ease the increased maintenance > efforts? I think/hope Martin picked option prefixes for which the results are relatively stable. If it turns out to be a pain, other options can be chosen, but I guess we can cross that bridge when we come to it. Dave
gcc-8-20180629 is now available
Snapshot gcc-8-20180629 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/8-20180629/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-8-branch revision 262262 You'll find: gcc-8-20180629.tar.xzComplete GCC SHA256=9b895bba96a92ca5666c4335fa71827067668919b36b88e1793b363fc5403aca SHA1=f08ac913b52e30af5d7f8efd24427ef90294f3b3 Diffs from 8-20180622 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-8 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.
