[buildrobot] SH broken

[Jan-Benedict Glaw]

Hi!

Between e4b851a364..130ab9aafd (= r209457..r209513), most probably
with 65b0537f9e (= r209482), I see failures for eg. sh64-linux (though
only when built with config-list.mk):

g++ -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions 
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic 
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common 
 -DHAVE_CONFIG_H -I. -I. -I../../../gcc/gcc -I../../../gcc/gcc/. 
-I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include 
-I/opt/cfarm/mpc/include  -I../../../gcc/gcc/../libdecnumber 
-I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
-I../../../gcc/gcc/../libbacktrace-I. -I. -I../../../gcc/gcc 
-I../../../gcc/gcc/. -I../../../gcc/gcc/../include 
-I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include  
-I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd 
-I../libdecnumber -I../../../gcc/gcc/../libbacktrace   
../../../gcc/gcc/config/sh/sh_treg_combine.cc
In file included from ../../../gcc/gcc/config/sh/sh_treg_combine.cc:32:0:
../../../gcc/gcc/tree-pass.h:99:24: error: ‘virtual unsigned int 
opt_pass::execute(function*)’ was hidden [-Werror=overloaded-virtual]
   virtual unsigned int execute (function *fun);
^
../../../gcc/gcc/config/sh/sh_treg_combine.cc:428:24: error:   by ‘virtual 
unsigned int sh_treg_combine::execute()’ [-Werror=overloaded-virtual]
   virtual unsigned int execute (void);
^
cc1plus: all warnings being treated as errors
make[2]: *** [sh_treg_combine.o] Error 1


Should be easy to fix by renaming sh's execute().

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of:  Fortschritt bedeutet, einen Schritt so zu machen,
the second  :   daß man den nächsten auch noch machen kann.


signature.asc
Description: Digital signature

[GSoC] use obstack in parse_c_expr

[Prathamesh Kulkarni]

Hi,
   There was a comment in parse_c_expr, mentioning to use obstack to
build c-code string. I have attached patch for the same.
OK to commit ?

* genmatch.c (parse_c_expr): Use obstack to build c code string.

