RE: disable-nls breaks build

[Paulo Matos]

After a couple of tests, this failure seems to have nothing to do with nls. 
Even if I remove all the flags it still fails.
I guess it can only be a case of tool versions:
Building with GCC 4.7.2, gmp 4.3.0, mpfr 2.4.1, mpc 0.8.1. Would you think any 
of these could be affecting the build?

Cheers,

Paulo Matos


> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Paulo
> Matos
> Sent: 30 April 2013 14:33
> To: gcc@gcc.gnu.org
> Subject: disable-nls breaks build
> 
> Hello,
> 
> I just cloned gcc because of an error I was seeing in my port. It seems to me
> that the problem is the --disable-nls option but I haven't research yet why
> this is happening.
> 
> If I configure with:
> ../gcc/configure --prefix=/home/pmatos/work/tmp/install-gcc/ --exec-
> prefix=/home/pmatos/work/tmp/install-gcc/x86_64-rhel5 --disable-nls --enable-
> checking --disable-shared   --enable-lto --enable-languages=c --enable-
> werror-always
> 
> and make.
> I get after awhile:
> ../../gcc/gcc/langhooks.c: In function 'void
> lhd_print_error_function(diagnostic_context*, const char*,
> diagnostic_info*)':
> ../../gcc/gcc/langhooks.c:457:41: error: unknown conversion type character
> 'r' in format [-Werror=format]
> ../../gcc/gcc/langhooks.c:457:41: error: format '%d' expects argument of type
> 'int', but argument 5 has type 'const char*' [-Werror=format]
> ../../gcc/gcc/langhooks.c:457:41: error: unknown conversion type character
> 'R' in format [-Werror=format]
> ../../gcc/gcc/langhooks.c:457:41: error: too many arguments for format [-
> Werror=format-extra-args]
> ../../gcc/gcc/langhooks.c:462:31: error: unknown conversion type character
> 'r' in format [-Werror=format]
> ../../gcc/gcc/langhooks.c:462:31: error: format '%d' expects argument of type
> 'int', but argument 5 has type 'const char*' [-Werror=format]
> ../../gcc/gcc/langhooks.c:462:31: error: unknown conversion type character
> 'R' in format [-Werror=format]
> ../../gcc/gcc/langhooks.c:462:31: error: too many arguments for format [-
> Werror=format-extra-args]
> 
> I am unsure about how nls works and what's causing this since pp_printf seems
> to be fine with %r, %R. I guess the important detail is that the string is
> surrounded by _(...).
> 
> Any hints on this?
> 
> Paulo Matos
> 

RE: disable-nls breaks build

[Paulo Matos]

Turns out that this is a warning thrown by GCC that ends up as an error due to 
--enable-werror-always.

Paulo Matos

> -Original Message-
> > From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Paulo
> > Matos
> > Sent: 30 April 2013 14:33
> > To: gcc@gcc.gnu.org
> > Subject: disable-nls breaks build
> >
> > and make.
> > I get after awhile:
> > ../../gcc/gcc/langhooks.c: In function 'void
> > lhd_print_error_function(diagnostic_context*, const char*,
> > diagnostic_info*)':
> > ../../gcc/gcc/langhooks.c:457:41: error: unknown conversion type character
> > 'r' in format [-Werror=format]
> > ../../gcc/gcc/langhooks.c:457:41: error: format '%d' expects argument of
> type
> > 'int', but argument 5 has type 'const char*' [-Werror=format]
> > ../../gcc/gcc/langhooks.c:457:41: error: unknown conversion type character
> > 'R' in format [-Werror=format]
> > ../../gcc/gcc/langhooks.c:457:41: error: too many arguments for format [-
> > Werror=format-extra-args]
> > ../../gcc/gcc/langhooks.c:462:31: error: unknown conversion type character
> > 'r' in format [-Werror=format]
> > ../../gcc/gcc/langhooks.c:462:31: error: format '%d' expects argument of
> type
> > 'int', but argument 5 has type 'const char*' [-Werror=format]
> > ../../gcc/gcc/langhooks.c:462:31: error: unknown conversion type character
> > 'R' in format [-Werror=format]
> > ../../gcc/gcc/langhooks.c:462:31: error: too many arguments for format [-
> > Werror=format-extra-args]
> >
> > I am unsure about how nls works and what's causing this since pp_printf
> seems
> > to be fine with %r, %R. I guess the important detail is that the string is
> > surrounded by _(...).
> >
> > Any hints on this?
> >
> > Paulo Matos
> >

Re: Computation and usage of SSA_NAME_PTR_INFO

[Nikhil Patil]

On Tue, Apr 30, 2013 at 1:32 PM, Richard Biener
 wrote:
> On Mon, Apr 29, 2013 at 7:34 PM, Nikhil Patil  
> wrote:
>> Hello,
>>
>> 1. Which passes of gcc make use of points-to information in
>> SSA_NAME_PTR_INFO (or more precisely, pt_solution) in doing
>> optimizations?
>
> All passes that query the alias oracle (tree-ssa-alias.h) which is almost
> all passes doing optimization of memory accesses.

Thanks a lot for giving direction. I will try finding the passes.

>
>>
>> 2. Also, who computes this points-to information and populates
>> pt_solution? Is it ONLY ipa-pta pass?
>
> It is points-to analysis, both the IPA variant and the local variant
> (ealias and alias
> passes).

>From what I could understand, gimple passes "pass_build_ealias"
(ealias) and "pass_build_alias" (alias) flags "TODO_rebuild_alias" at
end and then function "execute_function_todo" from passes.c calls
"compute_may_aliases ()" which eventually computes points-to
information.

Then the IPA PTA pass finds a more precise points-to information.
Please correct if I am wrong.

>
>> When I accessed pt_solution through a plugin which REPLACES ipa-pta
>> pass, I found that the information (in pt_solution) with and without
>> ipa-pta pass differs only in terms of flags in pt_solution. Here with
>> the examples I could construct, I found that the bitmap 'vars' in
>> pt_solution is same for both the cases. Is it always true?
>
> In theory IPA PTA should be able to compute a more precise solution,
> thus have different (less) bits set in 'vars'.  There are several testcases
> that show this, look for ipa-pta* testcases in gcc/testsuite/
>
> Richard.
>
>> Can someone please help in clarifying these doubts.
>>
>> Thanks in advance.
>>
>> --
>> Regards,
>> Nikhil Patil.

--
Regards,
Nikhil Patil.

Re: GSoC openMP task scheduling Advice

[guray.ozen]

Dear All,

Thank you for your reply Tobias.

By the way Mr Jakup I hope my approach is make sense for you.

I changed GOMP_SPINCOUNT factor and i got speedup more than.
I attached my trace that was profiled extrae and paraver. Light blue
mean idle, Dark blue mean running, Yellow scheduling, Fork/Join. First
trace belongs to intel trace with default configuration. 2nd trace
with spincount=10, 3rd spincount=100, 5rd with spincount=infinity. In
addition to you can see running time as nanosecond bottom right
corner.
https://raw.github.com/grypp/gcc-gsoc-taskscheduler/master/openmp.png

In my opinion gcc is little bit slower tha intel because of task
scheduling. Some threads (for example thread number 4,9,10 in the
multisort-omp-12-spin10 trace or 7,9,11 threads in the
multisort-omp-12-infinity trace) waiting too much to other threads.
You can see my trace image,

My advice i want to change or add task scheduler algorithm. The first
thing I really want to add work-stealing mechanism. In this way i can
decrease task waiting time and i can provide load-balancing. Also task
stealing has a strategy that Untied task can steal parents task. For
example parent task-stealing is very good for parallel-multisort
algortihm or recursive tasks. If parents task cannot be stolen then
the default task stealing techniques is used. In addition to i can
change task scheduler as follows : when a task is created, the
creating task is suspended and the executing thread switches to the
newly created task. When a task is suspended the task is placed in a
per thread local pool. So that i can provide better data locality.

I'm working on this topics but i am not sure my idea is good or not.
Probably i need change my way. Please can you help me? I would like to
work with OpenMP in gcc.

Regards,

Güray Özen
Polytechnic University of Catalonia



2013/4/30 Tobias Burnus :
> guray.ozen wrote:
>>
>> I thought gcc tasks/threads waiting too much on the idle than intel
>> compiler's threads.
>
>
> Regarding busy waits, you could try to tune the values of the GOMP_SPINCOUNT
> environment variable. Search for "@node GOMP_SPINCOUNT" in
> http://gcc.gnu.org/viewcvs/gcc/branches/gomp-4_0-branch/libgomp/libgomp.texi?view=co&content-type=text%2Fplain
> for details.
>
> If you have enough cores which are available, there shouldn't be a problem
> with idle. (Except with tasks where one could argue that the threads should
> do task stealing instead.)
>
> Tobias,
> who leaves the other questions to Jakub