Thanks and Regards,
Prathamesh
Index: gcc/genmatch.c
===
--- gcc/genmatch.c	(revision 209470)
+++ gcc/genmatch.c	(working copy)
@@ -689,15 +689,18 @@ parse_c_expr (cpp_reader *r, cpp_ttype s
   cpp_ttype end;
   unsigned opencnt;
   char *code;
+  struct obstack ob;
+ 
+  obstack_init (&ob);
   eat_token (r, start);
   if (start == CPP_OPEN_PAREN)
 {
-  code = xstrdup ("(");
+  obstack_grow (&ob, "(", 1);
   end = CPP_CLOSE_PAREN;
 }
   else if (start == CPP_OPEN_BRACE)
 {
-  code = xstrdup ("({");
+  obstack_grow (&ob, "({", 2);
   end = CPP_CLOSE_BRACE;
 }
   else
@@ -711,16 +714,16 @@ parse_c_expr (cpp_reader *r, cpp_ttype s
   if (token->type == CPP_ATSIGN)
 	{
 	  const cpp_token *n = peek (r);
+	  const char *number;
 	  if (n->type == CPP_NUMBER
 	  && !(n->flags & PREV_WHITE))
 	{
-	  code = (char *)xrealloc (code, strlen (code)
-   + strlen ("captures[") + 4);
 	  if (token->flags & PREV_WHITE)
-		strcat (code, " ");
-	  strcat (code, "captures[");
-	  strcat (code, get_number (r));
-	  strcat (code, "]");
+		obstack_grow (&ob, " ", 1);
+	  number = get_number (r);
+	  obstack_grow (&ob, "captures[", strlen ("captures["));
+	  obstack_grow (&ob, number, strlen (number)); 
+	  obstack_grow (&ob, "]", 1);
 	  continue;
 	}
 	}
@@ -734,24 +737,19 @@ parse_c_expr (cpp_reader *r, cpp_ttype s
 
   /* Output the token as string.  */
   char *tk = (char *)cpp_token_as_text (r, token);
-  code = (char *)xrealloc (code, strlen (code) + strlen (tk) + 2);
   if (token->flags & PREV_WHITE)
-	strcat (code, " ");
-  strcat (code, tk);
+	obstack_grow (&ob, " ", 1);	
+  obstack_grow (&ob, tk, strlen (tk));
 }
   while (1);
   if (end == CPP_CLOSE_PAREN)
-{
-  code = (char *)xrealloc (code, strlen (code) + 1 + 1);
-  strcat (code, ")");
-}
+obstack_grow0 (&ob, ")", 1);
   else if (end == CPP_CLOSE_BRACE)
-{
-  code = (char *)xrealloc (code, strlen (code) + 1 + 2);
-  strcat (code, "})");
-}
+obstack_grow0 (&ob, "})", 2);
   else
 gcc_unreachable ();
+
+  code = (char *) obstack_finish (&ob);
   return new c_expr (code);
 }
 

Re: [buildrobot] SH broken

[Trevor Saunders]

On Thu, Apr 24, 2014 at 04:24:37PM +0200, Jan-Benedict Glaw wrote:
> Hi!
> 
> Between e4b851a364..130ab9aafd (= r209457..r209513), most probably
> with 65b0537f9e (= r209482), I see failures for eg. sh64-linux (though
> only when built with config-list.mk):
> 
> g++ -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions 
> -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing 
> -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual 
> -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror 
> -fno-common  -DHAVE_CONFIG_H -I. -I. -I../../../gcc/gcc -I../../../gcc/gcc/. 
> -I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include 
> -I/opt/cfarm/mpc/include  -I../../../gcc/gcc/../libdecnumber 
> -I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
> -I../../../gcc/gcc/../libbacktrace-I. -I. -I../../../gcc/gcc 
> -I../../../gcc/gcc/. -I../../../gcc/gcc/../include 
> -I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include  
> -I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd 
> -I../libdecnumber -I../../../gcc/gcc/../libbacktrace   
> ../../../gcc/gcc/config/sh/sh_treg_combine.cc
> In file included from ../../../gcc/gcc/config/sh/sh_treg_combine.cc:32:0:
> ../../../gcc/gcc/tree-pass.h:99:24: error: ‘virtual unsigned int 
> opt_pass::execute(function*)’ was hidden [-Werror=overloaded-virtual]
>virtual unsigned int execute (function *fun);
> ^
> ../../../gcc/gcc/config/sh/sh_treg_combine.cc:428:24: error:   by ‘virtual 
> unsigned int sh_treg_combine::execute()’ [-Werror=overloaded-virtual]
>virtual unsigned int execute (void);
> ^
> cc1plus: all warnings being treated as errors
> make[2]: *** [sh_treg_combine.o] Error 1
> 
> 
> Should be easy to fix by renaming sh's execute().

no, that was a bug in r209483, which I think I fixed by commit the below
as r209751

Trev

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 7cab1de..5e91288 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2014-04-24  Trevor Saunders  
+
+   * config/sh/sh_treg_combine.c (sh_treg_combine::execute): Take
+   function * argument.
+
 2014-04-24  Alan Lawrence  
 
* config/aarch64/aarch64.c (aarch64_evpc_tbl): Enable for bigendian.
diff --git a/gcc/config/sh/sh_treg_combine.cc b/gcc/config/sh/sh_treg_combine.cc
index 57eddd2..2548479 100644
--- a/gcc/config/sh/sh_treg_combine.cc
+++ b/gcc/config/sh/sh_treg_combine.cc
@@ -425,7 +425,7 @@ public:
   sh_treg_combine (gcc::context* ctx, bool split_insns, const char* name);
   virtual ~sh_treg_combine (void);
   virtual bool gate (function *);
-  virtual unsigned int execute (void);
+  virtual unsigned int execute (function *);
 
 private:
   // Type of ccreg store that is supported.
@@ -1441,7 +1441,7 @@ sh_treg_combine::gate (function *)
 }
 
 unsigned int