Testing a plugin optimization with 'make check' (slashes in options)

[Steve Ellcey]

I was wondering if someone would tell me how to pass an option that 
contains slashes into 'make check'?

For example if I want to test a compiler using a simulator and the -O3
option I can run:

make check RUNTESTFLAGS="--target_board='mips-sim-mti32/-O3'"

I want to run this:

make check 
RUNTESTFLAGS="--target_board='mips-sim-mti32/-fplugin=/home/sellcey/plugin/dynopt.so'"

But the slashes in the plugin path are messing things up (I tried putting 1, 2,
or 3 backslashes in front of the forward slashes in the path but that did not
help and I tried putting /home/sellcey/plugin/dynopt.so in single quotes, that
did not help either.

Steve Ellcey
sell...@imgtec.com

Identifying global state within GCC

[David Malcolm]

I had a go at writing a custom pass to try to locate places where GCC
makes use of global state.

You can see the pass here (which I implemented using gcc-python-plugin):
https://gcc-python-plugin.readthedocs.org/en/latest/working-with-c.html#finding-global-variables

A build log from recompiling gcc using this pass can be seen at:
http://fedorapeople.org/~dmalcolm/gcc/2013-05-01/make.log
(about 12MB in size; I killed it when I saw that stage 1 was done).

I'm sure there are quite a few false positives in there.

Hope this is helpful.  FWIW I had an earlier version of the pass which
merely gave *declaration* sites for global variables, rather than all
*uses* of such variables.

Dave

RE: Testing a plugin optimization with 'make check' (slashes in options)

[Matthew Fortune]

Hi,

> I was wondering if someone would tell me how to pass an option that
> contains slashes into 'make check'?
> 
> For example if I want to test a compiler using a simulator and the -O3 option
> I can run:
> 
> make check RUNTESTFLAGS="--target_board='mips-sim-mti32/-O3'"
> 
> I want to run this:
> 
> make check RUNTESTFLAGS="--target_board='mips-sim-mti32/-
> fplugin=/home/sellcey/plugin/dynopt.so'"

Using a brace expansion may help here though I haven't checked. Forward slashes 
are for the first set of run variants and braces are for the second set. Given 
the separator for brace expansion is , then the forwards slashes would 
hopefully not matter. It's a bit of a guess though:

make check 
RUNTESTFLAGS="--target_board='mips-sim-mti32\{-fplugin=/home/sellcey/plugin/dynopt.so\}'"

Matthew

> 
> But the slashes in the plugin path are messing things up (I tried putting 1, 
> 2,
> or 3 backslashes in front of the forward slashes in the path but that did not
> help and I tried putting /home/sellcey/plugin/dynopt.so in single quotes,
> that did not help either.
> 
> Steve Ellcey
> sell...@imgtec.com

RE: Testing a plugin optimization with 'make check' (slashes in options)

[Steve Ellcey]

On Wed, 2013-05-01 at 13:53 -0700, Matthew Fortune wrote:
> 
> Using a brace expansion may help here though I haven't checked. Forward 
> slashes are for the first
> set of run variants and braces are for the second set. Given the separator 
> for brace expansion is ,
> then the forwards slashes would hopefully not matter. It's a bit of a guess 
> though:
> 
> make check 
> RUNTESTFLAGS="--target_board='mips-sim-mti32\{-fplugin=/home/sellcey/plugin/dynopt.so\}'"
> 
> Matthew


I hadn't tried that, but unfortunately it doesn't seem to help.

Running target mips-sim-mti32/-fplugin=/home/sellcey/plugin/dynopt.so
Using /usr/share/dejagnu/baseboards/mips-sim-mti32.exp as board description 
file for target.
Using /usr/share/dejagnu/config/sim.exp as generic interface file for target.
Using /usr/share/dejagnu/baseboards/basic-sim.exp as board description file for 
target.
ERROR: tcl error sourcing board description file for target 
/usr/share/dejagnu/baseboards/mips-sim-mti32.exp.
.
xgcc: error: missing argument to '-fplugin='
xgcc: error: unrecognized command line option '-mhome'
xgcc: error: unrecognized command line option '-msellcey'
xgcc: error: unrecognized command line option '-mplugin'
xgcc: error: unrecognized command line option '-mdynopt.so'

Steve Ellcey
sell...@imgtec.com

Optimization pass for coremark switch statement

[Steve Ellcey]

I have created a dynamically loadable optimization pass for optimizing
the switch statement in the core_state_transition function of the
coremark benchmark.  This pass is not fully tested (I haven't run
anything other then coremark with it) and it has no controls for
limiting how much code it copies when doing the optimization but I do
get an impressive speed up on coremark on the MIPS chips I ran it on and
I thought I would send it out to see if there were any comments on it or
suggestions for improvements (hopefully something more useful then
telling me to add some controls for limiting the code copying).

My main concern is that I am using gimple_duplicate_sese_region to
copy blocks and the comments for this routine say it should only
be used on single-entry, single-exit regions.  I use it on individual
blocks and while every block is (by definition) single entry, they are
not necessarily single exit.  If anyone knows what needs to be done to
gimple_duplicate_sese_region to make it safe for multiple-exit blocks,
I would love to hear it.  In the meantime coremark does seem to 
compile correctly and its self check passes when I compile with this
optimization pass using gimple_duplicate_sese_region as is.

Comments?

Steve Ellcey
sell...@imgtec.com

/* Alias analysis for GNU C
   Copyright (C) 2013 Free Software Foundation, Inc.
   Contributed by Steve Ellcey (sell...@imgtec.com).

This file is part of GCC.

GCC is free software; you can redistribute it and/or modify it under
the terms of the GNU General Public License as published by the Free
Software Foundation; either version 3, or (at your option) any later
version.

GCC is distributed in the hope that it will be useful, but WITHOUT ANY
WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
for more details.

You should have received a copy of the GNU General Public License
along with GCC; see the file COPYING3.  If not see
.  */


/* This file implements an optimization where, when a variable is set
   to a constant value and there is a path that leads from this definition
   to a switch statement that uses the variable as its controlling expression
   we duplicate the blocks on this path and change the switch goto to a
   direct goto to the label of the switch block that control would goto based
   on the value of the variable.  */

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

int plugin_is_GPL_compatible;

/* Helper function for find_path, visited_bbs is used to make sure we don't
   fall into an infinite loop.  */

static int
find_path_1(basic_block start_bb, basic_block end_bb, struct pointer_set_t *visited_bbs)
{
  edge_iterator ei;
  edge e;

  if (start_bb == end_bb) return 1;

  if (!pointer_set_insert (visited_bbs, start_bb))
{
  FOR_EACH_EDGE (e, ei, start_bb->succs)
	if (find_path_1 (e->dest, end_bb, visited_bbs)) return 1;
}
return 0;
}

/* Return 1 if there is a path from start_bb to end_bb and 0 if there
   is not.  There may be multiple paths from start_bb to end_bb.  */

static int
find_path(basic_block start_bb, basic_block end_bb)
{
  edge_iterator ei;
  edge e;
  struct pointer_set_t *visited_bbs;
  int p = 0;

  if (start_bb == end_bb) return 1;

  visited_bbs = pointer_set_create ();
  if (!pointer_set_insert (visited_bbs, start_bb))
{
  FOR_EACH_EDGE (e, ei, start_bb->succs)
	if (find_path_1 (e->dest, end_bb, visited_bbs))
	  {
	p = 1;
	break;
	  }
}
  pointer_set_destroy (visited_bbs);
  return p;
}


/* We save the paths we want to copy in bbs_list_array.  n_bbs_list is the
   number of paths saved, bbs_list_array[i] is the list of basic blocks in
   one path.  Each path starts with the block where a variable is assigned
   a constant value (bbs_list_array[i][0]) and ends with the switch statement
   block (bbs_list_array[i][bbs_list_size[i]-2]) and then the block that the
   switch statement is going to go to given the constant value of the
   variable (bbs_list_array[i][bbs_list_size[i]-1]).  */

static basic_block *bbs_list_array[40];
static int val_array[40];
static int bbs_list_size[40];
static int n_bbs_list = 0;

/* bbs_list[0] is the block with the switch statement,
   bbs_list[n-1] is the block where the switch statement variable is assigned
 a constant value,
   The entries in between make a (reverse) path between the two.

   We don't want to change bb_list, we want to leave that alone and
   and copy the path to bbs_list_array so that we wind up with a list (array)
   of paths that we want to update.  We also want to add the block that the
   switch is going to go to on to the list so that we know which exit from the
   switch statement is important when calling gimple_duplicate_sese_region.  */

static void
save_new_path (basic_block *bbs_list, int n, tree val)
{
  int i;
  edge switch_taken_edge;

  if (n <= 1) return;