-sh_treg_combine::execute (void)
+sh_treg_combine::execute (function *fun)
 {
   unsigned int ccr0 = INVALID_REGNUM;
   unsigned int ccr1 = INVALID_REGNUM;
@@ -1468,7 +1468,7 @@ sh_treg_combine::execute (void)
   // Look for basic blocks that end with a conditional branch and try to
   // optimize them.
   basic_block bb;
-  FOR_EACH_BB_FN (bb, cfun)
+  FOR_EACH_BB_FN (bb, fun)
 {
   rtx i = BB_END (bb);
   if (any_condjump_p (i) && onlyjump_p (i))
> 
> MfG, JBG
> 
> -- 
>   Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
> Signature of:  Fortschritt bedeutet, einen Schritt so zu machen,
> the second  :   daß man den nächsten auch noch machen kann.




signature.asc
Description: Digital signature

Re: [buildrobot] SH broken

[Jan-Benedict Glaw]

Hi Trevor!

On Thu, 2014-04-24 11:39:17 -0400, Trevor Saunders  
wrote:
> On Thu, Apr 24, 2014 at 04:24:37PM +0200, Jan-Benedict Glaw wrote:
> > Between e4b851a364..130ab9aafd (= r209457..r209513), most probably
> > with 65b0537f9e (= r209482), I see failures for eg. sh64-linux (though
> > only when built with config-list.mk):
[...]
> no, that was a bug in r209483, which I think I fixed by commit the below
> as r209751

Ah, I missed that commit and that combination wasn't "recently" built.
(Next built will probbaly be noon, tomorrow.)

  Thanks for already having it fixed faster than light! :)

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of: "Debugging is twice as hard as writing the code in the first 
place.
the second  :  Therefore, if you write the code as cleverly as possible, you 
are,
   by definition, not smart enough to debug it." - Brian W. 
Kernighan


signature.asc
Description: Digital signature

How can I generate a new function at compile time?

[Benedikt Huber]

Hi!

I want to uninline some basic blocks to a separate function to aid slp 
vectorization.
The new pass runs just before the slp vectorization pass.
As a first try I create an new and empty function.
Which in turn will be filled with some copies of basic blocks from the original 
function.
As an example I was looking at code in omp-low.c
The pass itself seem to be successful,
however I do not see the new function printed when using 
-fdump-tree-all-details.
Further more an ipa pass crashes with a segfault at an seemingly unrelated 
location.
I call gcc like this.

/home/bhuber/sandbox/gcc/install/bin/gcc -std=c99 -O3 -I . -S 
-fdump-tree-all-details -fdump-rtl-all-details -fdump-tree-vect=vec.out 
-fopt-info-vec-missed=missed.out -ftree-vectorizer-verbose=6 
-funinline-innermost-loops -ftree-slp-vectorize -Wall -Wextra 
/home/bhuber/sandbox/try/vectorizable.c
/home/bhuber/sandbox/try/vectorizable.c: In function '_GLOBAL__N_foo':
/home/bhuber/sandbox/try/vectorizable.c:61:6: internal compiler error: 
Segmentation fault
 void foo ( int M
  ^
0x99be1f crash_signal
../../src/gcc/toplev.c:337
0x9cdaac execute_fixup_cfg()
../../src/gcc/tree-cfg.c:8413
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
bhuber@android:~/sandbox/try/foo$

The function to generate the empty function looks like this:

static unsigned int 
make_empty_function (void)
{ 
  tree name, decl, type, t, block;
  gimple_seq body = NULL;
  gimple bind;

  type = build_function_type_list (void_type_node, NULL_TREE);
  name = get_file_function_name ("N");
  decl = build_decl (input_location,
 FUNCTION_DECL, name, type);

  TREE_STATIC (decl) = 1;
  TREE_USED (decl) = 1;
  DECL_ARTIFICIAL (decl) = 1;
  DECL_NAMELESS (decl) = 0;
  DECL_IGNORED_P (decl) = 0;
  TREE_PUBLIC (decl) = 0;
  DECL_UNINLINABLE (decl) = 1;
  DECL_EXTERNAL (decl) = 0;
  DECL_CONTEXT (decl) = NULL_TREE;

  block = make_node (BLOCK);
  DECL_INITIAL (decl) = block;

  t = build_decl (DECL_SOURCE_LOCATION (decl),
  RESULT_DECL, NULL_TREE, void_type_node);
  DECL_ARTIFICIAL (t) = 1;
  DECL_IGNORED_P (t) = 1;
  DECL_CONTEXT (t) = decl;
  DECL_RESULT (decl) = t;

  push_struct_function (decl);

  pop_cfun ();

  bind = gimple_build_bind (NULL, body, block);
  gimple_seq_add_stmt (&body, bind);
  gimple_set_body (decl, body);

  DECL_STRUCT_FUNCTION (decl)->curr_properties = cfun->curr_properties;

  cgraph_add_new_function (decl, true);

  return 0;
}

I am working on trunk.
Please note that this is experimental code to get to know gcc internals.
What am I doing wrong?

Thank you in advance and best regards,
Benedikt

[buildrobot] ARM: Missing initializers for Cortex A8

[Jan-Benedict Glaw]

Hi!

Seems the new cost model for Cortex A8 is missing two initializer
fields:

g++ -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions 
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic 
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common 
 -DHAVE_CONFIG_H -I. -I. -I../../../gcc/gcc -I../../../gcc/gcc/. 
-I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include 
-I/opt/cfarm/mpc/include  -I../../../gcc/gcc/../libdecnumber 
-I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
-I../../../gcc/gcc/../libbacktrace-o arm.o -MT arm.o -MMD -MP -MF 
./.deps/arm.TPo ../../../gcc/gcc/config/arm/arm.c
../../../gcc/gcc/config/arm/arm.c:1714:1: error: missing initializer for member 
‘tune_params::disparage_flag_setting_t16_encodings’ 
[-Werror=missing-field-initializers]
 };
 ^
../../../gcc/gcc/config/arm/arm.c:1714:1: error: missing initializer for member 
‘tune_params::disparage_partial_flag_setting_t16_encodings’ 
[-Werror=missing-field-initializers]
cc1plus: all warnings being treated as errors
make[2]: *** [arm.o] Error 1


(Cf. http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=207555)

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of:  Träume nicht von Deinem Leben: Lebe Deinen Traum!
the second  :


signature.asc
Description: Digital signature

Re: [RFC] Meta-description for tree and gimple folding

[Jeff Law]

On 02/28/14 08:21, Kai Tietz wrote:

Hmm,  this all reminds me about the approach Andrew Pinski and I came
up with two years ago.  All in all I think it might be worth to
express folding-patterns in a more abstract way.  So the md-like Lisp
syntax for this seems to be just stringent.  We make use of such a
script-language already for machine-description.

Nevertheless I doubt that we really want to have same facility for
fold-const and gimple.  Instead I got the impression that we would
prefer to have all folding-optimizations instead in Middle-end
(GIMPLE).  We need folding in front-end (AST) mostly for determination
of constant-expression detection. Otherwise we want to keep maximum of
original AST to have best results for debugging (and even to think
about having alternative FE on our middle/backend) and code-analyzers.
This is the core of what I want to see happening.  I'm open to whatever 
methods we use to take us in that direction.


The way I tend to think leads me to a "hmm, fold-const.c does X, move it 
to gimple" and iterate approach.  But again, that's just the way I tend 
to look at problems.


If we can describe significant hunks of folding using a pattern 
selection language and generate code to recognize and transform the IL, 
then that seems good to me  as long as we keep the goal of moving most 
folding out of the front-ends.


So if Richi and GSOC students want to experiment in this space, possibly 
baking off with other approaches that delay folding, that's fine with me.


Jeff

Re: [RFC] Meta-description for tree and gimple folding

[Jeff Law]

On 03/03/14 07:05, Kai Tietz wrote:

[the possibility to use offline verification tools for the
transforms comes to my mind as well]

This is actually a pretty interesting idea.  As it would allow us to
do testing for this area without  side-effects by high-level passes,
target-properties, etc
Yea, the question is are there offline tools that we can use for this 
purpose?  I simply haven't explored that space at all.;



Additional I think we need to some related conceptional decisions here
too. I saw here some missing concept for abstraction of
back-end/target specific limitations in middle-end.  For example the
branch-cost optimization, or the target's pattern-preferences, etc.
We lack to make a consequent difference between target-agnostic and
target-specific passes in middle-end.  There were introduced
diagnostics in late passes.  For latter see "possible integral
overflow on additions in loops" as one sample. Such stuff hinders us
to do better job on pattern-folding in many places. Right now we tend
to introduce backend-representation too early (eg branch-cost,
avoiding packing of conditional patterns due some limitiation on some
targets, too early jump-threading, etc).  So I think we should think
about at least some passes doing target/backend agnostic
folding/normalization, and doing target/backend-specific
pattern-transformation explicit in latter passes.
There's a lot of open questions in this space -- but I don't think we 
necessarily have to tie them together.  If we can express 
simplifications in the way Richi wants, that seems largely independent 
of most of these issues.


jeff

gcc-4.8-20140424 is now available

[gccadmin]

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

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

You'll find:

 gcc-4.8-20140424.tar.bz2 Complete GCC

  MD5=3552af39b6ca3499552abab5a0fd1753
  SHA1=4998fd6af0ca31cc0ecc2a59cafb64d429189794

Diffs from 4.8-20140417 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.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.

Call for Topics and Sponsors -- Workshop on Open Source Development Tools 2014

[Mingjie Xing]

*
Call for Topics and Sponsors

Workshop on Open Source Development Tools 2014 (i.e. HelloGCC Workshop)
Beijing, China
Sep. 13rd, 2014 (TBD)
HelloGCC Work Group (www.hellogcc.org)
*
Open Source Development Tools Workshop (i.e. HelloGCC Workshop) is
a meeting for open source software developers. You can share your work,
study and learning experience of open source software development here.
Our main topics is open source development tools.

The content of topics can be:
* GNU tool chains (gcc, gdb, binutils, etc)
* LLVM or other open source compilers
* other tools of open source development, debug and simulation

The form of topics can be:
* the introduction of your own work
* the introduction of your work did in the past
* tutorial, experience and etc
* other forms of presentation, such as lightning talk

If you have some topics, please contact us:
* send email to hello...@freelists.org (need to subscribe
http://www.freelists.org/list/hellogcc first)
* login into freenode IRC #hellogcc room

Important Date:
* the deadline of topics and sponsors solicitation: Aug 1st, 2014

Previous Meetings:
* HelloGCC 2013: http://www.hellogcc.org/?p=33518
* HelloGCC 2012: http://linux.chinaunix.net/hellogcc2012
* HelloGCC 2011: http://linux.chinaunix.net/hellogcc2011
* HelloGCC 2010: http://linux.chinaunix.net/hellogcc2010
* HelloGCC 2009: http://www.aka-kernel.org/news/hellogcc/index.html

If you want to sponsor us, we will very appreciate and please contact us via
hellogcc.workgr...@gmail.com