from:"Iyer, Balaji V"

RE: question about gtype-desc.c

2014-02-04 Thread Iyer, Balaji V



> -Original Message-
> From: Jakub Jelinek [mailto:ja...@redhat.com]
> Sent: Tuesday, February 4, 2014 5:36 PM
> To: Iyer, Balaji V
> Cc: gcc@gcc.gnu.org
> Subject: Re: question about gtype-desc.c
> 
> On Tue, Feb 04, 2014 at 10:26:20PM +, Iyer, Balaji V wrote:
> > > > gtype-desc.c:8176: error: âstruct gimple_omp_for_iterâ has no
> > > > member named âloop_countâ
> > > > gtype-desc.c:8178: error: âstruct gimple_omp_for_iterâ has no
> > > > member named âgrainâ
> > > >
> > > > These files are in the build directory. I deleted everything and
> > > > reconfigured
> > > but the error reappears.
> > >
> > > You mean you've started a new build directory, or just removed *.o
> > > or something similar?  I'd suggest to rm s-gtype gtype-desc.c and make s-
> gtype.
> >
> > I did the following
> >
> > cd build_dir
> > rm -rf *
> > ../gcc/configure --prefix=$PWD/../install --enable-languages="c,c++"
> > make
> >
> > Should I do make s-gtype before I do "make" above?
> 
> What you did should be more than enough.  But then, I didn't see
> loop_count nor grain fields of gimple_omp_for_iter in your previously
> posted patches (only your ChangeLog mentioned it).  So, if you start with
> wiping up the build directory, I think you have to grep where the fields
> appear.
> 

OK. Found the issue. I had the 2 fields enclosed inside a #if 0 and #endif

I guess whatever that is reading the fields to create gtype-desc.c does not 
understand C/C++ pre-processing, and thus it didn't ignore the fields in 
between #if 0.

Thanks,

Balaji V. Iyer.

RE: question about gtype-desc.c

2014-02-04 Thread Iyer, Balaji V



> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Jakub Jelinek
> Sent: Tuesday, February 4, 2014 5:23 PM
> To: Iyer, Balaji V
> Cc: gcc@gcc.gnu.org
> Subject: Re: question about gtype-desc.c
> 
> On Tue, Feb 04, 2014 at 10:12:13PM +, Iyer, Balaji V wrote:
> > Hello Jakub,
> > I think I have found a fix to _Cilk_for to be structured the way you
> requested. I am currently trying to clean up my code so that I can send you a
> patch.
> >
> > Now, I am trying to remove the 2 fields I put in gimple_omp_for_iter:
> loop_count and grain. But, it is giving the following errors when I remove it.
> >
> > Do you know what is causing it and how I can fix it?
> >
> > gtype-desc.c: In function âvoid
> gt_ggc_mx_gimple_statement_base(void*)â:
> > gtype-desc.c:1721: error: âstruct gimple_omp_for_iterâ has no member
> > named âloop_countâ
> > gtype-desc.c:1721: error: âstruct gimple_omp_for_iterâ has no member
> > named âloop_countâ
> > gtype-desc.c:1722: error: âstruct gimple_omp_for_iterâ has no member
> > named âgrainâ
> > gtype-desc.c:1722: error: âstruct gimple_omp_for_iterâ has no member
> > named âgrainâ
> > gtype-desc.c: In function âvoid
> gt_pch_nx_gimple_statement_base(void*)â:
> > gtype-desc.c:4854: error: âstruct gimple_omp_for_iterâ has no member
> > named âloop_countâ
> > gtype-desc.c:4854: error: âstruct gimple_omp_for_iterâ has no member
> > named âloop_countâ
> > gtype-desc.c:4855: error: âstruct gimple_omp_for_iterâ has no member
> > named âgrainâ
> > gtype-desc.c:4855: error: âstruct gimple_omp_for_iterâ has no member
> > named âgrainâ
> > gtype-desc.c: In function âvoid
> gt_pch_p_21gimple_statement_base(void*, void*, void (*)(void*, void*),
> void*)â:
> > gtype-desc.c:8176: error: âstruct gimple_omp_for_iterâ has no member
> > named âloop_countâ
> > gtype-desc.c:8178: error: âstruct gimple_omp_for_iterâ has no member
> > named âgrainâ
> >
> > These files are in the build directory. I deleted everything and 
> > reconfigured
> but the error reappears.
> 
> You mean you've started a new build directory, or just removed *.o or
> something similar?  I'd suggest to rm s-gtype gtype-desc.c and make s-gtype.

I did the following

cd build_dir
rm -rf *
../gcc/configure --prefix=$PWD/../install --enable-languages="c,c++" 
make

Should I do make s-gtype before I do "make" above?



> 
>   Jakub

question about gtype-desc.c

2014-02-04 Thread Iyer, Balaji V

Hello Jakub,
I think I have found a fix to _Cilk_for to be structured the way you 
requested. I am currently trying to clean up my code so that I can send you a 
patch.

Now, I am trying to remove the 2 fields I put in gimple_omp_for_iter: 
loop_count and grain. But, it is giving the following errors when I remove it.

Do you know what is causing it and how I can fix it?

gtype-desc.c: In function âvoid gt_ggc_mx_gimple_statement_base(void*)â:
gtype-desc.c:1721: error: âstruct gimple_omp_for_iterâ has no member named 
âloop_countâ
gtype-desc.c:1721: error: âstruct gimple_omp_for_iterâ has no member named 
âloop_countâ
gtype-desc.c:1722: error: âstruct gimple_omp_for_iterâ has no member named 
âgrainâ
gtype-desc.c:1722: error: âstruct gimple_omp_for_iterâ has no member named 
âgrainâ
gtype-desc.c: In function âvoid gt_pch_nx_gimple_statement_base(void*)â:
gtype-desc.c:4854: error: âstruct gimple_omp_for_iterâ has no member named 
âloop_countâ
gtype-desc.c:4854: error: âstruct gimple_omp_for_iterâ has no member named 
âloop_countâ
gtype-desc.c:4855: error: âstruct gimple_omp_for_iterâ has no member named 
âgrainâ
gtype-desc.c:4855: error: âstruct gimple_omp_for_iterâ has no member named 
âgrainâ
gtype-desc.c: In function âvoid gt_pch_p_21gimple_statement_base(void*, void*, 
void (*)(void*, void*), void*)â:
gtype-desc.c:8176: error: âstruct gimple_omp_for_iterâ has no member named 
âloop_countâ
gtype-desc.c:8178: error: âstruct gimple_omp_for_iterâ has no member named 
âgrainâ

These files are in the build directory. I deleted everything and reconfigured 
but the error reappears.

Thanks,

Balaji V. Iyer.

RE: g++.dg/cilk-plus/CK/catch_exc.cc -O1 times out

2014-02-02 Thread Iyer, Balaji V

Hi Paolo,
We are looking into this issue. Will let you know as soon as we find a 
fix.

Thanks,

Balaji V. Iyer.

> -Original Message-
> From: Paolo Carlini [mailto:paolo.carl...@oracle.com]
> Sent: Sunday, February 2, 2014 11:04 AM
> To: g...@gnu.org
> Cc: Iyer, Balaji V; Jakub Jelinek
> Subject: g++.dg/cilk-plus/CK/catch_exc.cc -O1 times out
> 
> Hi,
> 
> today I'm seeing this testcase using a lot of cpu and eventually timing out. 
> Is it
> known?
> 
> Thanks,
> Paolo.

RE: Enable debug info

2014-01-29 Thread Iyer, Balaji V



> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Umesh Kalappa
> Sent: Wednesday, January 29, 2014 4:36 AM
> To: gcc@gcc.gnu.org
> Subject: Enable debug info
> 
> Dear All,
> 
> We need to support  the debug info emit for our private port on gcc 4.8.1.
> 
> I was in impression using option -g in the commandline by defualt ,will emit
> the dwarf debugging symbols and the info ,But i was wrong here.
> 
> Anyone in the group point me some references or through some lights on
> how do i enable debug options  in the compiler.

What version of GDB are you using? If you are not using the latest one, the 
DWARF's version might mismatch. Try to add -g and -gdwarf-2 

> 
> Appreciate your comments and Thank you
> ~Umesh

RE: Question about omp-low.c

2013-12-19 Thread Iyer, Balaji V



> -Original Message-
> From: Jakub Jelinek [mailto:ja...@redhat.com]
> Sent: Thursday, December 19, 2013 2:40 AM
> To: Iyer, Balaji V
> Cc: Jason Merrill (ja...@redhat.com); 'gcc@gcc.gnu.org'
> Subject: Re: Question about omp-low.c
> 
> On Thu, Dec 19, 2013 at 05:14:16AM +, Iyer, Balaji V wrote:
> > I looked into this, but the issue I have is, for the following code:
> >
> > Int main (void) {
> > _Cilk_for (int ii = W; ii < (X+Y); ii = ii + (q+z))
> 
> This doesn't have a body, Int won't compile either.  Can you post -fdump-
> tree-{original,gimple,omplower,ompexp} dump for some short simple
> testcase just to see what design decisions you've made so far?  Perhaps
> something should be reconsidered...

Yes I didn't put a body because it wasn't relevant for what I was talking 
about. I wanted to talk about parameters of the _Cilk_for. The body should be 
pushed into the child function and that is straight forward.

Int is int after Outlook decided to capitalize it :-) and I forgot to undo it 
:-(


> 
>   Jakub

RE: Question about omp-low.c

2013-12-18 Thread Iyer, Balaji V

> -Original Message-
> From: Jakub Jelinek [mailto:ja...@redhat.com]
> Sent: Wednesday, December 18, 2013 11:28 AM
> To: Iyer, Balaji V
> Cc: Jason Merrill (ja...@redhat.com); 'gcc@gcc.gnu.org'
> Subject: Re: Question about omp-low.c
> 
> On Wed, Dec 18, 2013 at 04:16:57PM +, Iyer, Balaji V wrote:
> > > Don't do this, compute loop count during omp expansion (there is
> > > already code that does that for you, after all, for #pragma omp for
> > > the loop count is typically (unless static schedule) passed as parameter 
> > > to
> the runtime as well.
> >
> > Where does this happen? Is there a routine that you can point me to that
> will compute the loop-count?
> 
> E.g. extract_omp_for_data (that does that only for collapse>1 though),
> otherwise you get from that routine just n1, n2, step and cond_code and
> from that you can easily compute it as extract_omp_for_data does:
>   tree itype = TREE_TYPE (loop->v);
> 
>   if (POINTER_TYPE_P (itype))
> itype = signed_type_for (itype);
>   t = build_int_cst (itype, (loop->cond_code == LT_EXPR ? -1 : 
> 1));
>   t = fold_build2_loc (loc,
>PLUS_EXPR, itype,
>fold_convert_loc (loc, itype, loop->step), t);
>   t = fold_build2_loc (loc, PLUS_EXPR, itype, t,
>fold_convert_loc (loc, itype, loop->n2));
>   t = fold_build2_loc (loc, MINUS_EXPR, itype, t,
>fold_convert_loc (loc, itype, loop->n1));
>   if (TYPE_UNSIGNED (itype) && loop->cond_code == GT_EXPR)
> t = fold_build2_loc (loc, TRUNC_DIV_EXPR, itype,
>  fold_build1_loc (loc, NEGATE_EXPR, itype, t),
>  fold_build1_loc (loc, NEGATE_EXPR, itype,
>   fold_convert_loc (loc, itype,
> loop->step)));
>   else
> t = fold_build2_loc (loc, TRUNC_DIV_EXPR, itype, t,
>  fold_convert_loc (loc, itype, loop->step));
> 

Hi Jakub,
I looked into this, but the issue I have is, for the following code:

Int main (void) {
_Cilk_for (int ii = W; ii < (X+Y); ii = ii + (q+z))
}

It will gimplify X+Y and q+z and put it in a new variable that is stored in 
pre_body and replace the above code like this:

Int main (void {
_Cilk_for (int ii = W; ii < D1234 ; ii =  ii + D1235)
}

The pre_body will have something like this:

D1234 = X + Y;
D1235 = q + z;

Finally, I need to replace the _Cilk_for with something  like this in the main 
function:

Int main (void)
{
__cilkrts_cilk_for_64 (main.cilk_for_fn.0, &cilk_for_data, 
, grain);
}

During the expand_omp_for stage (or at any stage after gimplification), if I 
calculate the loop count, I should get something like this:

Loop_count = (D1234 - W) / D1235

Now, the pre_body is pushed into the child function and thus the values 
calculated for D1234 and D1235 will be in the child function and not in main 
which will result in getting the wrong loop count.  This is why I need to have 
a loop count field to calculate and then store this value from the 
pre-gimplification phase.

Now, if I can somehow make it push the pre-body into the main function and not 
in the child function, I won't have this issue anymore. Can you please suggest 
me where the pre-body is being pushed into the child function and/or how I 
could stop it? I tried to warlk through the code by putting a break point in 
gimple_omp_for_pre_body_ptr and I am still not finding this...

In most OMP code I have seen, the loop count is inserted/used in the child 
function and thus this is not an issue.

Thanks,

Balaji V. Iyer.

>   Jakub

RE: Question about omp-low.c

2013-12-18 Thread Iyer, Balaji V

> Don't do this, compute loop count during omp expansion (there is already
> code that does that for you, after all, for #pragma omp for the loop count is
> typically (unless static schedule) passed as parameter to the runtime as well.

Where does this happen? Is there a routine that you can point me to that will 
compute the loop-count?

Thanks,

Balaji V. Iyer.

RE: Question about omp-low.c

2013-12-18 Thread Iyer, Balaji V



> -Original Message-
> From: Jakub Jelinek [mailto:ja...@redhat.com]
> Sent: Wednesday, December 18, 2013 1:58 AM
> To: Iyer, Balaji V
> Cc: Jason Merrill (ja...@redhat.com); 'gcc@gcc.gnu.org'
> Subject: Re: Question about omp-low.c
> 
> On Wed, Dec 18, 2013 at 04:46:40AM +, Iyer, Balaji V wrote:
> > I have a question regarding the parallel for implementation. I am
> implementing _Cilk_for based on the routines in omp-low.c and I would like
> to create a child function but would like to move the items that
> gimplify_omp_for inserts in for_pre_body in the top-level function. I need to
> do this because in _Cilk_for, we insert the body of the function into a child
> function and then we call a builtin CilkPlus function called
> __cilkrts_cilk_for_64 and pass in the child function's name, data pointer,
> loop-count and grain.
> >
> > The loop count computation gets to be an issue in C++ when we use
> iterator.
> >
> > For example, if we have something like this:
> > Vector  array;
> > For (vector::iterator iter =  array.begin(); iter != array.end
> > (); iter++)
> 
> OpenMP also supports C++ iterators, so I don't see why you don't follow
> that.
> The iterators are lowered already by the C++ FE, what the middle-end sees is
> an integral iterator.  Just look at one of the several
> libgomp/testsuite/libgomp.c++/for-* testcases.
> 

I think we are talking two different things or I am not understanding you. I am 
using OMP's iterator handling mechanism, but the question I have is about the 
pre-body. It is pre-gimplifying the condition and the initial value and storing 
it in pre_body. The prebody is then pushed into the child function. I want the 
pre-body to be pushed into main function. Is it possible for me to do that?


> By following what we do for OpenMP here, I'd hope you can get rid of the
> loop_count you've added to the gimple structure, what is grain, is that
> specific to each of the collapsed trees, or does Cilk+ support only 
> collapse(1),
> and if so or if it is global for the _Cilk_for and not for each iterator, 
> just add a
> clause for it instead.
> 
Grain is a value that user specifies that is passed directly to the runtime 
that tells it how to divide the work (different from step-size, please see 
cilk_for_grain.c in my patch). It is very Cilk runtime specific. Loop-count I 
need it because I need it to pass into the cilk runtime function call (along 
with grain) to tell the loop count. I calculate this value way ahead before the 
gimplification of the condition, intial value and the step-size. Now, if I can 
some-how find a way to make GCC move the pre-body to the parent function 
instead of the child function, I can try to eliminate this field from the 
structure.

>   Jakub

Question about omp-low.c

2013-12-17 Thread Iyer, Balaji V

Hello Jakub et al.,
I have a question regarding the parallel for implementation. I am 
implementing _Cilk_for based on the routines in omp-low.c and I would like to 
create a child function but would like to move the items that gimplify_omp_for 
inserts in for_pre_body in the top-level function. I need to do this because in 
_Cilk_for, we insert the body of the function into a child function and then we 
call a builtin CilkPlus function called __cilkrts_cilk_for_64 and pass in the 
child function's name, data pointer,  loop-count and grain.

The loop count computation gets to be an issue in C++ when we use 
iterator.

For example, if we have something like this:
Vector  array;
For (vector::iterator iter =  array.begin(); iter != array.end (); iter++)

gimplify_omp_for function gimplifys the condition expression (array.end ()) and 
then inserts the following in pre_body

 iter = std::vector::begin (&array);
D.28387 = std::vector::end (&array);
try
  {
retval.0 = __gnu_cxx::operator- > (&D.28387, &iter);
  }
finally
  {
D.28387 = {CLOBBER};
  }

..and moves it to the child function at a later stage (I believe in 
lower_omp_for). I want to make it *NOT* do that and keep it in the current 
function, since I want to use the retval.0. Can someone please suggest me how 
to do that?

Any help is greatly appreciated!

Sincerely,

Balaji V. Iyer.

RE: Question about overloaded operators

2013-11-10 Thread Iyer, Balaji V



> -Original Message-
> From: Jason Merrill [mailto:ja...@redhat.com]
> Sent: Sunday, November 10, 2013 1:55 PM
> To: Iyer, Balaji V; gcc@gcc.gnu.org
> Subject: Re: Question about overloaded operators
> 
> On 11/10/2013 11:08 AM, Iyer, Balaji V wrote:
> > In C++, when a binary/unary operator is overloaded, then the
> build_x_[binary/unary]_op replaces it with a call expression. Is there  a way
> to know from the call expression (assume we are in the gimplification stage)
> what the operator is? I tried to look around but I didn't find any obvious way
> to figure this info out.
> 
> Not a simple one.  You might factor out the code for that in
> write_unqualified_id into a separate function.
> 

Semi crazy thought...If I do something like a string compare for the operation 
after operator toward the end of the function, will I get what I want? I guess 
another way to ask this is, will a '+' operation, for example, be mapped to a 
function ending in something other than "operator+"

> Jason

Question about overloaded operators

2013-11-10 Thread Iyer, Balaji V

Hello Everyone,
In C++, when a binary/unary operator is overloaded, then the 
build_x_[binary/unary]_op replaces it with a call expression. Is there  a way 
to know from the call expression (assume we are in the gimplification stage) 
what the operator is? I tried to look around but I didn't find any obvious way 
to figure this info out.

Thanks,

Balaji V. Iyer.

RE: Bootstrap issues in libsanitizer

2013-11-06 Thread Iyer, Balaji V



> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: Wednesday, November 6, 2013 5:55 AM
> To: Gopalasubramanian, Ganesh
> Cc: Iyer, Balaji V; gcc@gcc.gnu.org; konstantin.s.serebry...@gmail.com;
> Jonathan Wakely
> Subject: Re: Bootstrap issues in libsanitizer
> 
> On Wed, Nov 6, 2013 at 11:50 AM, Gopalasubramanian, Ganesh
>  wrote:
> >> Are you including linux/vt.h yourself?  If you get it via a glibc header 
> >> then
> it's a SUSE issue, yes.  Can you specify the SUSE version you are looking at?
> Even for 12.1 I see 'newev' here though SLE11 seems to have 'new'.
> >
> > I get the error with
> >
> > SUSE Linux Enterprise Server 11 (x86_64) VERSION = 11 PATCHLEVEL = 1

Hi Ganesh, That's exactly the version I have. One quick workaround I have done 
to get around this issue (yes I know it is pretty wierd one, but still works) 
is the following


#ifndef __cplusplus
#define new_SOMETHING_ELSE new
#endif
struct vt_event {
unsigned int event;
#define VT_EVENT_SWITCH 0x0001  /* Console switch */
#define VT_EVENT_BLANK  0x0002  /* Screen blank */
#define VT_EVENT_UNBLANK0x0004  /* Screen unblank */
#define VT_EVENT_RESIZE 0x0008  /* Resize display */
#define VT_MAX_EVENT0x000F
unsigned int old;   /* Old console */
unsigned int new_SOMETHING_ELSE;/* New console (if changing) */
unsigned int pad[4];/* Padding for expansion */
};
--
> 
> I've filed a bugreport internally.  And yes, sys/vt.h just includes linux/vt.h
> here.
> 

Thanks Richard!

-Balaji V. Iyer.


> Richard.
> 
> > Regards
> > Ganesh
> >
> > -Original Message-
> > From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf
> > Of Richard Biener
> > Sent: Wednesday, November 06, 2013 4:16 PM
> > To: Jonathan Wakely
> > Cc: Iyer, Balaji V; gcc@gcc.gnu.org; konstantin.s.serebry...@gmail.com
> > Subject: Re: Bootstrap issues in libsanitizer
> >
> > On Tue, Nov 5, 2013 at 4:41 PM, Jonathan Wakely
>  wrote:
> >> On 5 November 2013 15:38, Jonathan Wakely wrote:
> >>> On 5 November 2013 15:32, Jonathan Wakely wrote:
> >>>> On 5 November 2013 15:27, Iyer, Balaji V wrote:
> >>>>> In file included from /usr/include/sys/vt.h:1:0,
> >>>>>  from ../../../../trunk-
> gcc/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:49:
> >>>>> /usr/include/linux/vt.h:74:15: error: expected unqualified-id before
> ânewâ
> >>>>>   unsigned int new;  /* New console (if changing) */
> >>>>>^
> >>>>
> >>>> 'new' is a keyword in C++, so your linux/vt.h header is not usable in C++
> files.
> >>>>
> >>>> This is not a problem in libsanitizer.  Have you recently updated a
> >>>> kernel-headers package on your machine?
> >>>
> >>> With kernel 3.11.6 I see that field is called newev, so it looks as
> >>> though newer kernels fix the problem.
> >>
> >> http://lkml.indiana.edu/hypermail/linux/kernel/0911.2/01720.html
> >> implies the "new" field never made it into an actual release, so it
> >> might be a problem for SuSE kernels only.
> >
> > Are you including linux/vt.h yourself?  If you get it via a glibc header 
> > then
> it's a SUSE issue, yes.  Can you specify the SUSE version you are looking at?
> Even for 12.1 I see 'newev' here though SLE11 seems to have 'new'.
> >
> > Richard.
> >
> >

Bootstrap issues in libsanitizer

2013-11-05 Thread Iyer, Balaji V

Hello Everyone,
I am getting this weird bootstrap error in my SUSE machine with 
libsanitizer that didn't occur ~1.5 days ago. Is anyone else seeing this?

libtool: compile:  /export/users/gcc-svn/b-trunk-gcc/./gcc/xgcc -shared-libgcc 
-B/export/users/gcc-svn/b-trunk-gcc/./gcc -nostdinc++ 
-L/export/users/gcc-svn/b-trunk-gcc/x86_64-unknown-linux-gnu/libstdc++-v3/src 
-L/export/users/gcc-svn/b-trunk-gcc/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
 
-L/export/users/gcc-svn/b-trunk-gcc/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
 
-B/export/users/gcc-svn/install_dir/trunk-install/x86_64-unknown-linux-gnu/bin/ 
-B/export/users/gcc-svn/install_dir/trunk-install/x86_64-unknown-linux-gnu/lib/ 
-isystem 
/export/users/gcc-svn/install_dir/trunk-install/x86_64-unknown-linux-gnu/include
 -isystem 
/export/users/gcc-svn/install_dir/trunk-install/x86_64-unknown-linux-gnu/sys-include
 -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS 
-D__STDC_LIMIT_MACROS -I. -I../../../../trunk-gcc/libsanitizer/sanitizer_common 
-I ../../../../trunk-gcc/libsanitizer/include -Wall -W -Wno-unused-parameter 
-Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions 
-fomit-frame-pointer -funwind-tables -fvisibility=hidden -Wno-variadic-macros 
-I../../libstdc++-v3/include 
-I../../libstdc++-v3/include/x86_64-unknown-linux-gnu 
-I../../../../trunk-gcc/libsanitizer/../libstdc++-v3/libsupc++ -g -O2 
-D_GNU_SOURCE -MT sanitizer_platform_limits_posix.lo -MD -MP -MF 
.deps/sanitizer_platform_limits_posix.Tpo -c 
../../../../trunk-gcc/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc
  -fPIC -DPIC -o .libs/sanitizer_platform_limits_posix.o
In file included from /usr/include/sys/vt.h:1:0,
 from 
../../../../trunk-gcc/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:49:
/usr/include/linux/vt.h:74:15: error: expected unqualified-id before ânewâ
  unsigned int new;  /* New console (if changing) */
   ^

configured with: ../trunk-gcc/configure 
--prefix=/export/users/gcc-svn/install_dir/trunk-install

Thanks,

Balaji V. Iyer.

RE: [PATCH] RE: libcilkrts breaks non-bootstrap build

2013-11-05 Thread Iyer, Balaji V



> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: Tuesday, November 5, 2013 7:08 AM
> To: Iyer, Balaji V
> Cc: Tom de Vries; gcc@gcc.gnu.org
> Subject: Re: [PATCH] RE: libcilkrts breaks non-bootstrap build
> 
> On Tue, Nov 5, 2013 at 5:17 AM, Iyer, Balaji V 
> wrote:
> >
> >
> >> -Original Message-
> >> From: Tom de Vries [mailto:tom_devr...@mentor.com]
> >> Sent: Monday, November 4, 2013 2:15 PM
> >> To: gcc@gcc.gnu.org
> >> Cc: Iyer, Balaji V
> >> Subject: libcilkrts breaks non-bootstrap build
> >>
> >> Hi,
> >>
> >> When configuring a gcc build with "--disable-bootstrap --enable-
> >> languages=c" I run into this error:
> >> ...
> >> libtool: compile:  g++
> >> -B/home/vries/gcc_versions/devel/lean-c/install/x86_64-unknown-linux-
> >> gnu/bin/
> >> -B/home/vries/gcc_versions/devel/lean-c/install/x86_64-unknown-linux-
> >> gnu/lib/
> >> -isystem
> >> /home/vries/gcc_versions/devel/lean-c/install/x86_64-unknown-linux-
> >> gnu/include
> >> -isystem
> >> /home/vries/gcc_versions/devel/lean-c/install/x86_64-unknown-linux-
> >> gnu/sys-include
> >> "-DPACKAGE_NAME=\"Cilk Runtime Library\""
> >> -DPACKAGE_TARNAME=\"cilk-runtime-library\" -
> DPACKAGE_VERSION=\"2.0\"
> >> "-DPACKAGE_STRING=\"Cilk Runtime Library 2.0\""
> >> -DPACKAGE_BUGREPORT=\"c...@intel.com\" -DPACKAGE_URL=\"\"
> >> -DPACKAGE=\"cilk-runtime-library\" -DVERSION=\"2.0\" -
> DSTDC_HEADERS=1
> >> -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -
> >> DHAVE_STRING_H=1
> >> -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -
> >> DHAVE_STDINT_H=1
> >> -DHAVE_UNISTD_H=1 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -
> >> DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -I. -
> >> I/home/vries/gcc_versions/devel/src/libcilkrts
> >> -I/home/vries/gcc_versions/devel/src/libcilkrts/include
> >> -I/home/vries/gcc_versions/devel/src/libcilkrts/runtime
> >> -I/home/vries/gcc_versions/devel/src/libcilkrts/runtime/config/x86
> >> -DIN_CILK_RUNTIME=1 -D_Cilk_spawn= -D_Cilk_sync= -D_Cilk_for=for -
> >> fcilkplus -g3
> >> -O0 -dH -D_GNU_SOURCE -MT bug.lo -MD -MP -MF .deps/bug.Tpo -c
> >> /home/vries/gcc_versions/devel/src/libcilkrts/runtime/bug.cpp  -fPIC
> >> -DPIC - o .libs/bug.o
> >> g++: error: unrecognized command line option '-fcilkplus'
> >> make[2]: *** [bug.lo] Error 1
> >> make[2]: Leaving directory
> >> `/home/vries/gcc_versions/devel/lean-c/build/x86_64-unknown-linux-
> >> gnu/libcilkrts'
> >> ...
> >>
> >> The error occurs because the compiler doesn't support -fcilkplus.
> >>
> >> Should configure disable libcilkplus when c++ is not enabled?
> >>
> >
> > Is the following patch OK to fix this issue?
> 
> Ok.
> 
> Thanks,
> Richard.
> 

Committed as revision 204396.

Thanks,

Balaji V. Iyer.



> > Thanks,
> >
> > Balaji V. Iyer.
> >
> > Index: configure.ac
> >
> ==
> =
> > --- configure.ac(revision 204381)
> > +++ configure.ac(working copy)
> > @@ -2061,7 +2061,7 @@
> >  case ,${enable_languages}, in
> >*,c++,*) ;;
> >*)
> > -noconfigdirs="$noconfigdirs target-libitm target-libsanitizer target-
> libvtv"
> > +noconfigdirs="$noconfigdirs target-libcilkrts target-libitm target-
> libsanitizer target-libvtv"
> >  ;;
> >  esac
> >
> > Index: ChangeLog
> >
> ==
> =
> > --- ChangeLog   (revision 204381)
> > +++ ChangeLog   (working copy)
> > @@ -1,3 +1,9 @@
> > +2013-11-04  Balaji V. Iyer  
> > +
> > +   * configure.ac: Added libcilkrts to noconfig list when C++ is not
> > +   supported.
> > +   * configure: Regenerated.
> > +
> >  2013-11-01  Trevor Saunders  
> >
> >  * MAINTAINERS (Write After Approval): Add myself.
> > Index: configure
> >
> ==
> =
> > --- configure   (revision 204381)
> > +++ configure   (working copy)
> > @@ -6630,7 +6630,7 @@
> >  case ,${enable_languages}, in
> >*,c++,*) ;;
> >*)
> > -noconfigdirs="$noconfigdirs target-libitm target-libsanitizer target-
> libvtv"
> > +noconfigdirs="$noconfigdirs target-libcilkrts target-libitm target-
> libsanitizer target-libvtv"
> >  ;;
> >  esac
> >

[PATCH] RE: libcilkrts breaks non-bootstrap build

2013-11-04 Thread Iyer, Balaji V



> -Original Message-
> From: Tom de Vries [mailto:tom_devr...@mentor.com]
> Sent: Monday, November 4, 2013 2:15 PM
> To: gcc@gcc.gnu.org
> Cc: Iyer, Balaji V
> Subject: libcilkrts breaks non-bootstrap build
> 
> Hi,
> 
> When configuring a gcc build with "--disable-bootstrap --enable-
> languages=c" I run into this error:
> ...
> libtool: compile:  g++
> -B/home/vries/gcc_versions/devel/lean-c/install/x86_64-unknown-linux-
> gnu/bin/
> -B/home/vries/gcc_versions/devel/lean-c/install/x86_64-unknown-linux-
> gnu/lib/
> -isystem
> /home/vries/gcc_versions/devel/lean-c/install/x86_64-unknown-linux-
> gnu/include
> -isystem
> /home/vries/gcc_versions/devel/lean-c/install/x86_64-unknown-linux-
> gnu/sys-include
> "-DPACKAGE_NAME=\"Cilk Runtime Library\""
> -DPACKAGE_TARNAME=\"cilk-runtime-library\" -
> DPACKAGE_VERSION=\"2.0\"
> "-DPACKAGE_STRING=\"Cilk Runtime Library 2.0\""
> -DPACKAGE_BUGREPORT=\"c...@intel.com\" -DPACKAGE_URL=\"\"
> -DPACKAGE=\"cilk-runtime-library\" -DVERSION=\"2.0\" -DSTDC_HEADERS=1
> -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -
> DHAVE_STRING_H=1
> -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -
> DHAVE_STDINT_H=1
> -DHAVE_UNISTD_H=1 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -
> DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -I. -
> I/home/vries/gcc_versions/devel/src/libcilkrts
> -I/home/vries/gcc_versions/devel/src/libcilkrts/include
> -I/home/vries/gcc_versions/devel/src/libcilkrts/runtime
> -I/home/vries/gcc_versions/devel/src/libcilkrts/runtime/config/x86
> -DIN_CILK_RUNTIME=1 -D_Cilk_spawn= -D_Cilk_sync= -D_Cilk_for=for -
> fcilkplus -g3
> -O0 -dH -D_GNU_SOURCE -MT bug.lo -MD -MP -MF .deps/bug.Tpo -c
> /home/vries/gcc_versions/devel/src/libcilkrts/runtime/bug.cpp  -fPIC -DPIC -
> o .libs/bug.o
> g++: error: unrecognized command line option '-fcilkplus'
> make[2]: *** [bug.lo] Error 1
> make[2]: Leaving directory
> `/home/vries/gcc_versions/devel/lean-c/build/x86_64-unknown-linux-
> gnu/libcilkrts'
> ...
> 
> The error occurs because the compiler doesn't support -fcilkplus.
> 
> Should configure disable libcilkplus when c++ is not enabled?
> 

Is the following patch OK to fix this issue? 

Thanks,

Balaji V. Iyer.

Index: configure.ac
===
--- configure.ac(revision 204381)
+++ configure.ac(working copy)
@@ -2061,7 +2061,7 @@
 case ,${enable_languages}, in
   *,c++,*) ;;
   *)
-noconfigdirs="$noconfigdirs target-libitm target-libsanitizer 
target-libvtv"
+noconfigdirs="$noconfigdirs target-libcilkrts target-libitm 
target-libsanitizer target-libvtv"
 ;;
 esac

Index: ChangeLog
===
--- ChangeLog   (revision 204381)
+++ ChangeLog   (working copy)
@@ -1,3 +1,9 @@
+2013-11-04  Balaji V. Iyer  
+
+   * configure.ac: Added libcilkrts to noconfig list when C++ is not
+   supported.
+   * configure: Regenerated.
+
 2013-11-01  Trevor Saunders  

 * MAINTAINERS (Write After Approval): Add myself.
Index: configure
===
--- configure   (revision 204381)
+++ configure   (working copy)
@@ -6630,7 +6630,7 @@
 case ,${enable_languages}, in
   *,c++,*) ;;
   *)
-noconfigdirs="$noconfigdirs target-libitm target-libsanitizer 
target-libvtv"
+noconfigdirs="$noconfigdirs target-libcilkrts target-libitm 
target-libsanitizer target-libvtv"
 ;;
 esac

RE: libcilkrts breaks non-bootstrap build

2013-11-04 Thread Iyer, Balaji V

Hi Tom,
This is what I tried for --enable-languages=c,c++

../trunk-gcc/configure --disable-bootstrap --enable-languages="c,c++" 
--prefix=/home /install_dir/trunk-install-disable-bootstrap

And it seem to compile fine. Did you any other tags to configure?

Thanks,

Balaji V. Iyer.

> -Original Message-
> From: Tom de Vries [mailto:tom_devr...@mentor.com]
> Sent: Monday, November 4, 2013 2:15 PM
> To: gcc@gcc.gnu.org
> Cc: Iyer, Balaji V
> Subject: libcilkrts breaks non-bootstrap build
> 
> Hi,
> 
> When configuring a gcc build with "--disable-bootstrap --enable-
> languages=c" I run into this error:
> ...
> libtool: compile:  g++
> -B/home/vries/gcc_versions/devel/lean-c/install/x86_64-unknown-linux-
> gnu/bin/
> -B/home/vries/gcc_versions/devel/lean-c/install/x86_64-unknown-linux-
> gnu/lib/
> -isystem
> /home/vries/gcc_versions/devel/lean-c/install/x86_64-unknown-linux-
> gnu/include
> -isystem
> /home/vries/gcc_versions/devel/lean-c/install/x86_64-unknown-linux-
> gnu/sys-include
> "-DPACKAGE_NAME=\"Cilk Runtime Library\""
> -DPACKAGE_TARNAME=\"cilk-runtime-library\" -
> DPACKAGE_VERSION=\"2.0\"
> "-DPACKAGE_STRING=\"Cilk Runtime Library 2.0\""
> -DPACKAGE_BUGREPORT=\"c...@intel.com\" -DPACKAGE_URL=\"\"
> -DPACKAGE=\"cilk-runtime-library\" -DVERSION=\"2.0\" -DSTDC_HEADERS=1
> -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -
> DHAVE_STRING_H=1
> -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -
> DHAVE_STDINT_H=1
> -DHAVE_UNISTD_H=1 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -
> DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -I. -
> I/home/vries/gcc_versions/devel/src/libcilkrts
> -I/home/vries/gcc_versions/devel/src/libcilkrts/include
> -I/home/vries/gcc_versions/devel/src/libcilkrts/runtime
> -I/home/vries/gcc_versions/devel/src/libcilkrts/runtime/config/x86
> -DIN_CILK_RUNTIME=1 -D_Cilk_spawn= -D_Cilk_sync= -D_Cilk_for=for -
> fcilkplus -g3
> -O0 -dH -D_GNU_SOURCE -MT bug.lo -MD -MP -MF .deps/bug.Tpo -c
> /home/vries/gcc_versions/devel/src/libcilkrts/runtime/bug.cpp  -fPIC -DPIC -
> o .libs/bug.o
> g++: error: unrecognized command line option '-fcilkplus'
> make[2]: *** [bug.lo] Error 1
> make[2]: Leaving directory
> `/home/vries/gcc_versions/devel/lean-c/build/x86_64-unknown-linux-
> gnu/libcilkrts'
> ...
> 
> The error occurs because the compiler doesn't support -fcilkplus.
> 
> Should configure disable libcilkplus when c++ is not enabled?
> 
> I see the same error with "--disable-bootstrap --enable-languages=c,c++".
> Should configure test the compiler for support of -fcilkplus and disable
> libcilkplus if not?
> 
> Thanks,
> - Tom

RE: libcilkrts breaks non-bootstrap build

2013-11-04 Thread Iyer, Balaji V

Hi Tom,
Please see my response below:

Thanks,

Balaji V. Iyer.

> -Original Message-
> From: Tom de Vries [mailto:tom_devr...@mentor.com]
> Sent: Monday, November 4, 2013 2:15 PM
> To: gcc@gcc.gnu.org
> Cc: Iyer, Balaji V
> Subject: libcilkrts breaks non-bootstrap build
> 
> Hi,
> 
> When configuring a gcc build with "--disable-bootstrap --enable-
> languages=c" I run into this error:
> ...
> libtool: compile:  g++
> -B/home/vries/gcc_versions/devel/lean-c/install/x86_64-unknown-linux-
> gnu/bin/
> -B/home/vries/gcc_versions/devel/lean-c/install/x86_64-unknown-linux-
> gnu/lib/
> -isystem
> /home/vries/gcc_versions/devel/lean-c/install/x86_64-unknown-linux-
> gnu/include
> -isystem
> /home/vries/gcc_versions/devel/lean-c/install/x86_64-unknown-linux-
> gnu/sys-include
> "-DPACKAGE_NAME=\"Cilk Runtime Library\""
> -DPACKAGE_TARNAME=\"cilk-runtime-library\" -
> DPACKAGE_VERSION=\"2.0\"
> "-DPACKAGE_STRING=\"Cilk Runtime Library 2.0\""
> -DPACKAGE_BUGREPORT=\"c...@intel.com\" -DPACKAGE_URL=\"\"
> -DPACKAGE=\"cilk-runtime-library\" -DVERSION=\"2.0\" -DSTDC_HEADERS=1
> -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -
> DHAVE_STRING_H=1
> -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -
> DHAVE_STDINT_H=1
> -DHAVE_UNISTD_H=1 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -
> DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -I. -
> I/home/vries/gcc_versions/devel/src/libcilkrts
> -I/home/vries/gcc_versions/devel/src/libcilkrts/include
> -I/home/vries/gcc_versions/devel/src/libcilkrts/runtime
> -I/home/vries/gcc_versions/devel/src/libcilkrts/runtime/config/x86
> -DIN_CILK_RUNTIME=1 -D_Cilk_spawn= -D_Cilk_sync= -D_Cilk_for=for -
> fcilkplus -g3
> -O0 -dH -D_GNU_SOURCE -MT bug.lo -MD -MP -MF .deps/bug.Tpo -c
> /home/vries/gcc_versions/devel/src/libcilkrts/runtime/bug.cpp  -fPIC -DPIC -
> o .libs/bug.o
> g++: error: unrecognized command line option '-fcilkplus'
> make[2]: *** [bug.lo] Error 1
> make[2]: Leaving directory
> `/home/vries/gcc_versions/devel/lean-c/build/x86_64-unknown-linux-
> gnu/libcilkrts'
> ...
> 
> The error occurs because the compiler doesn't support -fcilkplus.
> 
> Should configure disable libcilkplus when c++ is not enabled?
> 

Yes, I should do that. Thanks for catching this.

> I see the same error with "--disable-bootstrap --enable-languages=c,c++".
> Should configure test the compiler for support of -fcilkplus and disable
> libcilkplus if not?
> 

Hmm, I generally build using the two flags and it always works for me. Let me 
try it again and get back to you.



> Thanks,
> - Tom

RE: [PATCH] RE: libcilkrts/runtime/config/generic/cilk-abi-vla.c failure

2013-10-31 Thread Iyer, Balaji V

Hi Rainer,
This patch looks OK.

Thanks,

Balaji V. Iyer.

-Original Message-
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Rainer 
Orth
Sent: Thursday, October 31, 2013 10:02 AM
To: Jakub Jelinek
Cc: Iyer, Balaji V; Gerald Pfeifer; Jeff Law; gcc@gcc.gnu.org
Subject: Re: [PATCH] RE: libcilkrts/runtime/config/generic/cilk-abi-vla.c 
failure

Jakub Jelinek  writes:

> On Thu, Oct 31, 2013 at 01:32:19PM +0000, Iyer, Balaji V wrote:
>> > It is not just about not including 3, but also the []s in 
>> > configure.ac were eaten by m4.  In any case, shouldn't you fix also 
>> > config/generic?
>> > 
>> 
>> I am in the process of fixing config/generic. I also replaced [456] 
>> with i?86.  That should work fine right?
>
> Yes.

Even with that change, i386-pc-solaris2.11 bootstrap is broken in libcilkrts in 
two different ways:

* Configuring the library fails for the 64-bit multilib: config.log
  shows

configure:3105: checking whether the C++ compiler works
configure:3114: ./a.out
ld.so.1: a.out: fatal: 
/var/gcc/regression/trunk/11-gcc/build/./gcc/libgcc_s.so.1: wrong ELF class: 
ELFCLASS32
/vol/gcc/src/hg/trunk/local/libcilkrts/configure[3116]: eval: line 1: 4955: 
Killed
configure:3118: $? = 265
configure:3125: error: in 
`/var/gcc/regression/trunk/11-gcc/build/i386-pc-solaris2.11/amd64/libcilkrts':
configure:3127: error: cannot run C++ compiled programs.

  There's no 64-bit libgcc_s.so.1 installed in the runtime linker's
  default search path, and toplevel Makefile (via RPATH_ENVVAR) only
  takes care of the default multilib.  This is also reported for the
  libgcj case in PR other/43445.

* Even after setting LD_LIBRARY_PATH_64 to work around this,
  compilation fails for os-unix.c:

/vol/gcc/src/hg/trunk/local/libcilkrts/runtime/os-unix.c:66:5: error: #error 
"Unsupported OS"
 #   error "Unsupported OS"
 ^
/vol/gcc/src/hg/trunk/local/libcilkrts/runtime/os-unix.c: In function 
'__cilkrts_hardware_cpu_count':
/vol/gcc/src/hg/trunk/local/libcilkrts/runtime/os-unix.c:378:2: error: #error 
"Unknown architecture"
 #error "Unknown architecture"
  ^
/vol/gcc/src/hg/trunk/local/libcilkrts/runtime/os-unix.c: In function 
'__cilkrts_yield':
/vol/gcc/src/hg/trunk/local/libcilkrts/runtime/os-unix.c:411:5: warning: 
implicit declaration of function 'pthread_yield' 
[-Wimplicit-function-declaration]
 pthread_yield();
 ^
make[2]: *** [os-unix.lo] Error 1

  The following patch fixes this:

2013-10-31  Rainer Orth  

* runtime/os-unix.c [__sun__ && __svr4__]: Include .
(__cilkrts_hardware_cpu_count) [__sun__ && __svr4__]: Use sysconf.
(__cilkrts_yield) [__sun__ && __svr4__]: Use sched_yield.

RE: Question about a fix for PR 58925

2013-10-31 Thread Iyer, Balaji V



> -Original Message-
> From: Andrew MacLeod [mailto:amacl...@redhat.com]
> Sent: Thursday, October 31, 2013 12:14 PM
> To: Iyer, Balaji V
> Cc: 'gcc@gcc.gnu.org'; Jeff Law
> Subject: Re: Question about a fix for PR 58925
> 
> On 10/31/2013 12:05 PM, Iyer, Balaji V wrote:
> >
> >> -Original Message-
> >> From: Andrew MacLeod [mailto:amacl...@redhat.com]
> >> Sent: Thursday, October 31, 2013 11:44 AM
> >> To: Iyer, Balaji V
> >> Cc: 'gcc@gcc.gnu.org'; Jeff Law
> >> Subject: Re: Question about a fix for PR 58925
> >>
> >> on a related note,  is there something I have to do to make the
> >> compiler bootstrap on x86_64?
> >>
> >> on x86_64 I checked out a fresh branch this morning, and my bootstrap
> >> fails trying to configure cilk runtime. It was doing it yesterday to
> >> me when I updated, so I tried a fresh checkout this morning.. same thing.
> >>
> >> its actually just configured pretty blandly on x86_64-unknown-linux-gnu...
> >> /gcc/2013-10-31/gcc/configure --verbose
> >> --prefix=/gcc/2013-10-31/install
> >>
> > That should just work. Let me look into this and get back to you. It
> bootstrapped for me correctly yesterday.
> >
> 
> Jakub says it does for him too...  So Im not sure what he scoop is.
> And it turns out it does work on a different x86 box I have.
> This is a pretty vanilla fedora 18.. huh.  I'll keep poking, especially now 
> that i
> have aworking  version I can compare the config.log files
> 

I have tried it on my Ubuntu and Suse machine. Both seem to work fine. Let me 
see if I can track down a Fedora machine...

RE: Question about a fix for PR 58925

2013-10-31 Thread Iyer, Balaji V



> -Original Message-
> From: Andrew MacLeod [mailto:amacl...@redhat.com]
> Sent: Thursday, October 31, 2013 11:44 AM
> To: Iyer, Balaji V
> Cc: 'gcc@gcc.gnu.org'; Jeff Law
> Subject: Re: Question about a fix for PR 58925
> 
> on a related note,  is there something I have to do to make the compiler
> bootstrap on x86_64?
> 
> on x86_64 I checked out a fresh branch this morning, and my bootstrap fails
> trying to configure cilk runtime. It was doing it yesterday to me when I 
> updated,
> so I tried a fresh checkout this morning.. same thing.
> 
> its actually just configured pretty blandly on x86_64-unknown-linux-gnu...
> /gcc/2013-10-31/gcc/configure --verbose --prefix=/gcc/2013-10-31/install
> 

That should just work. Let me look into this and get back to you. It 
bootstrapped for me correctly yesterday.

Thanks,

Balaji V. Iyer.

> 
> Checking multilib configuration for libcilkrts...(1)
> make[2]: Entering directory
> `/gcc/2013-10-31/build/x86_64-unknown-linux-gnu/libcilkrts'
> /bin/sh ./libtool  --tag=CC   --mode=compile
> /gcc/2013-10-31/build/./gcc/xgcc -B/gcc/2013-10-31/build/./gcc/ -B/gcc/2013-
> 10-31/install/x86_64-unknown-linux-gnu/bin/
> -B/gcc/2013-10-31/install/x86_64-unknown-linux-gnu/lib/ -isystem /gcc/2013-
> 10-31/install/x86_64-unknown-linux-gnu/include -isystem /gcc/2013-10-
> 31/install/x86_64-unknown-linux-gnu/sys-include
> -DPACKAGE_NAME=\"Cilk\ Runtime\ Library\"
> -DPACKAGE_TARNAME=\"cilk-runtime-library\" -DPACKAGE_VERSION=\"2.0\"
> -DPACKAGE_STRING=\"Cilk\ Runtime\ Library\ 2.0\"
> -DPACKAGE_BUGREPORT=\"c...@intel.com\" -DPACKAGE_URL=\"\"
> -DPACKAGE=\"cilk-runtime-library\" -DVERSION=\"2.0\" -DSTDC_HEADERS=1
> -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
> -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
> -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1
> -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_DLFCN_H=1 -
> DLT_OBJDIR=\".libs/\" -I. -I/gcc/2013-10-31/gcc/libcilkrts -I/gcc/2013-10-
> 31/gcc/libcilkrts/include
> -I/gcc/2013-10-31/gcc/libcilkrts/runtime
> -I/gcc/2013-10-31/gcc/libcilkrts/runtime/config/x86 -DIN_CILK_RUNTIME=1 -
> D_Cilk_spawn="" -D_Cilk_sync="" -D_Cilk_for=for -fcilkplus -I/gcc/2013-10-
> 31/gcc/libcilkrts/include
> -I/gcc/2013-10-31/gcc/libcilkrts/runtime
> -I/gcc/2013-10-31/gcc/libcilkrts/runtime/config/x86 -DIN_CILK_RUNTIME=1 -
> D_Cilk_spawn="" -D_Cilk_sync="" -D_Cilk_for=for -fcilkplus -std=c99 -g
> -O2 -MT cilk-abi-vla.lo -MD -MP -MF .deps/cilk-abi-vla.Tpo -c -o 
> cilk-abi-vla.lo
> `test -f 'runtime/config/x86/cilk-abi-vla.c' || echo '/gcc/2013-10-
> 31/gcc/libcilkrts/'`runtime/config/x86/cilk-abi-vla.c
> /bin/sh: ./libtool: No such file or directory
> make[2]: *** [cilk-abi-vla.lo] Error 127
> make[2]: Leaving directory
> `/gcc/2013-10-31/build/x86_64-unknown-linux-gnu/libcilkrts'
> make[1]: *** [all-target-libcilkrts] Error 2
> make[1]: Leaving directory `/gcc/2013-10-31/build'
> make: *** [all] Error 2
> 
> 
> Andrew

Question about a fix for PR 58925

2013-10-31 Thread Iyer, Balaji V

Hello Everyone, 
I am currently looking to fix the bug reported in PR 58925. Here is the 
issue,

When the user configures using the following command:
../gcc/configure --enable-version-specific-runtime-libs --disable-bootstrap 
--disable-werror --disable-multilib --enable-languages=c,c++

Make is OK, but when they do make install: here is the output we get

/include" "AR=/usr/x86_64-pc-linux-gnu/bin/ar" 
"AS=/var/tmp/gcc_build_dir/./gcc/as" 
"LD=/var/tmp/gcc_build_dir/./gcc/collect-ld" "LIBCFLAGS=-g -O2" 
"NM=/var/tmp/gcc_build_dir/./gcc/nm" "PICFLAG=" 
"RANLIB=/usr/x86_64-pc-linux-gnu/bin/ranlib" "DESTDIR=" DO=install multi-do # 
make
test -z "/usr/lib/gcc/x86_64-pc-linux-gnu/" || /bin/mkdir -p 
"/usr/lib/gcc/x86_64-pc-linux-gnu/"
 /bin/sh ./libtool   --mode=install /usr/bin/install -c   libcilkrts.la 
'/usr/lib/gcc/x86_64-pc-linux-gnu/'
libtool: install: error: cannot install `libcilkrts.la' to a directory not 
ending in /usr/lib/gcc/x86_64-pc-linux-gnu/


I googled the error, but most of them seem to say the issue is in libtool and 
doing a make clean before make would fix it. I tried that and it is not fixing 
it. Can someone please give me a suggestion as to where/what I should look for?


Thanks,

Balaji V. Iyer.

RE: [PATCH] RE: libcilkrts/runtime/config/generic/cilk-abi-vla.c failure (was: [PATCH, committed] libcilkrts - Add check for availability of alloca.h (Bug Bootstrap/58918))

2013-10-31 Thread Iyer, Balaji V



> -Original Message-
> From: Jakub Jelinek [mailto:ja...@redhat.com]
> Sent: Thursday, October 31, 2013 3:46 AM
> To: Iyer, Balaji V
> Cc: Gerald Pfeifer; Jeff Law; gcc@gcc.gnu.org
> Subject: Re: [PATCH] RE: libcilkrts/runtime/config/generic/cilk-abi-vla.c 
> failure
> (was: [PATCH, committed] libcilkrts - Add check for availability of alloca.h 
> (Bug
> Bootstrap/58918))
> 
> On Thu, Oct 31, 2013 at 03:21:14AM +, Iyer, Balaji V wrote:
> > It is because of this line:
> >
> >   i[456]86-*-*)
> > config_dir="x86"
> > ;;
> >
> > It should include a 3 too. My bad sorry. I have fixed it. Attached, please 
> > find a
> patch. It is committed as obvious.
> 
> It is not just about not including 3, but also the []s in configure.ac were 
> eaten by
> m4.  In any case, shouldn't you fix also config/generic?
> 

I am in the process of fixing config/generic. I also replaced [456] with i?86. 
That should work fine right?

>   Jakub

[PATCH] RE: libcilkrts/runtime/config/generic/cilk-abi-vla.c failure (was: [PATCH, committed] libcilkrts - Add check for availability of alloca.h (Bug Bootstrap/58918))

2013-10-30 Thread Iyer, Balaji V


> -Original Message-
> From: Gerald Pfeifer [mailto:ger...@pfeifer.com]
> Sent: Wednesday, October 30, 2013 9:39 PM
> To: Iyer, Balaji V
> Cc: Jeff Law; gcc@gcc.gnu.org
> Subject: libcilkrts/runtime/config/generic/cilk-abi-vla.c failure (was: 
> [PATCH,
> committed] libcilkrts - Add check for availability of alloca.h (Bug
> Bootstrap/58918))
> 
> On Wed, 30 Oct 2013, Iyer, Balaji V wrote:
> > This attached patch will check for usage of alloca.h before using it.
> > The change is entirely in libcilkrts and I am committing this change
> > as it is pretty obvious (the change was lifted from the autconf manual
> > example).
> 
> Thanks, Balaji!
> 
> Now my FreeBSD tester no longer shows this failure, but this:
> 
> /scratch2/tmp/gerald/gcc-HEAD/libcilkrts/runtime/config/generic/cilk-abi-vla.c:
> In function \xe2\x80\x98__cilkrts_stack_free\xe2\x80\x99:
> /scratch2/tmp/gerald/gcc-HEAD/libcilkrts/runtime/config/generic/cilk-abi-
> vla.c:1
> 06:28: error: \xe2\x80\x98t\xe2\x80\x99 undeclared (first use in this 
> function)
>  vla_internal_heap_free(t, full_size);
> ^
> 
> Looking at the source coude, indeed t is not declared anywhere that I can see.
> 
> So, two issues:
> 
>  - Why is it using the /generic subdirectory and not /x86 on
>i386-unknown-freebsd10.0?
> 

It is because of this line:

  i[456]86-*-*)
config_dir="x86"
;;

It should include a 3 too. My bad sorry. I have fixed it. Attached, please find 
a patch. It is committed as obvious.

>  - What doesn't libcilkrts/runtime/config/generic/cilk-abi-vla.c compile?
> 

I will ask my team and get back to you.

> Gerald
Index: libcilkrts/configure
===
--- libcilkrts/configure(revision 204244)
+++ libcilkrts/configure(working copy)
@@ -4907,7 +4907,7 @@
 config_dir="x86"
 ;;
 
-  i45686-*-*)
+  i?86-*-*)
 config_dir="x86"
 ;;
 
Index: libcilkrts/configure.ac
===
--- libcilkrts/configure.ac (revision 204244)
+++ libcilkrts/configure.ac (working copy)
@@ -115,7 +115,7 @@
 config_dir="x86"
 ;;
 
-  i[456]86-*-*)
+  i?86-*-*)
 config_dir="x86"
 ;;
 
Index: libcilkrts/ChangeLog
===
--- libcilkrts/ChangeLog(revision 204244)
+++ libcilkrts/ChangeLog(working copy)
@@ -1,5 +1,9 @@
 2013-10-30  Balaji V. Iyer  
 
+   * configure.ac: Changed a case statement to include i386.
+
+2013-10-30  Balaji V. Iyer  
+
* configure: Reconfigured.
* configure.ac: Add AC_FUNC_ALLOCA.
* runtime/sysdep-unix.c: Added check for alloca.h before

RE: libcilkrts portability

2013-10-30 Thread Iyer, Balaji V



> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Wednesday, October 30, 2013 1:04 PM
> To: Gerald Pfeifer; Iyer, Balaji V; gcc@gcc.gnu.org
> Subject: Re: libcilkrts portability
> 
> On 10/29/13 16:56, Gerald Pfeifer wrote:
> > Hi Balaji,
> >
> > On Wed, 23 Oct 2013, Iyer, Balaji V wrote:
> >> Is there anything you were thinking about that I missed?
> >
> > the question was in a different context, but making the code a bit
> > more portable would be good.
> >
> > Right now FreeBSD bootstrap is broken due to the following in
> > runtime/config/x86/cilk-abi-vla.c (and others):
> >
> >#include 
> >#include 
> >#include 
> >#ifdef _WIN32
> ># define alloca _alloca
> ># define INLINE static __inline
> ># pragma warning(disable:1025)  // Don't whine about zero extending 
> > result
> of unary operation
> >#else
> ># include 
> ># define INLINE static inline
> >#endif
> >
> > I'm running out of time on my end, but a bit of autoconf-igury and
> >
> ># ifdef HAVE_ALLOC_H
> >#  include 
> ># endif
> >
> > should heal this.
> >
> > ( http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58918 )
> Agreed.  Note I assigned 58918 to Balaji :-)
> 

...I am on it.

> jeff

RE: Cilk Library

2013-10-24 Thread Iyer, Balaji V

Hi Richard,
Here is the link to the fixed patch 
(https://drive.google.com/file/d/0BzEpbbnrYKsSNmpmM3NlRThfcWc/edit?usp=sharing).
 Answers to your questions are given below.

Thanks,

Balaji V. Iyer.

> -Original Message-
> From: Richard Henderson [mailto:r...@redhat.com]
> Sent: Thursday, October 24, 2013 12:15 PM
> To: Iyer, Balaji V; Jeff Law; gcc@gcc.gnu.org
> Cc: Aldy Hernandez (al...@redhat.com); Jason Merrill (ja...@redhat.com);
> Joseph S. Myers
> Subject: Re: Cilk Library
> 
> On 10/23/2013 12:30 PM, Iyer, Balaji V wrote:
> > Hi Jeff et al.,
> > Here is a link to the updated patch
> (https://docs.google.com/file/d/0BzEpbbnrYKsSbVY2X3ZLUnd4OXM/edit?usp=s
> haring). We have fixed all the issues that Joseph pointed out in
> http://gcc.gnu.org/ml/gcc/2013-10/msg00090.html. We have also added
> symbol versioning and have double-checked (using nm) that all symbols are
> hidden unless we have explicitly allowed them to be public.
> >
> 
> 
> In file included from ../../../git-master/libcilkrts/runtime/cilk-abi.c:52:0:
> ../../../git-master/libcilkrts/include/cilk/cilk_api.h:59:9: warning: 
> #warning Cilk
> API is being used with non-Cilk compiler (or Cilk is disabled) [-Wcpp]
>  #   warning Cilk API is being used with non-Cilk compiler (or Cilk is
> disabled)
> 
> and similar for
> 
>  ../../../git-master/libcilkrts/runtime/global_state.cpp:44
>  ../../../git-master/libcilkrts/runtime/reducer_impl.cpp:59
>  ../../../git-master/libcilkrts/runtime/scheduler.c:74:0:

To compile Cilk Library (libcilkrts), the compiler must have _Cilk_spawn and 
_Cilk_sync support. For this patch, I have defined (please see Makefile.am 
under GENERAL_FLAGS) the cilk-keywords to NULL to make this patch compile. When 
I commit this patch, I will commit the patches in the following order (after 
everything is approved that is):

1. Commit the _Cilk_spawn and _Cilk_sync for C and C++
2. Remove the -D_Cilk_spawn="" and -D_Cilk_sync="" and -D_Cilk_for=for from the 
Makefile.am
3. Commit the Cilk library patch

If we do it in the above order, you won't see those warnings.

> 
> > CILKABI1
> > {
> >   global:
> > __cilkrts_bind_thread_1;
> > __cilkrts_bump_loop_rank;
> > __cilkrts_bump_loop_rank_internal;
> > __cilkrts_bump_worker_rank;
> > __cilkrts_bump_worker_rank_internal;
> > __cilkrts_enter_frame_1;
> > __cilkrts_enter_frame_fast_1;
> > __cilkrts_get_pedigree_info;
> > __cilkrts_get_pedigree_internal;
> > __cilkrts_get_sf;
> > __cilkrts_get_stack_size;
> > __cilkrts_get_worker_rank;
> > __cilkrts_save_fp_ctrl_state;
> > __cilkrts_stack_alloc;
> > __cilkrts_stack_free;
> > __cilkrts_watch_stack;
> > };
> 
> You probably want CILKABI1 to inherit from CILKABI0.  E.g.

The inheritance is added.

> 
>   } CLKABI0;
> 
> Is there any relation between these and CILKLIB1.02?
> 

There is no relation. They simply are exported by the same shared object.

> 
> r~

RE: Cilk Library

2013-10-24 Thread Iyer, Balaji V

Hi Joseph and Jeff,
The issue you mentioned below is fixed. I added a configure.tgt file in 
libcilkrts and modified configure.ac (both libcilkrts and the toplevel gcc one) 
accordingly. Here is a link for the patch 
(https://drive.google.com/file/d/0BzEpbbnrYKsSZFR6cktQQWtXQms/edit?usp=sharing).

Thanks,

Balaji V. Iyer.

> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Wednesday, October 23, 2013 4:33 PM
> To: Joseph S. Myers; Iyer, Balaji V
> Cc: gcc@gcc.gnu.org; Aldy Hernandez (al...@redhat.com); r...@redhat.com;
> Jason Merrill (ja...@redhat.com)
> Subject: Re: Cilk Library
> 
> On 10/23/13 14:22, Joseph S. Myers wrote:
> > On Wed, 23 Oct 2013, Iyer, Balaji V wrote:
> >
> >> Hi Jeff et al.,
> >>Here is a link to the updated patch
> >>
> (https://docs.google.com/file/d/0BzEpbbnrYKsSbVY2X3ZLUnd4OXM/edit?usp=s
> haring).
> >> We have fixed all the issues that Joseph pointed out in
> >> http://gcc.gnu.org/ml/gcc/2013-10/msg00090.html. We have also added
> >> symbol versioning and have double-checked (using nm) that all symbols
> >> are hidden unless we have explicitly allowed them to be public.
> >
> > As I said in my previous comments, please follow libatomic, libitm,
> > libsanitizer or libvtv in using a configure.tgt file in the library's
> > subdirectory to describe what systems are supported.  This is
> > especially important now that all toplevel patches need applying to
> > three rather than two repositories (GCC SVN, src CVS, binutils-gdb
> > git) - anything logically specific to one of those three should go in
> > an appropriate subdirectory whenever possible, to reduce the number of
> > changes needing syncing to multiple places.
> It also just makes sense from a modularity point of view.  Whether or not 
> cilkrts
> is supported is a property of cilkrts and thus code to detect that and "do the
> right thing" should live within the cilkrts directory.
> 
> 
> > (Yes, there's lots of configuration specific to newlib/libgloss,
> > binutils, gdb or individual GCC libraries that's still hardcoded in
> > the toplevel configure.ac and should move to such configure.tgt or
> > similar files in subdirectories.  Patches moving it to such files are 
> > certainly
> welcome.
> > But at least we shouldn't add new directories with details at toplevel
> > of what targets they support.)
> Agreed.  There's a lot of cruft up there that needs to move down into the
> subdirectories.  Unfortunately there's not many people actively working to
> address these maintenance issues.
> 
> 
> I didn't see anything else grossly wrong.  I think once the
> configure.tgt stuff is addressed, this patch is good to go.   As
> previously discussed, don't actually check it in until the final approval is 
> in place
> for the keywords.
> 

> jeff

RE: Cilk Library

2013-10-23 Thread Iyer, Balaji V

Hi Jeff et al.,
Here is a link to the updated patch 
(https://docs.google.com/file/d/0BzEpbbnrYKsSbVY2X3ZLUnd4OXM/edit?usp=sharing). 
We have fixed all the issues that Joseph pointed out in 
http://gcc.gnu.org/ml/gcc/2013-10/msg00090.html. We have also added symbol 
versioning and have double-checked (using nm) that all symbols are hidden 
unless we have explicitly allowed them to be public.

Thanks,

Balaji V. Iyer.

> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Wednesday, October 23, 2013 1:15 AM
> To: Iyer, Balaji V; gcc@gcc.gnu.org
> Cc: Aldy Hernandez (al...@redhat.com); r...@redhat.com; Jason Merrill
> (ja...@redhat.com)
> Subject: Re: Cilk Library
> 
> On 10/16/13 13:30, Iyer, Balaji V wrote:
> >> First, the all issues Joseph mentioned need to be addressed.  So
> >> first, you need to ensure it's only being built on x86/x86_64 given
> >> the asms and bring together some documentation as to what's needed to
> port the
> >> runtime system to other architectures.   Closely related, I think you
> >> initially need to ensure it only builds on x86-linux platforms --
> >> unless you've already verified it works properly on one or more of
> >> the bsd platforms, solaris, windows, etc.
> >>
> >
> > We are in the process of addressing all these. I will send out an email 
> > with the
> fixed runtime as soon as I can.
> Excellent.  THanks.
> 
> 
> >> I would strongly echo Joseph's recommendation to ensure that only
> >> those symbols specifically intended to be part of the public
> >> interface are exported from the shared library. How stable has the exported
> API/ABI
> >> for Cilk+ been?Related: how clean is the RTS from a compile-time
> >> namespace pollution standpoint.  For C++ is everything in a
> >> namespace, for C is everything prefixed appropriately?
> >>
> >
> > We are currently verifying those and making sure only the required symbols
> are exported.
> IMHO, the best way to do this is with linker scripts and it's an excellent 
> time ot
> drop in versioning information.  I'd think this would be useful for ICC as 
> well.
> This is probably the biggest issue.  I'll note Richi chimed in on this as 
> well.
> 
> Look at libatomic/libatomic.map and how that gets used.  It gives you full
> control over the exports.
> 
> jeff

RE: Cilk Library

2013-10-23 Thread Iyer, Balaji V



> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Wednesday, October 23, 2013 1:15 AM
> To: Iyer, Balaji V; gcc@gcc.gnu.org
> Cc: Aldy Hernandez (al...@redhat.com); r...@redhat.com; Jason Merrill
> (ja...@redhat.com)
> Subject: Re: Cilk Library
> 
> On 10/16/13 13:30, Iyer, Balaji V wrote:
> >> First, the all issues Joseph mentioned need to be addressed.  So
> >> first, you need to ensure it's only being built on x86/x86_64 given
> >> the asms and bring together some documentation as to what's needed to
> port the
> >> runtime system to other architectures.   Closely related, I think you
> >> initially need to ensure it only builds on x86-linux platforms --
> >> unless you've already verified it works properly on one or more of
> >> the bsd platforms, solaris, windows, etc.
> >>
> >
> > We are in the process of addressing all these. I will send out an email 
> > with the
> fixed runtime as soon as I can.
> Excellent.  THanks.
> 
> 
> >> I would strongly echo Joseph's recommendation to ensure that only
> >> those symbols specifically intended to be part of the public
> >> interface are exported from the shared library. How stable has the exported
> API/ABI
> >> for Cilk+ been?Related: how clean is the RTS from a compile-time
> >> namespace pollution standpoint.  For C++ is everything in a
> >> namespace, for C is everything prefixed appropriately?
> >>
> >
> > We are currently verifying those and making sure only the required symbols
> are exported.
> IMHO, the best way to do this is with linker scripts and it's an excellent 
> time ot
> drop in versioning information.  I'd think this would be useful for ICC as 
> well.
> This is probably the biggest issue.  I'll note Richi chimed in on this as 
> well.
> 
Yup we have implemented versioning. Also, we have just completed all the things 
that Joseph Myers mentioned and are in the process of testing it. I will send 
out a revised patch this week itself.

> Look at libatomic/libatomic.map and how that gets used.  It gives you full
> control over the exports.
> 
> jeff

RE: Cilk Library

2013-10-16 Thread Iyer, Balaji V

Hello Jeff, 
Please see my comments below:

Thanks,

Balaji V. Iyer.


> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Tuesday, October 15, 2013 4:14 PM
> To: Iyer, Balaji V; gcc@gcc.gnu.org
> Cc: Aldy Hernandez (al...@redhat.com); r...@redhat.com; Jason Merrill
> (ja...@redhat.com)
> Subject: Re: Cilk Library
> 
> On 10/09/13 12:32, Iyer, Balaji V wrote:
> > Dear Jeff and the rest of Steering committee members,
> >   Thank you very much for approving the license terms of the Cilk 
> > Library. I
> couldn't attach the zipped copy of the patch due to its size, so here is a 
> link to
> the Cilk library patch that can be applied to the trunk:
> (https://docs.google.com/file/d/0BzEpbbnrYKsSWjBWSkNrVS1SaGs/edit?usp=sh
> aring).
> >
> >   Is it OK for trunk?
> >
> > Here are the ChangeLog entries:
> >
> > ChangeLog:
> > 2013-10-09  Balaji V. Iyer  
> >
> >  * Makefile.def: Add libcilkrts to target_modules.  Make libcilkrts
> >  depend on libstdc++ and libgcc.
> >  * configure.ac: Added libcilkrts to target binaries.
> >  * configure: Likewise.
> >  * Makefile.in: Added libcilkrts related fields to support building 
> > it.
> >
> > libcilkrts/ChangeLog:
> > 2013-10-09  Balaji V. Iyer  
> >
> > * libcilkrts/Makefile.am: New file.  Libcilkrts version 3613.
> > * libcilkrts/Makefile.in: Likewise.
> > * libcilkrts/README: Likewise.
> > * libcilkrts/aclocal.m4: Likewise.
> > * libcilkrts/configure: Likewise.
> > * libcilkrts/configure.ac: Likewise.
> > * libcilkrts/include/cilk/cilk.h: Likewise.
> > * libcilkrts/include/cilk/cilk_api.h: Likewise.
> > * libcilkrts/include/cilk/cilk_api_linux.h: Likewise.
> > * libcilkrts/include/cilk/cilk_stub.h: Likewise.
> > * libcilkrts/include/cilk/cilk_undocumented.h: Likewise.
> > * libcilkrts/include/cilk/common.h: Likewise.
> > * libcilkrts/include/cilk/holder.h: Likewise.
> > * libcilkrts/include/cilk/hyperobject_base.h: Likewise.
> > * libcilkrts/include/cilk/metaprogramming.h: Likewise.
> > * libcilkrts/include/cilk/reducer.h: Likewise.
> > * libcilkrts/include/cilk/reducer_file.h: Likewise.
> > * libcilkrts/include/cilk/reducer_list.h: Likewise.
> > * libcilkrts/include/cilk/reducer_max.h: Likewise.
> > * libcilkrts/include/cilk/reducer_min.h: Likewise.
> > * libcilkrts/include/cilk/reducer_min_max.h: Likewise.
> > * libcilkrts/include/cilk/reducer_opadd.h: Likewise.
> > * libcilkrts/include/cilk/reducer_opand.h: Likewise.
> > * libcilkrts/include/cilk/reducer_opmul.h: Likewise.
> > * libcilkrts/include/cilk/reducer_opor.h: Likewise.
> > * libcilkrts/include/cilk/reducer_opxor.h: Likewise.
> > * libcilkrts/include/cilk/reducer_ostream.h: Likewise.
> > * libcilkrts/include/cilk/reducer_string.h: Likewise.
> > * libcilkrts/include/cilktools/cilkscreen.h: Likewise.
> > * libcilkrts/include/cilktools/cilkview.h: Likewise.
> > * libcilkrts/include/cilktools/fake_mutex.h: Likewise.
> > * libcilkrts/include/cilktools/lock_guard.h: Likewise.
> > * libcilkrts/include/internal/abi.h: Likewise.
> > * libcilkrts/include/internal/cilk_fake.h: Likewise.
> > * libcilkrts/include/internal/cilk_version.h: Likewise.
> > * libcilkrts/include/internal/inspector-abi.h: Likewise.
> > * libcilkrts/include/internal/metacall.h: Likewise.
> > * libcilkrts/include/internal/rev.mk: Likewise.
> > * libcilkrts/mk/cilk-version.mk: Likewise.
> > * libcilkrts/mk/unix-common.mk: Likewise.
> > * libcilkrts/runtime/acknowledgements.dox: Likewise.
> > * libcilkrts/runtime/bug.cpp: Likewise.
> > * libcilkrts/runtime/bug.h: Likewise.
> > * libcilkrts/runtime/c_reducers.c: Likewise.
> > * libcilkrts/runtime/cilk-abi-cilk-for.cpp: Likewise.
> > * libcilkrts/runtime/cilk-abi-vla-internal.c: Likewise.
> > * libcilkrts/runtime/cilk-abi-vla-internal.h: Likewise.
> > * libcilkrts/runtime/cilk-abi-vla.c: Likewise.
> > * libcilkrts/runtime/cilk-abi.c: Likewise.
> > * libcilkrts/runtime/cilk-ittnotify.h: Likewise.
> > * libcilkrts/runtime/cilk-tbb-interop.h: Likewise.
> > * libcilkrts/runtime/cilk_api.c: Likewise.
> > * libcilkrts/runtime/cilk_fiber-unix.cpp: Likewise.
> > * libcilkrts/runtime/cilk_fiber-unix.h: Likewise.
> > * libcilkrts/runtime/cilk_fiber.cpp: Likewise.
> > * libcilkrts/runt

RE: Cilk Library

2013-10-10 Thread Iyer, Balaji V



> -Original Message-
> From: Aldy Hernandez [mailto:al...@redhat.com]
> Sent: Thursday, October 10, 2013 9:19 AM
> To: Iyer, Balaji V
> Cc: Jeff Law; gcc@gcc.gnu.org; r...@redhat.com; Jason Merrill
> (ja...@redhat.com)
> Subject: Re: Cilk Library
> 
> On 10/09/13 13:32, Iyer, Balaji V wrote:
> 
> >   Is it OK for trunk?
> >
> 
> I would prefer that a consumer of this library be in place before you commit.
> That is, until cilk_spawn/sync/etc go in.

Yup that's the plan.

RE: Cilk Library

2013-10-09 Thread Iyer, Balaji V

ntime/metacall_impl.c: Likewise.
* libcilkrts/runtime/metacall_impl.h: Likewise.
* libcilkrts/runtime/os-unix.c: Likewise.
* libcilkrts/runtime/os.h: Likewise.
* libcilkrts/runtime/os_mutex-unix.c: Likewise.
* libcilkrts/runtime/os_mutex.h: Likewise.
* libcilkrts/runtime/pedigrees.c: Likewise.
* libcilkrts/runtime/pedigrees.h: Likewise.
* libcilkrts/runtime/record-replay.cpp: Likewise.
* libcilkrts/runtime/record-replay.h: Likewise.
* libcilkrts/runtime/reducer_impl.cpp: Likewise.
* libcilkrts/runtime/reducer_impl.h: Likewise.
* libcilkrts/runtime/rts-common.h: Likewise.
* libcilkrts/runtime/scheduler.c: Likewise.
* libcilkrts/runtime/scheduler.h: Likewise.
* libcilkrts/runtime/signal_node.c: Likewise.
* libcilkrts/runtime/signal_node.h: Likewise.
* libcilkrts/runtime/spin_mutex.c: Likewise.
* libcilkrts/runtime/spin_mutex.h: Likewise.
* libcilkrts/runtime/stacks.h: Likewise.
* libcilkrts/runtime/stats.c: Likewise.
* libcilkrts/runtime/stats.h: Likewise.
* libcilkrts/runtime/symbol_test.c: Likewise.
* libcilkrts/runtime/sysdep-unix.c: Likewise.
* libcilkrts/runtime/sysdep.h: Likewise.
* libcilkrts/runtime/unix_symbols.t: Likewise.
* libcilkrts/runtime/worker_mutex.c: Likewise.
* libcilkrts/runtime/worker_mutex.h: Likewise.

Thanks,

Balaji V. Iyer.
   

> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Tuesday, October 08, 2013 3:45 PM
> To: Iyer, Balaji V; gcc@gcc.gnu.org
> Cc: Aldy Hernandez (al...@redhat.com); r...@redhat.com; Jason Merrill
> (ja...@redhat.com)
> Subject: Re: Cilk Library
> 
> On 10/02/13 13:40, Iyer, Balaji V wrote:
> > Dear steering committee, To support the _Cilk_spawn, and _Cilk_sync
> > implementation in GCC (patch submitted link:
> > http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00859.html), we need to
> > add a foreign library (Cilk Runtime Library) into the gcc repository.
> > With this email, I am attaching the README file that will accompany
> > Cilk Runtime Library (libcilkrts). I am also copy-pasting the header
> > comment from one of the libcilkrts files. The header shown below will
> > be in all the source files in libcilkrts. Does this look OK?
> >
> 
> I'm pleased to announce the steering committee approves the license terms for
> the Cilk+ runtime system as well as the plan to have the Cilk+ runtime
> maintained upstream by Intel and copied into the GCC repository.
> 
> Given the runtime system will be maintained upstream by Intel, only a cursory
> review of the runtime system should be necessary -- basically stuff like 
> ensuring
> it integrates into our build system, copyrights are in place and the like.
> 
> 
> Jeff

Cilk Library

2013-10-02 Thread Iyer, Balaji V

Dear steering committee,
To support the _Cilk_spawn, and _Cilk_sync implementation in GCC (patch 
submitted link: http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00859.html), we 
need to add a foreign library (Cilk Runtime Library) into the gcc repository. 
With this email, I am attaching the README file that will accompany Cilk 
Runtime Library (libcilkrts). I am also copy-pasting the header comment from 
one of the libcilkrts files. The header shown below will be in all the source 
files in libcilkrts. Does this look OK?

Thanks,

Balaji V. Iyer.


/* cilk_api.c  -*-C-*-
 *
 *
 *
 *  @copyright
 *  Copyright (C) 2009-2013, Intel Corporation
 *  All rights reserved.
 *
 *  @copyright
 *  Redistribution and use in source and binary forms, with or without
 *  modification, are permitted provided that the following conditions
 *  are met:
 *
 ** Redistributions of source code must retain the above copyright
 *  notice, this list of conditions and the following disclaimer.
 ** Redistributions in binary form must reproduce the above copyright
 *  notice, this list of conditions and the following disclaimer in
 *  the documentation and/or other materials provided with the
 *  distribution.
 ** Neither the name of Intel Corporation nor the names of its
 *  contributors may be used to endorse or promote products derived
 *  from this software without specific prior written permission.
 *
 *  @copyright
 *  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
 *  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
 *  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
 *  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
 *  HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
 *  INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
 *  BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
 *  OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
 *  AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 *  LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY
 *  WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
 *  POSSIBILITY OF SUCH DAMAGE.
 **/


README
Description: README

RE: Help with using multilib for Cilk Library

2013-07-23 Thread Iyer, Balaji V



> -Original Message-
> From: H.J. Lu [mailto:hjl.to...@gmail.com]
> Sent: Tuesday, July 23, 2013 1:04 PM
> To: Iyer, Balaji V
> Cc: Ian Lance Taylor; gcc@gcc.gnu.org
> Subject: Re: Help with using multilib for Cilk Library
> 
> On Tue, Jul 23, 2013 at 9:33 AM, Iyer, Balaji V  
> wrote:
> >> Here is a patch:
> >>
> >> 1. Add target dependency on C++ for parallel build.
> >> 2. Remove hardcoded -O3 -fpic. libtool takes care of it.
> >> 3. Work around MAKEFLAGS for multilib build.
> >>
> >
> > Hi H.J.,
> > Thank you! This patch got rid of all the errors for me. When I do 
> > make
> install, it is installing both the 32 bit one and 64 bit one in 
> $INSTALL_DIR/lib.
> How can I make the 32 bit one write to $INSTALL_DIR/lib and the 64-bit one
> write to $INSTALL_DIR/lib64?
> >
> 
> Try this:
> 
>  # Target list.
> -lib_LTLIBRARIES = libcilkrts.la
> +toolexeclib_LTLIBRARIES = libcilkrts.la
> 
> on libcilkrts/Makefile.am.

It works now! Thanks for all your help!

Thanks,

Balaji V. Iyer.

> 
> --
> H.J.

RE: Help with using multilib for Cilk Library

2013-07-23 Thread Iyer, Balaji V



> -Original Message-
> From: H.J. Lu [mailto:hjl.to...@gmail.com]
> Sent: Monday, July 22, 2013 5:08 PM
> To: Iyer, Balaji V
> Cc: Ian Lance Taylor; gcc@gcc.gnu.org
> Subject: Re: Help with using multilib for Cilk Library
> 
> On Mon, Jul 22, 2013 at 9:27 AM, Iyer, Balaji V  
> wrote:
> >
> >
> >> -Original Message-
> >> From: H.J. Lu [mailto:hjl.to...@gmail.com]
> >> Sent: Friday, July 19, 2013 6:56 PM
> >> To: Iyer, Balaji V
> >> Cc: Ian Lance Taylor; gcc@gcc.gnu.org
> >> Subject: Re: Help with using multilib for Cilk Library
> >>
> >> On Fri, Jul 19, 2013 at 3:53 PM, Iyer, Balaji V  
> >> wrote:
> >> >
> >> >
> >> >> -Original Message-
> >> >> From: Ian Lance Taylor [mailto:i...@google.com]
> >> >> Sent: Friday, July 19, 2013 6:26 PM
> >> >> To: Iyer, Balaji V
> >> >> Cc: gcc@gcc.gnu.org
> >> >> Subject: Re: Help with using multilib for Cilk Library
> >> >>
> >> >> On Fri, Jul 19, 2013 at 11:22 AM, Iyer, Balaji V
> >> >> 
> >> wrote:
> >> >> > Hello Everyone,
> >> >> > I am trying to use Multilib on Cilk Library. I looked at
> >> >> > this website
> >> >> (http://www.airs.com/ian/configure/configure_8.html) and used
> >> >> libsanitizer and libgo as samples to model after. It is currently
> >> >> failing with the following error
> >> >> message:
> >> >> >
> >> >> > libtool: link: /export/users/my-files/b-gcc-multilib/./gcc/xg++
> >> >> > -
> >> >> B/export/users/my-files/b-gcc-multilib/./gcc/ -nostdinc++
> >> >> -nostdinc++
> >> >> -
> >> >> I/export/users/my-files/b-gcc-multilib/x86_64-unknown-linux-gnu/32
> >> >> /li
> >> >> bstdc++- v3/include/x86_64-unknown-linux-gnu
> >> >> -I/export/users/my-files/b-gcc-
> >> >> multilib/x86_64-unknown-linux-gnu/32/libstdc++-v3/include -
> >> >> I/export/users/my-files/gcc/libstdc++-v3/libsupc++
> >> >> -I/export/users/my- files/gcc/libstdc++-v3/include/backward
> >> >> -I/export/users/my-files/gcc/libstdc++-
> >> >> v3/testsuite/util
> >> >> -L/export/users/my-files/b-gcc-multilib/x86_64-unknown-linux-
> >> >> gnu/32/libstdc++-v3/src
> >> >> -L/export/users/my-files/b-gcc-multilib/x86_64-
> >> >> unknown-linux-gnu/32/libstdc++-v3/src/.libs
> >> >> -B/export/users/my-files/install-
> >> >> gcc-multilib/x86_64-unknown-linux-gnu/bin/
> >> >> -B/export/users/my-files/install-
> >> >> gcc-multilib/x86_64-unknown-linux-gnu/lib/ -isystem
> >> >> /export/users/my-
> >> >> files/install-gcc-multilib/x86_64-unknown-linux-gnu/include
> >> >> -isystem
> >> >> /export/users/my-files/install-gcc-multilib/x86_64-unknown-linux-g
> >> >> nu/
> >> >> sys- include  -m32 -shared -nostdlib /usr/lib/../lib/crti.o
> >> >> /export/users/my-files/b- gcc-multilib/./gcc/32/crtbeginS.o
> >> >> .libs/bug.o .libs/cilk-abi.o .libs/cilk-abi-cilk- for.o
> >> >> .libs/cilk-abi-vla.o .libs/cilk-abi-vla-internal.o
> >> >> .libs/cilk_api.o .libs/cilk_fiber.o .libs/cilk_fiber-unix.o
> >> >> .libs/cilk_malloc.o .libs/c_reducers.o .libs/except-gcc.o
> >> >> .libs/frame_malloc.o .libs/full_frame.o .libs/global_state.o
> >> >> .libs/jmpbuf.o .libs/local_state.o .libs/metacall_impl.o
> >> >> .libs/os_mutex-unix.o .libs/os-unix.o .libs/pedigrees.o
> >> >> .libs/record-replay.o .libs/reducer_impl.o
> >> .libs/scheduler.o .libs/signal_node.o .libs/spin_mutex.o
> >> .libs/stats.o
> >> >> .libs/symbol_test.o .libs/sysdep-unix.o .libs/worker_mutex.o   
> >> >> -Wl,-rpath -
> >> >> Wl,/export/users/my-files/b-gcc-multilib/x86_64-unknown-linux-gnu/
> >> >> lib
> >> >> stdc++- v3/src/.libs -Wl,-rpath
> >> >> -Wl,/export/users/my-files/install-gcc-multilib/lib/../lib64
> >> >> -L/export/users/my-files/b-gcc-multilib/x86_64-unknown-linux-gnu/l
> >> >> ibs
> >> >> tdc++- v3/src/.libs
> >> >> -L/export/users/my-files/b-gcc-multilib/x86_64-unknown-linux-
> >> >> gnu/libstdc++-v3/src -lpthread -ldl
> >> >> -L/export/users/my-

RE: Help with using multilib for Cilk Library

2013-07-22 Thread Iyer, Balaji V



> -Original Message-
> From: H.J. Lu [mailto:hjl.to...@gmail.com]
> Sent: Friday, July 19, 2013 6:56 PM
> To: Iyer, Balaji V
> Cc: Ian Lance Taylor; gcc@gcc.gnu.org
> Subject: Re: Help with using multilib for Cilk Library
> 
> On Fri, Jul 19, 2013 at 3:53 PM, Iyer, Balaji V  
> wrote:
> >
> >
> >> -Original Message-
> >> From: Ian Lance Taylor [mailto:i...@google.com]
> >> Sent: Friday, July 19, 2013 6:26 PM
> >> To: Iyer, Balaji V
> >> Cc: gcc@gcc.gnu.org
> >> Subject: Re: Help with using multilib for Cilk Library
> >>
> >> On Fri, Jul 19, 2013 at 11:22 AM, Iyer, Balaji V 
> wrote:
> >> > Hello Everyone,
> >> > I am trying to use Multilib on Cilk Library. I looked at
> >> > this website
> >> (http://www.airs.com/ian/configure/configure_8.html) and used
> >> libsanitizer and libgo as samples to model after. It is currently
> >> failing with the following error
> >> message:
> >> >
> >> > libtool: link: /export/users/my-files/b-gcc-multilib/./gcc/xg++ -
> >> B/export/users/my-files/b-gcc-multilib/./gcc/ -nostdinc++ -nostdinc++
> >> -
> >> I/export/users/my-files/b-gcc-multilib/x86_64-unknown-linux-gnu/32/li
> >> bstdc++- v3/include/x86_64-unknown-linux-gnu
> >> -I/export/users/my-files/b-gcc-
> >> multilib/x86_64-unknown-linux-gnu/32/libstdc++-v3/include -
> >> I/export/users/my-files/gcc/libstdc++-v3/libsupc++
> >> -I/export/users/my- files/gcc/libstdc++-v3/include/backward
> >> -I/export/users/my-files/gcc/libstdc++-
> >> v3/testsuite/util
> >> -L/export/users/my-files/b-gcc-multilib/x86_64-unknown-linux-
> >> gnu/32/libstdc++-v3/src
> >> -L/export/users/my-files/b-gcc-multilib/x86_64-
> >> unknown-linux-gnu/32/libstdc++-v3/src/.libs
> >> -B/export/users/my-files/install-
> >> gcc-multilib/x86_64-unknown-linux-gnu/bin/
> >> -B/export/users/my-files/install-
> >> gcc-multilib/x86_64-unknown-linux-gnu/lib/ -isystem /export/users/my-
> >> files/install-gcc-multilib/x86_64-unknown-linux-gnu/include -isystem
> >> /export/users/my-files/install-gcc-multilib/x86_64-unknown-linux-gnu/
> >> sys- include  -m32 -shared -nostdlib /usr/lib/../lib/crti.o
> >> /export/users/my-files/b- gcc-multilib/./gcc/32/crtbeginS.o
> >> .libs/bug.o .libs/cilk-abi.o .libs/cilk-abi-cilk- for.o
> >> .libs/cilk-abi-vla.o .libs/cilk-abi-vla-internal.o .libs/cilk_api.o
> >> .libs/cilk_fiber.o .libs/cilk_fiber-unix.o .libs/cilk_malloc.o
> >> .libs/c_reducers.o .libs/except-gcc.o .libs/frame_malloc.o
> >> .libs/full_frame.o .libs/global_state.o .libs/jmpbuf.o
> >> .libs/local_state.o .libs/metacall_impl.o .libs/os_mutex-unix.o
> >> .libs/os-unix.o .libs/pedigrees.o .libs/record-replay.o 
> >> .libs/reducer_impl.o
> .libs/scheduler.o .libs/signal_node.o .libs/spin_mutex.o .libs/stats.o
> >> .libs/symbol_test.o .libs/sysdep-unix.o .libs/worker_mutex.o   -Wl,-rpath -
> >> Wl,/export/users/my-files/b-gcc-multilib/x86_64-unknown-linux-gnu/lib
> >> stdc++- v3/src/.libs -Wl,-rpath
> >> -Wl,/export/users/my-files/install-gcc-multilib/lib/../lib64
> >> -L/export/users/my-files/b-gcc-multilib/x86_64-unknown-linux-gnu/libs
> >> tdc++- v3/src/.libs
> >> -L/export/users/my-files/b-gcc-multilib/x86_64-unknown-linux-
> >> gnu/libstdc++-v3/src -lpthread -ldl -L/export/users/my-files/b-gcc-
> >> multilib/x86_64-unknown-linux-gnu/32/libstdc++-v3/src
> >> -L/export/users/my-
> >> files/b-gcc-multilib/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.li
> >> bs -
> >> L/export/users/my-files/b-gcc-multilib/./gcc/32 -L/lib/../lib
> >> -L/usr/lib/../lib - L/export/users/my-files/b-gcc-multilib/./gcc
> >> /export/users/my-files/b-gcc-
> >> multilib/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so -lm 
> >> -lc
> - lgcc_s /export/users/my-files/b-gcc-multilib/./gcc/32/crtendS.o
> >> /usr/lib/../lib/crtn.o  -m32 -m32   -Wl,-soname -Wl,libcilkrts.so.5 -o
> >> .libs/libcilkrts.so.5.0.3511
> >> > /export/users/my-files/b-gcc-multilib/x86_64-unknown-linux-gnu/libs
> >> > tdc
> >> > ++-v3/src/.libs/libstdc++.so: could not read symbols: File in wrong
> >> > format
> >> > collect2: error: ld returned 1 exit status
> >> > make[4]: *** [libcilkrts.la] Error 1
> >> > make[4]: Leaving directory
> >> > `/export/users/my-files/b-gcc-multilib/x86_64-
> >> unknown-linux-gnu/32/libcilkrts&#

RE: Help with using multilib for Cilk Library

2013-07-19 Thread Iyer, Balaji V



> -Original Message-
> From: Ian Lance Taylor [mailto:i...@google.com]
> Sent: Friday, July 19, 2013 6:26 PM
> To: Iyer, Balaji V
> Cc: gcc@gcc.gnu.org
> Subject: Re: Help with using multilib for Cilk Library
> 
> On Fri, Jul 19, 2013 at 11:22 AM, Iyer, Balaji V  
> wrote:
> > Hello Everyone,
> > I am trying to use Multilib on Cilk Library. I looked at this 
> > website
> (http://www.airs.com/ian/configure/configure_8.html) and used libsanitizer and
> libgo as samples to model after. It is currently failing with the following 
> error
> message:
> >
> > libtool: link: /export/users/my-files/b-gcc-multilib/./gcc/xg++ -
> B/export/users/my-files/b-gcc-multilib/./gcc/ -nostdinc++ -nostdinc++ -
> I/export/users/my-files/b-gcc-multilib/x86_64-unknown-linux-gnu/32/libstdc++-
> v3/include/x86_64-unknown-linux-gnu -I/export/users/my-files/b-gcc-
> multilib/x86_64-unknown-linux-gnu/32/libstdc++-v3/include -
> I/export/users/my-files/gcc/libstdc++-v3/libsupc++ -I/export/users/my-
> files/gcc/libstdc++-v3/include/backward 
> -I/export/users/my-files/gcc/libstdc++-
> v3/testsuite/util 
> -L/export/users/my-files/b-gcc-multilib/x86_64-unknown-linux-
> gnu/32/libstdc++-v3/src -L/export/users/my-files/b-gcc-multilib/x86_64-
> unknown-linux-gnu/32/libstdc++-v3/src/.libs -B/export/users/my-files/install-
> gcc-multilib/x86_64-unknown-linux-gnu/bin/ -B/export/users/my-files/install-
> gcc-multilib/x86_64-unknown-linux-gnu/lib/ -isystem /export/users/my-
> files/install-gcc-multilib/x86_64-unknown-linux-gnu/include -isystem
> /export/users/my-files/install-gcc-multilib/x86_64-unknown-linux-gnu/sys-
> include  -m32 -shared -nostdlib /usr/lib/../lib/crti.o 
> /export/users/my-files/b-
> gcc-multilib/./gcc/32/crtbeginS.o  .libs/bug.o .libs/cilk-abi.o 
> .libs/cilk-abi-cilk-
> for.o .libs/cilk-abi-vla.o .libs/cilk-abi-vla-internal.o .libs/cilk_api.o
> .libs/cilk_fiber.o .libs/cilk_fiber-unix.o .libs/cilk_malloc.o 
> .libs/c_reducers.o
> .libs/except-gcc.o .libs/frame_malloc.o .libs/full_frame.o 
> .libs/global_state.o
> .libs/jmpbuf.o .libs/local_state.o .libs/metacall_impl.o .libs/os_mutex-unix.o
> .libs/os-unix.o .libs/pedigrees.o .libs/record-replay.o .libs/reducer_impl.o
> .libs/scheduler.o .libs/signal_node.o .libs/spin_mutex.o .libs/stats.o
> .libs/symbol_test.o .libs/sysdep-unix.o .libs/worker_mutex.o   -Wl,-rpath -
> Wl,/export/users/my-files/b-gcc-multilib/x86_64-unknown-linux-gnu/libstdc++-
> v3/src/.libs -Wl,-rpath 
> -Wl,/export/users/my-files/install-gcc-multilib/lib/../lib64
> -L/export/users/my-files/b-gcc-multilib/x86_64-unknown-linux-gnu/libstdc++-
> v3/src/.libs -L/export/users/my-files/b-gcc-multilib/x86_64-unknown-linux-
> gnu/libstdc++-v3/src -lpthread -ldl -L/export/users/my-files/b-gcc-
> multilib/x86_64-unknown-linux-gnu/32/libstdc++-v3/src -L/export/users/my-
> files/b-gcc-multilib/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs -
> L/export/users/my-files/b-gcc-multilib/./gcc/32 -L/lib/../lib 
> -L/usr/lib/../lib -
> L/export/users/my-files/b-gcc-multilib/./gcc /export/users/my-files/b-gcc-
> multilib/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so -lm -lc 
> -
> lgcc_s /export/users/my-files/b-gcc-multilib/./gcc/32/crtendS.o
> /usr/lib/../lib/crtn.o  -m32 -m32   -Wl,-soname -Wl,libcilkrts.so.5 -o
> .libs/libcilkrts.so.5.0.3511
> > /export/users/my-files/b-gcc-multilib/x86_64-unknown-linux-gnu/libstdc
> > ++-v3/src/.libs/libstdc++.so: could not read symbols: File in wrong
> > format
> > collect2: error: ld returned 1 exit status
> > make[4]: *** [libcilkrts.la] Error 1
> > make[4]: Leaving directory `/export/users/my-files/b-gcc-multilib/x86_64-
> unknown-linux-gnu/32/libcilkrts'
> > make[3]: *** [multi-do] Error 1
> > make[3]: Leaving directory `/export/users/my-files/b-gcc
> >
> >
> > From what it looks like, it is reading the 64 bit library for the 32 bit 
> > mode (or
> vice-versa). How do I fix this? I am also attaching my configure.ac and
> Makefile.am. Please note that it is not fully cleaned up (e.g. I have stuff
> commented out etc). Can someone please tell me what I am doing wrong?
> 
> When building the 32bit libcillkrts you are linking against the 64-bit
> libstdc++.  It's right there on your command line:
> /export/users/my-files/b-gcc-multilib/x86_64-unknown-linux-gnu/libstdc++-
> v3/src/.libs/libstdc++.so.
>  If that argument is needed at all, it needs to be 
> /export/users/my-files/b-gcc-
> multilib/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/libstdc++.so
> (note added /32 in there).  I guess the question is where the argument is 
> coming
> from.  I must admit that I don't know.  Is it in some environment variable?

I am not setting any environment variable that weren't set automatically in my 
SUSE machine. Also, all the other libs are working correctly for 32 and 64 bit.

> 
> Ian

Help with using multilib for Cilk Library

2013-07-19 Thread Iyer, Balaji V

Hello Everyone,
I am trying to use Multilib on Cilk Library. I looked at this website 
(http://www.airs.com/ian/configure/configure_8.html) and used libsanitizer and 
libgo as samples to model after. It is currently failing with the following 
error message:

libtool: link: /export/users/my-files/b-gcc-multilib/./gcc/xg++ 
-B/export/users/my-files/b-gcc-multilib/./gcc/ -nostdinc++ -nostdinc++ 
-I/export/users/my-files/b-gcc-multilib/x86_64-unknown-linux-gnu/32/libstdc++-v3/include/x86_64-unknown-linux-gnu
 
-I/export/users/my-files/b-gcc-multilib/x86_64-unknown-linux-gnu/32/libstdc++-v3/include
 -I/export/users/my-files/gcc/libstdc++-v3/libsupc++ 
-I/export/users/my-files/gcc/libstdc++-v3/include/backward 
-I/export/users/my-files/gcc/libstdc++-v3/testsuite/util 
-L/export/users/my-files/b-gcc-multilib/x86_64-unknown-linux-gnu/32/libstdc++-v3/src
 
-L/export/users/my-files/b-gcc-multilib/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs
 -B/export/users/my-files/install-gcc-multilib/x86_64-unknown-linux-gnu/bin/ 
-B/export/users/my-files/install-gcc-multilib/x86_64-unknown-linux-gnu/lib/ 
-isystem 
/export/users/my-files/install-gcc-multilib/x86_64-unknown-linux-gnu/include 
-isystem 
/export/users/my-files/install-gcc-multilib/x86_64-unknown-linux-gnu/sys-include
  -m32 -shared -nostdlib /usr/lib/../lib/crti.o 
/export/users/my-files/b-gcc-multilib/./gcc/32/crtbeginS.o  .libs/bug.o 
.libs/cilk-abi.o .libs/cilk-abi-cilk-for.o .libs/cilk-abi-vla.o 
.libs/cilk-abi-vla-internal.o .libs/cilk_api.o .libs/cilk_fiber.o 
.libs/cilk_fiber-unix.o .libs/cilk_malloc.o .libs/c_reducers.o 
.libs/except-gcc.o .libs/frame_malloc.o .libs/full_frame.o .libs/global_state.o 
.libs/jmpbuf.o .libs/local_state.o .libs/metacall_impl.o .libs/os_mutex-unix.o 
.libs/os-unix.o .libs/pedigrees.o .libs/record-replay.o .libs/reducer_impl.o 
.libs/scheduler.o .libs/signal_node.o .libs/spin_mutex.o .libs/stats.o 
.libs/symbol_test.o .libs/sysdep-unix.o .libs/worker_mutex.o   -Wl,-rpath 
-Wl,/export/users/my-files/b-gcc-multilib/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
 -Wl,-rpath -Wl,/export/users/my-files/install-gcc-multilib/lib/../lib64 
-L/export/users/my-files/b-gcc-multilib/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
 
-L/export/users/my-files/b-gcc-multilib/x86_64-unknown-linux-gnu/libstdc++-v3/src
 -lpthread -ldl 
-L/export/users/my-files/b-gcc-multilib/x86_64-unknown-linux-gnu/32/libstdc++-v3/src
 
-L/export/users/my-files/b-gcc-multilib/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs
 -L/export/users/my-files/b-gcc-multilib/./gcc/32 -L/lib/../lib 
-L/usr/lib/../lib -L/export/users/my-files/b-gcc-multilib/./gcc 
/export/users/my-files/b-gcc-multilib/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so
 -lm -lc -lgcc_s /export/users/my-files/b-gcc-multilib/./gcc/32/crtendS.o 
/usr/lib/../lib/crtn.o  -m32 -m32   -Wl,-soname -Wl,libcilkrts.so.5 -o 
.libs/libcilkrts.so.5.0.3511
/export/users/my-files/b-gcc-multilib/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so:
 could not read symbols: File in wrong format
collect2: error: ld returned 1 exit status
make[4]: *** [libcilkrts.la] Error 1
make[4]: Leaving directory 
`/export/users/my-files/b-gcc-multilib/x86_64-unknown-linux-gnu/32/libcilkrts'
make[3]: *** [multi-do] Error 1
make[3]: Leaving directory `/export/users/my-files/b-gcc


>From what it looks like, it is reading the 64 bit library for the 32 bit mode 
>(or vice-versa). How do I fix this? I am also attaching my configure.ac and 
>Makefile.am. Please note that it is not fully cleaned up (e.g. I have stuff 
>commented out etc). Can someone please tell me what I am doing wrong?

Any help is greatly appreciated!

Thanks,

Balaji V. Iyer.



configure.ac
Description: configure.ac


Makefile.am
Description: Makefile.am

GCC build error

2013-05-09 Thread Iyer, Balaji V

Hello Everyone,
I am currently trying to build the GCC trunk (revision 198747) and it 
is giving me the following error in make install for the java compiler. It 
looks like it is not able to find a function. 

Thanks,

Balaji V. Iyer.


libtool: link: /export/users/gcc-svn/b-trunk-gcc/./gcc/gcj 
-B/export/users/gcc-svn/b-trunk-gcc/x86_64-unknown-linux-gnu/32/libjava/ 
-B/export/users/gcc-svn/b-trunk-gcc/x86_64-unknown-linux-gnu/32/libjava/ 
-B/export/users/gcc-svn/b-trunk-gcc/./gcc/ 
-B/export/users/gcc-svn/install_dir/trunk-install/x86_64-unknown-linux-gnu/bin/ 
-B/export/users/gcc-svn/install_dir/trunk-install/x86_64-unknown-linux-gnu/lib/ 
-isystem 
/export/users/gcc-svn/install_dir/trunk-install/x86_64-unknown-linux-gnu/include
 -isystem 
/export/users/gcc-svn/install_dir/trunk-install/x86_64-unknown-linux-gnu/sys-include
 -m32 -ffloat-store -fomit-frame-pointer -Usun -g -O2 -m32 -m32 -o 
.libs/jv-convert --main=gnu.gcj.convert.Convert -shared-libgcc  
-L/export/users/gcc-svn/b-trunk-gcc/x86_64-unknown-linux-gnu/32/libjava/.libs 
-L/export/users/gcc-svn/b-trunk-gcc/x86_64-unknown-linux-gnu/32/libjava 
./.libs/libgcj.so -lpthread -ldl -lrt -Wl,-rpath 
-Wl,/export/users/gcc-svn/install_dir/trunk-install/lib/../lib
./.libs/libgcj.so: undefined reference to `__cxa_throw_bad_array_length'
collect2: error: ld returned 1 exit status
make[5]: *** [jv-convert] Error 1

RE: Fortran Compiler Hangs

2013-04-29 Thread Iyer, Balaji V


> -Original Message-
> From: Tobias Burnus [mailto:bur...@net-b.de]
> Sent: Monday, April 29, 2013 3:47 PM
> To: Iyer, Balaji V
> Cc: 'gcc@gcc.gnu.org'
> Subject: Re: Fortran Compiler Hangs
> 
> Hello Iyer,
> 
> Iyer, Balaji V wrote:
> > The fortran compiler  (f951) seem to hang even for a simple hello world
> program in GCC. This is causing the whole gcc build process to hang at the
> following line:
> >
> > checking for x86_64-unknown-linux-gnu-gfortran...
> > /export/users/gcc-svn/b-cilkplus-gcc/./gcc/gfortran
> 
> First question: Do you use the trunk or some branch? From your email, I'd
> assume that you use the trunk, but "b-cilkplus-gcc" rather implies that you 
> are
> using some branch.

Hi Tobias,
I found this issue when I updated my cilkplus branch with trunk. Then, 
I went to the same revision in the trunk and the same issue was there also.

> 
> 
> Looking at the backtrace, it seems as if your GMP (GNU Multiprecision 
> [integer]
> Library) and/or MPFR (multi-precision floating-point library) is not correctly
> working, e.g. you might use a different library version at run time than you
> compiled against. The problem could be either f951
> -> MPFR or MFPR -> GMP. Or it could be something different. In any case,
> the failure happens very early in the f951 when the some variables are 
> initialized
> - which is before the parser even has started.

I downloaded the MPFR, MPC and GMP libraries using 
./contrib/download_prerequisites script. I am still having the same issue. I 
tried simple programs on cc1 and cc1plus and it seem to work OK.

Thanks,

Balaji V. Iyer.

> 
> Tobias
> 
> > I tried a small hello world program and it was also hanging. I tried to gdb 
> > it and
> here is the backtrace. My current revision is at r198424. My previous revision
> was at r198143 and I believe things were working fine there.
> >
> > Here is the test program:
> >
> > PRINT *, 'Hello, world!'
> > END
> >
> > Here is the back trace:
> > (gdb) bt
> > #0  0x00ece7f1 in __gmpn_mul_1 ()
> > #1  0x00ed540b in __gmpn_mul_basecase ()
> > #2  0x00ed3c2f in __gmpn_kara_mul_n ()
> > #3  0x00ed40df in __gmpn_kara_mul_n ()
> > #4  0x00ed4bd5 in __gmpn_toom3_mul_n ()
> > #5  0x00ed52ac in __gmpn_mul_n ()
> > #6  0x00ed011f in __gmpn_mul ()
> > #7  0x00edd4e4 in __gmpn_toom22_mul ()
> > #8  0x00eded73 in __gmpn_toom32_mul ()
> > #9  0x00ed0080 in __gmpn_mul ()
> > #10 0x00ec9cd3 in __gmpz_mul ()
> > #11 0x00ea2fb1 in S ()
> > #12 0x00ea2f95 in S ()
> > #13 0x00ea2f6b in S ()
> > #14 0x00ea2f95 in S ()
> > #15 0x00ea2f6b in S ()
> > #16 0x00ea2f6b in S ()
> > #17 0x00ea2f95 in S ()
> > #18 0x00ea2f6b in S ()
> > #19 0x00ea2f6b in S ()
> > #20 0x00ea326b in mpfr_const_log2_internal ()
> > #21 0x00eb98af in mpfr_cache ()
> > #22 0x00ea36eb in mpfr_log ()
> > #23 0x00eb3165 in mpfr_log10 ()
> > #24 0x0051d2af in gfc_arith_init_1() ()
> > #25 0x00576463 in gfc_init_1() ()
> > #26 0x005c5bb3 in gfc_init() ()
> > #27 0x0097d8b7 in toplev_main(int, char**) ()
> > #28 0x77644bc6 in __libc_start_main () from /lib64/libc.so.6
> > #29 0x0051bb41 in _start () at
> > ../sysdeps/x86_64/elf/start.S:113

Fortran Compiler Hangs

2013-04-29 Thread Iyer, Balaji V

Hello Everyone,
The fortran compiler  (f951) seem to hang even for a simple hello world 
program in GCC. This is causing the whole gcc build process to hang at the 
following line:

checking for x86_64-unknown-linux-gnu-gfortran... 
/export/users/gcc-svn/b-cilkplus-gcc/./gcc/gfortran 
-B/export/users/gcc-svn/b-cilkplus-gcc/./gcc/ 
-B/export/users/gcc-svn/install_dir/cilkplus-install/x86_64-unknown-linux-gnu/bin/
 
-B/export/users/gcc-svn/install_dir/cilkplus-install/x86_64-unknown-linux-gnu/lib/
 -isystem 
/export/users/gcc-svn/install_dir/cilkplus-install/x86_64-unknown-linux-gnu/include
 -isystem 
/export/users/gcc-svn/install_dir/cilkplus-install/x86_64-unknown-linux-gnu/sys-include
checking whether we are using the GNU Fortran compiler...

I tried a small hello world program and it was also hanging. I tried to gdb it 
and here is the backtrace. My current revision is at r198424. My previous 
revision was at r198143 and I believe things were working fine there.

Here is the test program:

   PRINT *, 'Hello, world!'
   END

Here is the back trace:
(gdb) bt
#0  0x00ece7f1 in __gmpn_mul_1 ()
#1  0x00ed540b in __gmpn_mul_basecase ()
#2  0x00ed3c2f in __gmpn_kara_mul_n ()
#3  0x00ed40df in __gmpn_kara_mul_n ()
#4  0x00ed4bd5 in __gmpn_toom3_mul_n ()
#5  0x00ed52ac in __gmpn_mul_n ()
#6  0x00ed011f in __gmpn_mul ()
#7  0x00edd4e4 in __gmpn_toom22_mul ()
#8  0x00eded73 in __gmpn_toom32_mul ()
#9  0x00ed0080 in __gmpn_mul ()
#10 0x00ec9cd3 in __gmpz_mul ()
#11 0x00ea2fb1 in S ()
#12 0x00ea2f95 in S ()
#13 0x00ea2f6b in S ()
#14 0x00ea2f95 in S ()
#15 0x00ea2f6b in S ()
#16 0x00ea2f6b in S ()
#17 0x00ea2f95 in S ()
#18 0x00ea2f6b in S ()
#19 0x00ea2f6b in S ()
#20 0x00ea326b in mpfr_const_log2_internal ()
#21 0x00eb98af in mpfr_cache ()
#22 0x00ea36eb in mpfr_log ()
#23 0x00eb3165 in mpfr_log10 ()
#24 0x0051d2af in gfc_arith_init_1() ()
#25 0x00576463 in gfc_init_1() ()
#26 0x005c5bb3 in gfc_init() ()
#27 0x0097d8b7 in toplev_main(int, char**) ()
#28 0x77644bc6 in __libc_start_main () from /lib64/libc.so.6
#29 0x0051bb41 in _start () at ../sysdeps/x86_64/elf/start.S:113

Thanks,

Balaji V. Iyer.

Updating svn.html

2013-04-03 Thread Iyer, Balaji V

Hello Everyone, 
I would like to add the following information about my cilkplus branch 
under "Language-specific" in the SVN.html webpage. Do I send this as a patch or 
is there a specific person I should contact with the information? 

Here is the HTML code for what I want to add:

  cilkplus
  This branch is for the development of
  http://www.cilkplus.org";>Cilk Plus language extension support
  on GCC and G++ compilers.  This branch is maintained by
  mailto:balaji.v.i...@intel.com";>Balaji V. Iyer.  Patches to this
  branch must be prefixed with [cilkplus] in the subject line.  It
  is also highly encouraged to CC the maintainer (Balaji).


Thanks,

Balaji V. Iyer.

RE: GIt Issue

2013-03-26 Thread Iyer, Balaji V



> -Original Message-
> From: Markus Trippelsdorf [mailto:mar...@trippelsdorf.de]
> Sent: Tuesday, March 26, 2013 3:16 PM
> To: Iyer, Balaji V
> Cc: 'gcc@gcc.gnu.org'; Jason Merrill (ja...@redhat.com)
> Subject: Re: GIt Issue
> 
> On 2013.03.26 at 18:28 +, Iyer, Balaji V wrote:
> > Hello everyone,
> > I am trying to clone a git repository and I am getting the following 
> > error.
> Can someone please tell me what this error could be and how I could fix this? 
> It
> worked for me a while back but not now.
> >
> > I tried the following command:
> > git clone http://gcc.gnu.org/git/gcc.git gcc.git
> >
> >
> > This is the output I got:
> >
> > Initialized empty Git repository in /export/users/gcc.git/.git/
> > error: The requested URL returned error: 503 (curl_result = 22,
> > http_code = 503, sha1 = 948da40c5008d4d7c2f8020f4e0ebddfc144350d)
> > error: Unable to find 52979cfc138789a17ec692b59dd239566b055e94 under
> > http://gcc.gnu.org/git/gcc.git Cannot obtain needed tree
> > 52979cfc138789a17ec692b59dd239566b055e94
> > while processing commit caacf4a76941db5eb611e9350da17f05447316a6.
> > error: Fetch failed.
> 
> Please try the git protocol instead of http:
>  git clone git://gcc.gnu.org/git/gcc.git gcc.git

Thanks for your help Markus. Unfortunately, http is the only option for me. 

Thanks,

Balaji V. Iyer.
> 
> --
> Markus

GIt Issue

2013-03-26 Thread Iyer, Balaji V

Hello everyone,
I am trying to clone a git repository and I am getting the following 
error. Can someone please tell me what this error could be and how I could fix 
this? It worked for me a while back but not now.

I tried the following command:
git clone http://gcc.gnu.org/git/gcc.git gcc.git


This is the output I got:

Initialized empty Git repository in /export/users/gcc.git/.git/
error: The requested URL returned error: 503 (curl_result = 22, http_code = 
503, sha1 = 948da40c5008d4d7c2f8020f4e0ebddfc144350d)
error: Unable to find 52979cfc138789a17ec692b59dd239566b055e94 under 
http://gcc.gnu.org/git/gcc.git
Cannot obtain needed tree 52979cfc138789a17ec692b59dd239566b055e94
while processing commit caacf4a76941db5eb611e9350da17f05447316a6.
error: Fetch failed.

Thanks,

Balaji V. Iyer.

RE: Build error in genconstants.c

2013-01-08 Thread Iyer, Balaji V

Hi Marc,
Please see my response below.

> -Original Message-
> From: Marc Glisse [mailto:marc.gli...@inria.fr]
> Sent: Tuesday, January 08, 2013 6:20 PM
> To: Iyer, Balaji V
> Cc: 'gcc@gcc.gnu.org'
> Subject: RE: Build error in genconstants.c
> 
> On Tue, 8 Jan 2013, Iyer, Balaji V wrote:
> 
> > Thanks for your response. I looked at config.log and I got the
> > following information about sbrk. This error only occurs when I type
> > "make." If I reconfigured the build directory and typed "make -j8" (or
> > whatever the number of cores I have on my machine) it seem to build
> > fine.
> 
> A race condition? Or the first make created stuff that the second try picked 
> up?

Yes, it sure does look like it. If I do -j1 it still gives the same error. I am 
assuming (and I could be completely wrong here) that by the time autoconf gets 
to a certain test, another process already build the gmp and thus pass the test.

> 
> > configure:10333: checking whether sbrk is declared
> > | #ifndef sbrk
> > | char *(*pfn) = (char *(*)) sbrk ;
> 
> The result of grep is not so useful, what's nearby would help more. You should
> probably file a bug report and include the whole gcc/config.log file.
> 
> (H.J. Lu noticed another gmp.h issue, but that's only for in-tree gmp and you
> seem to have an external one)

Yes, he send out a patch and that seem to have fixed the problem.

> 
> --
> Marc Glisse

Thanks for your advice and help!

-Balaji V. Iyer.

RE: Build error in genconstants.c

2013-01-08 Thread Iyer, Balaji V

 for 'sbrk'
 extern void *sbrk (int);
/usr/include/unistd.h:1046:14: note: previous declaration of 'sbrk' was here  
extern void *sbrk (intptr_t __delta) __THROW;
../../trunk-gcc/gcc/system.h:446:14: error: conflicting types for 'sbrk'
 extern void *sbrk (int);
/usr/include/unistd.h:1046:14: note: previous declaration of 'sbrk' was here  
extern void *sbrk (intptr_t __delta) __THROW;
../../trunk-gcc/gcc/system.h:446:14: error: conflicting types for 'sbrk'
 extern void *sbrk (int);
/usr/include/unistd.h:1046:14: note: previous declaration of 'sbrk' was here  
extern void *sbrk (intptr_t __delta) __THROW;
../../trunk-gcc/gcc/system.h:446:14: error: conflicting types for 'sbrk'
 extern void *sbrk (int);
/usr/include/unistd.h:1046:14: note: previous declaration of 'sbrk' was here  
extern void *sbrk (intptr_t __delta) __THROW;
../../trunk-gcc/gcc/system.h:446:14: error: conflicting types for 'sbrk'
 extern void *sbrk (int);
/usr/include/unistd.h:1046:14: note: previous declaration of 'sbrk' was here  
extern void *sbrk (intptr_t __delta) __THROW;
../../trunk-gcc/gcc/system.h:446:14: error: conflicting types for 'sbrk'
 extern void *sbrk (int);
/usr/include/unistd.h:1046:14: note: previous declaration of 'sbrk' was here  
extern void *sbrk (intptr_t __delta) __THROW;
../../trunk-gcc/gcc/system.h:446:14: error: conflicting types for 'sbrk'
 extern void *sbrk (int);
/usr/include/unistd.h:1046:14: note: previous declaration of 'sbrk' was here  
extern void *sbrk (intptr_t __delta) __THROW; 
gcc_cv_have_decl_sbrk=no



-Balaji V. Iyer.


> -Original Message-
> From: Marc Glisse [mailto:marc.gli...@inria.fr]
> Sent: Tuesday, January 08, 2013 1:31 AM
> To: Iyer, Balaji V
> Cc: 'gcc@gcc.gnu.org'
> Subject: Re: Build error in genconstants.c
> 
> On Tue, 8 Jan 2013, Iyer, Balaji V wrote:
> 
> > Hello Everyone,
> > I am getting the following error when I tried to build the trunk 
> > (revision
> 194999) on my SuSE machine (Linux 2.6.32.29-0.3-default x86_64).  I just did 
> the
> standard configure (../src_directory/configure --prefix=<>). It looks like 
> some
> syscall functions on my machine seem to not like the system.h that is 
> available
> with GCC.
> >
> > Is there anything I can do to fix this? Any help is greatly appreciated!
> 
> This looks like
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55784
> 
> which was supposedly fixed by the use of $GMPINC, but your revision is recent
> enough to have the fix, so something is still wrong.
> 
> Maybe look through config.log for the corresponding test?
> 
> --
> Marc Glisse

Build error in genconstants.c

2013-01-07 Thread Iyer, Balaji V

Hello Everyone, 
I am getting the following error when I tried to build the trunk 
(revision 194999) on my SuSE machine (Linux 2.6.32.29-0.3-default x86_64).  I 
just did the standard configure (../src_directory/configure --prefix=<>). It 
looks like some syscall functions on my machine seem to not like the system.h 
that is available with GCC. 

Is there anything I can do to fix this? Any help is greatly appreciated!

Thanks,

Balaji V. Iyer.


make[3]: Leaving directory `/export/users/gcc-svn/b-trunk-gcc/libdecnumber'
make[3]: Entering directory `/export/users/gcc-svn/b-trunk-gcc/gcc'
g++ -c   -g -DIN_GCC   -fno-exceptions -fno-rtti -fasynchronous-unwind-tables 
-W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic 
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common  
-DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../trunk-gcc/gcc 
-I../../trunk-gcc/gcc/build -I../../trunk-gcc/gcc/../include 
-I../../trunk-gcc/gcc/../libcpp/include 
-I/export/users/gcc-svn/b-trunk-gcc/./gmp -I/export/users/gcc-svn/trunk-gcc/gmp 
-I/export/users/gcc-svn/b-trunk-gcc/./mpfr 
-I/export/users/gcc-svn/trunk-gcc/mpfr 
-I/export/users/gcc-svn/trunk-gcc/mpc/src  
-I../../trunk-gcc/gcc/../libdecnumber -I../../trunk-gcc/gcc/../libdecnumber/bid 
-I../libdecnumber -I../../trunk-gcc/gcc/../libbacktrace\
-o build/genconstants.o ../../trunk-gcc/gcc/genconstants.c
In file included from /usr/include/sys/resource.h:25,
 from /usr/include/sys/wait.h:32,
 from ../../trunk-gcc/gcc/system.h:354,
 from ../../trunk-gcc/gcc/genconstants.c:29:
/usr/include/bits/resource.h:127: error: declaration does not declare anything
In file included from ../../trunk-gcc/gcc/genconstants.c:29:
../../trunk-gcc/gcc/system.h:446: error: declaration of C function âvoid* 
sbrk(int)â conflicts with
/usr/include/unistd.h:1046: error: previous declaration âvoid* sbrk(intptr_t)â 
here
In file included from ../../trunk-gcc/gcc/genconstants.c:29:
../../trunk-gcc/gcc/system.h:502: error: declaration of C function âconst char* 
strsignal(int)â conflicts with
/usr/include/string.h:564: error: previous declaration âchar* strsignal(int)â 
here
make[3]: *** [build/genconstants.o] Error 1
make[3]: Leaving directory `/export/users/gcc-svn/b-trunk-gcc/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/export/users/gcc-svn/b-trunk-gcc'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/export/users/gcc-svn/b-trunk-gcc'
make: *** [all] Error 2

RE: Internal Compiler Error

2012-12-27 Thread Iyer, Balaji V

The best way to handle this issue is to submit a bugzilla bug-request with a 
small test case that will replicate the internal error.

Thanks,

Balaji V. Iyer.

> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> tanle
> Sent: Monday, December 24, 2012 11:44 AM
> To: gcc@gcc.gnu.org; gcc-h...@gcc.gnu.org
> Subject: Internal Compiler Error
> 
> Could you explain for you about "Internal Compiler Error"?
> I am building the Linux kernel for microbalze (Atlys Board), there are some 
> errors
> as:
> fs/ext2/super.c: In function 'ext2_fill_super':
> fs/ext2/super.c:1144:1: internal compiler error: in reload, at
> reload1.c:1059
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> make[2]: *** [fs/ext2/super.o] Error 1
> make[1]: *** [fs/ext2] Error 2
> make: *** [fs] Error 2
> I use gcc version 4.6.1
> 
> Best Regards
> TanLe

Line number information

2012-10-16 Thread Iyer, Balaji V

Hello Everyone,
I am trying to debug the trunk cc1 (revision 192483) and it is not 
finding the line number information.   I am using GDB 7.5. My OS is SuSE (not  
sure if that matters). Is everyone else having this issue?

Thanks,

Balaji V. Iyer.

Error reporting functions

2012-10-04 Thread Iyer, Balaji V

Hi Everyone,
This question is mainly for some future submission. Am I allowed to use 
"fatal_error (..)"? Mainly, I want to use it in cases where I want to say "if 
this error has occurred, I see no reason to go forward with compilation."

Thanks,

Balaji V. Iyer.

RE: --with-gmp, --with-mpfr and/or --with-mpc

2012-09-22 Thread Iyer, Balaji V



>-Original Message-
>From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
>Gabriel Dos Reis
>Sent: Saturday, September 22, 2012 7:59 PM
>To: Bruce Korb
>Cc: gcc-h...@gcc.gnu.org; GCC
>Subject: Re: --with-gmp, --with-mpfr and/or --with-mpc
>
>On Sat, Sep 22, 2012 at 5:58 PM, Bruce Korb  wrote:
>> On 09/22/12 15:02, Gabriel Dos Reis wrote:
>>> On Sat, Sep 22, 2012 at 4:36 PM, Marc Glisse  wrote:
 Are you looking for gcc-h...@gcc.gnu.org?
>>>
 mpc-devel ? (not my platform, I don't even know if that package
 exists, but your grep pattern excludes such a package)
>>>
>>> yes, it is "mpc-devel" on suse.
>>>
>>> one needs the "-devel" packages of all the requirements.
>>
>>> $ rpm -q -a|egrep -i 'libmpc|gmp|mpfr'
>>> ...
>>> mpfr-devel-3.1.0-2.1.3.x86_64  <<<
>>> ...
>>> libmpc2-0.8.2-15.1.3.x86_64<<<
>>> ...
>>> gmp-devel-5.0.5-3.3.3.x86_64   <<<
>>> ...
>>
>> and I find no libmpc.*devel package either.
>
>On suse, I always use Yast (or Yast2 for the graphical
>interface) to install packages.
>
>* Start Yast
>* Select "Software", then "Software Management" tab
>* Enter mpc-devel in the box titled "Search Phrase"; hit Enter
>* You should see mpc-devel as part of the result; select it
>   and accept;
>* that should be all.
>
>The version of MPC that comes with opensuse 12.2 is 0.8.2 and should be good.

Another option [that I use] would be to run ./contrib/download_prequisities in 
your top-level directory. It will automatically download things and put 
symbolic links.

Thanks,

Balaji V. Iyer.

>
>Hope that helps,
>
>-- Gaby

RE: Merging Cilk Plus into GCC Trunk

2012-09-05 Thread Iyer, Balaji V

Hello Joseph,
Please see my response below.

Thanks,

Balaji V. Iyer.

>-Original Message-
>From: Joseph Myers [mailto:jos...@codesourcery.com]
>Sent: Wednesday, September 05, 2012 3:00 PM
>To: Iyer, Balaji V
>Cc: Aldy Hernandez; 'gcc@gcc.gnu.org'; Jeff Law; r...@redhat.com
>Subject: RE: Merging Cilk Plus into GCC Trunk
>
>On Wed, 5 Sep 2012, Iyer, Balaji V wrote:
>
>>  If this is OK with everyone, I will start sending patches to
>> gcc-patches mailing list soon.
>
>Regarding the patch ordering you list, note that earlier patches may not be
>reviewable without later ones (specifically, code changes can only be reviewed
>given documentation and testcases - in some cases documentation might be
>external, but it does need to be pointed to from the GCC manuals in that case,
>and it does need to make interactions with existing language features precise 
>at
>the level of standards text).

I will try to send the test case patch and the code-changes patches back to 
back. Regarding documentation, I am planning to include a link to the 
documentation for Cilk Plus in the patches email.

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

RE: Merging Cilk Plus into GCC Trunk

2012-09-05 Thread Iyer, Balaji V

Hello Aldy,
Thank you for responding. Please see my answers to your questions 
embedded below. 


If this is OK with everyone, I will start sending patches to 
gcc-patches mailing list soon.

Thanks,

Balaji V. Iyer.

>-Original Message-
>From: Aldy Hernandez [mailto:al...@redhat.com]
>Sent: Tuesday, September 04, 2012 6:24 PM
>To: Iyer, Balaji V
>Cc: 'gcc@gcc.gnu.org'; Jeff Law; r...@redhat.com
>Subject: Re: Merging Cilk Plus into GCC Trunk
>
>On 08/30/12 15:39, Iyer, Balaji V wrote:
>> Hello Everyone,
>>  The Cilk-Plus branch is feature-complete. Programs using Cilk Plus
>constructs get great performance on vector and multicore hardware. Programs
>that don't use the new language features (enabled by a -fcilkplus flag) see no
>change. For details please see http://cilkplus.org.
>>  It's time to promote the branch into mainline. Cilk Plus branch is 
>> stable
>and there is no unexpected failures with respect to the trunk in regression
>testsuites. Most of the changes are in the front and middle-end. Since it 
>involves
>many changes, I plan to break it up into individual patches (listed below), 
>each of
>which adds a new, complete capability. Later patches sometimes use the
>functionality added by the previous one. For example, Elemental functions for
>C++ will depend on some of the common routines used in C patch:
>
>Hi Iyer.
>
>Thank you for all your work on this.
>
>Perhaps it is of interest to note (IIRC), that the language extensions have 
>been
>proposed for inclusion in the next OpenMP version??

Cilk Plus has been proposed for inclusion in the next C++ standard.

>
>I can't speak for the rest of the community, but I think items 1-12 are useful 
>for
>GCC  (elemental functions, SIMD annotations, and array notations for C/C++),
>regardless of any language extensions.  Perhaps you could provide examples on
>these as a start?
>
I was planning to provide an example for elemental function, array notations 
and SIMD annotations with each patch. Is that good enough?

>
>Regarding the SIMD annotations, I find the "vector" attribute somewhat
>ambiguous, or prone to confusing users, so perhaps we could come up with a
>better name?

The keyword "vector" is used by the Intel Compiler and we would like them both 
to be compatible. Jakub at Cauldron did mention that vector keyword is used in 
Power PC and thus can potentially cause some interference. I configured the 
Cilk Plus branch for Power PC and I compiled both elemental functions and 
PowerPC programs that use the vector keyword. They both seem to work correctly.

>
>Over all, I don't see why this can't be included as an experimental feature 
>like
>OpenMP, transactional memory, etc, especially if it's relatively self 
>contained and
>doesn't affected the non cilkplus code path too much.
>
>Anyone have further thoughts on this, especially global maintainers :)?
>Aldy
>
>>
>> 1. Elemental functions for C.
>> 2. Regression tests for elemental functions for C.
>> 3. Elemental functions for C++.
>> 4. Regression tests for elemental functions for C++.
>> 5. SIMD annotations for C.
>> 6. Regression tests for SIMD annotations for C.
>> 7. SIMD annotations for C++.
>> 8. Regression tests for SIMD annotations for C++.
>> 9. Array notations for C.
>> 10. Regression tests for Array notations for C.
>> 11. Array Notations for C++.
>> 12. Regression tests for Array Notations for C++.
>> 13. The Cilk Runtime library -- It is a separate directory without any 
>> changes to
>compiler source.
>> 14. Cilk Keywords (_Cilk_spawn and _Cilk_sync) for C.
>> 15. Regression tests _Cilk_spawn and _Cilk_sync for C.
>> 16. Cilk Keywords (_Cilk_spawn and _Cilk_sync) for C++.
>> 17. Regression tests _Cilk_spawn and _Cilk_sync for C++.
>> 18. Cilk Keywords (_Cilk_for) for C.
>> 19. _Cilk_for Regression tests for C.
>> 20. Cilk Keywords (_Cilk_for) for C++.
>> 21. _Cilk_for Regression tests for C++.
>> 22. Documentation about Cilk Plus into GCC documents.
>>
>> If there is a more effective way to merge our changes to the trunk, I am open
>to suggestions.
>>
>> Thanking You,
>>
>> Yours Sincerely,
>>
>> Balaji V. Iyer.
>>

RE: Trunk Build errors

2012-09-04 Thread Iyer, Balaji V

Yes, I downloaded a GCC 4.6.3 and it seem to go well thus far.

Thanks,

Balaji V. Iyer.

>-Original Message-
>From: Diego Novillo [mailto:dnovi...@google.com]
>Sent: Tuesday, September 04, 2012 12:03 PM
>To: Iyer, Balaji V
>Cc: gcc@gcc.gnu.org
>Subject: Re: Trunk Build errors
>
>On Tue, Sep 4, 2012 at 10:12 AM, Iyer, Balaji V  
>wrote:
>> Hello Everyone,
>> I am getting the following error when I am trying to build the trunk 
>> on
>x86_64 SuSE Linux. My SVN head is at revision 190930.  Is anyone else finding
>this?
>
>It's happening with a g++ 4.3 host compiler, right?  I'm on it.  The
>gcc17 host in the FSF cluster has g++ 4.3.  Fix coming up.
>
>
>Diego.

Trunk Build errors

2012-09-04 Thread Iyer, Balaji V

Hello Everyone, 
I am getting the following error when I am trying to build the trunk on 
x86_64 SuSE Linux. My SVN head is at revision 190930.  Is anyone else finding 
this?

Thanks,

Balaji V. Iyer.

==
g++ -c   -g -DIN_GCC   -fno-exceptions -fno-rtti -W -Wall -Wwrite-strings 
-Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long 
-Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H 
-DGENERATOR_FILE -I. -Ibuild -I../../trunk-gcc-untouched/gcc 
-I../../trunk-gcc-untouched/gcc/build 
-I../../trunk-gcc-untouched/gcc/../include 
-I../../trunk-gcc-untouched/gcc/../libcpp/include 
-I/export/users/GCC_Trunk_Development/b-trunk-gcc-untounched/./gmp 
-I/export/users/GCC_Trunk_Development/trunk-gcc-untouched/gmp 
-I/export/users/GCC_Trunk_Development/b-trunk-gcc-untounched/./mpfr 
-I/export/users/GCC_Trunk_Development/trunk-gcc-untouched/mpfr 
-I/export/users/GCC_Trunk_Development/trunk-gcc-untouched/mpc/src  
-I../../trunk-gcc-untouched/gcc/../libdecnumber 
-I../../trunk-gcc-untouched/gcc/../libdecnumber/bid -I../libdecnumber\
-o build/read-rtl.o ../../trunk-gcc-untouched/gcc/read-rtl.c
../../trunk-gcc-untouched/gcc/vec.h: In static member function âstatic T& 
vec_t::safe_push(vec_t**, T, const char*, unsigned int, const char*) 
[with vec_allocation_t A = heap, T = mapping*]â:
../../trunk-gcc-untouched/gcc/read-rtl.c:395:   instantiated from here
../../trunk-gcc-untouched/gcc/vec.h:845: warning: left-hand operand of comma 
has no effect
../../trunk-gcc-untouched/gcc/vec.h:845: warning: right-hand operand of comma 
has no effect
../../trunk-gcc-untouched/gcc/vec.h:845: warning: right-hand operand of comma 
has no effect
../../trunk-gcc-untouched/gcc/vec.h:845: warning: right-hand operand of comma 
has no effect
../../trunk-gcc-untouched/gcc/vec.h:845: error: no match for âoperator<â in 
âvec_t::reserve [with vec_allocation_t A = A, T = mapping*] < heapâ
../../trunk-gcc-untouched/gcc/vec.h: In static member function âstatic T* 
vec_t::safe_push(vec_t**, const T*, const char*, unsigned int, const 
char*) [with vec_allocation_t A = heap, T = iterator_use]â:
../../trunk-gcc-untouched/gcc/read-rtl.c:689:   instantiated from here
../../trunk-gcc-untouched/gcc/vec.h:860: warning: left-hand operand of comma 
has no effect
../../trunk-gcc-untouched/gcc/vec.h:860: warning: right-hand operand of comma 
has no effect
../../trunk-gcc-untouched/gcc/vec.h:860: warning: right-hand operand of comma 
has no effect
../../trunk-gcc-untouched/gcc/vec.h:860: warning: right-hand operand of comma 
has no effect
../../trunk-gcc-untouched/gcc/vec.h:860: error: no match for âoperator<â in 
âvec_t::reserve [with vec_allocation_t A = A, T = iterator_use] < heapâ
../../trunk-gcc-untouched/gcc/vec.h: In static member function âstatic T* 
vec_t::safe_push(vec_t**, const T*, const char*, unsigned int, const 
char*) [with vec_allocation_t A = heap, T = attribute_use]â:
../../trunk-gcc-untouched/gcc/read-rtl.c:703:   instantiated from here
../../trunk-gcc-untouched/gcc/vec.h:860: warning: left-hand operand of comma 
has no effect
../../trunk-gcc-untouched/gcc/vec.h:860: warning: right-hand operand of comma 
has no effect
../../trunk-gcc-untouched/gcc/vec.h:860: warning: right-hand operand of comma 
has no effect
../../trunk-gcc-untouched/gcc/vec.h:860: warning: right-hand operand of comma 
has no effect
../../trunk-gcc-untouched/gcc/vec.h:860: error: no match for âoperator<â in 
âvec_t::reserve [with vec_allocation_t A = A, T = attribute_use] < heapâ
make[3]: *** [build/read-rtl.o] Error 1
make[3]: Leaving directory 
`/export/users/GCC_Trunk_Development/b-trunk-gcc-untounched/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory 
`/export/users/GCC_Trunk_Development/b-trunk-gcc-untounched'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory 
`/export/users/GCC_Trunk_Development/b-trunk-gcc-untounched'

===

Merging Cilk Plus into GCC Trunk

2012-08-30 Thread Iyer, Balaji V

Hello Everyone,
The Cilk-Plus branch is feature-complete. Programs using Cilk Plus 
constructs get great performance on vector and multicore hardware. Programs 
that don't use the new language features (enabled by a -fcilkplus flag) see no 
change. For details please see http://cilkplus.org.
It's time to promote the branch into mainline. Cilk Plus branch is 
stable and there is no unexpected failures with respect to the trunk in 
regression testsuites. Most of the changes are in the front and middle-end. 
Since it involves many changes, I plan to break it up into individual patches 
(listed below), each of which adds a new, complete capability. Later patches 
sometimes use the functionality added by the previous one. For example, 
Elemental functions for C++ will depend on some of the common routines used in 
C patch:

1. Elemental functions for C.
2. Regression tests for elemental functions for C.
3. Elemental functions for C++.
4. Regression tests for elemental functions for C++. 
5. SIMD annotations for C.
6. Regression tests for SIMD annotations for C.
7. SIMD annotations for C++.
8. Regression tests for SIMD annotations for C++. 
9. Array notations for C.
10. Regression tests for Array notations for C.
11. Array Notations for C++.
12. Regression tests for Array Notations for C++. 
13. The Cilk Runtime library -- It is a separate directory without any changes 
to compiler source.
14. Cilk Keywords (_Cilk_spawn and _Cilk_sync) for C.
15. Regression tests _Cilk_spawn and _Cilk_sync for C.
16. Cilk Keywords (_Cilk_spawn and _Cilk_sync) for C++.
17. Regression tests _Cilk_spawn and _Cilk_sync for C++. 
18. Cilk Keywords (_Cilk_for) for C.
19. _Cilk_for Regression tests for C.
20. Cilk Keywords (_Cilk_for) for C++.
21. _Cilk_for Regression tests for C++.
22. Documentation about Cilk Plus into GCC documents.

If there is a more effective way to merge our changes to the trunk, I am open 
to suggestions.

Thanking You,

Yours Sincerely,

Balaji V. Iyer.

RE: GDB issues on Trunk

2012-08-25 Thread Iyer, Balaji V



>-Original Message-
>From: Andrew Pinski [mailto:pins...@gmail.com]
>Sent: Saturday, August 25, 2012 1:31 PM
>To: Iyer, Balaji V
>Cc: gcc@gcc.gnu.org
>Subject: Re: GDB issues on Trunk
>
>On Sat, Aug 25, 2012 at 10:28 AM, Iyer, Balaji V  
>wrote:
>> Hello Everyone,
>> I am trying to debug "cc1" through gdb but is not working as it was 
>> before
>(my current revision is 190623) . For example, when I try to print out any 
>local
>variable when I am inside the function, it says the variable is not in in the 
>context.
>Here is an example below:
>
>What version of gdb are you using?  IIRC for the trunk at least GDB
>7.5 is required now to debug code generated from it as we produce some
>dwarf4 that only 7.5 and above understands.

Yes, upgrading to gdb 7.5 seem to have fixed the problem! I was using 7.4.1 and 
7.2 in my machines.

Thanks,

Balaji V. Iyer.


>
>Thanks,
>Andrew
>
>>
>> e.g.
>>
>> Single stepping until exit from function _ZL14tree_vectorizev, which
>> has no line number information.
>> vectorize_loops() () at ../../trunk-gcc/gcc/tree-vectorizer.c:168
>> 168   unsigned int num_vectorized_loops = 0;
>> (gdb) n
>> 173   vect_loops_num = number_of_loops ();
>> (gdb) p num_vectorized_loops
>> No symbol "num_vectorized_loops" in current context.
>>
>>
>> Another wierd thing I noticed is that "Breakpoint 1 and Breakpoint 2" 
>> generally
>point to 2 lines in diagnostic.c (I believe they are fancy_abort and 
>internal_error)
>but now it is just giving addresses. Also, when I start something, it says it 
>can't
>find line number information:
>>
>> Can someone please tell me how I can to fix these?
>>
>> Any help is greatly appreciated!
>>
>> Thanks,
>>
>> Balaji V. Iyer.
>>
>> PS. Please CC me when responding.

GDB issues on Trunk

2012-08-25 Thread Iyer, Balaji V

Hello Everyone,
I am trying to debug "cc1" through gdb but is not working as it was 
before (my current revision is 190623) . For example, when I try to print out 
any local variable when I am inside the function, it says the variable is not 
in in the context. Here is an example below:

e.g.

Single stepping until exit from function _ZL14tree_vectorizev,
which has no line number information.
vectorize_loops() () at ../../trunk-gcc/gcc/tree-vectorizer.c:168
168   unsigned int num_vectorized_loops = 0;
(gdb) n
173   vect_loops_num = number_of_loops ();
(gdb) p num_vectorized_loops
No symbol "num_vectorized_loops" in current context.


Another wierd thing I noticed is that "Breakpoint 1 and Breakpoint 2" generally 
point to 2 lines in diagnostic.c (I believe they are fancy_abort and 
internal_error) but now it is just giving addresses. Also, when I start 
something, it says it can't find line number information:

Can someone please tell me how I can to fix these? 

Any help is greatly appreciated!

Thanks,

Balaji V. Iyer.

PS. Please CC me when responding.

RE: Compilation error between SVN trunk revision 190444 and 190442

2012-08-18 Thread Iyer, Balaji V

>-Original Message-
>From: Gerald Pfeifer [mailto:ger...@pfeifer.com]
>Sent: Saturday, August 18, 2012 7:16 PM
>To: Iyer, Balaji V
>Cc: gcc@gcc.gnu.org; Diego Novillo
>Subject: Re: Compilation error between SVN trunk revision 190444 and 190442
>
>On Thu, 16 Aug 2012, Iyer, Balaji V wrote:
>>  When my HEAD is at (svn+ssh://gcc.gnu.org/svn/gcc/trunk@190444
>> 138bc75d-0d04-0410-961f-82ee72b054a4) I get the following error
>> (please see it pasted below). When I revert to 1 commit before that,
>> the problem seem to go away... Is it something to do with the GMP
>> version I am using? Mine is a couple months older.
>
>I had the same at about the same time, but do not see this any more; I believe 
>it's
>fixed by
>
>  2012-08-16   Diego Novillo  
>
>Revert
>
>PR bootstrap/54281
>* double-int.h: Move including of gmp.h ...
>* system.h: ... here.
>* realmpfr.h: Do not include gmp.h.
>* tree-ssa-loop-niter.c: Do not include gmp.h.

Yes, Mine seem to be working too!

Thanks,

Balaji V. Iyer.


>
>Gerald

Question about Dejagnu C++ Execution Test

2012-08-17 Thread Iyer, Balaji V

Hello Everyone
I have a question regarding a DejaGNU execution tests for C++. For C I 
used several C-torture routines (e.g. c-torture-execute) to add execution tests 
into the testsuite. I am not able to find a similar set of routine to use in 
C++. Can someone please point me if similar functions exists for C++? Also, any 
advice/pointers on how to write one would be great also.  

Any help on this topic is greatly appreciated!

Thanks,

Balaji V. Iyer.

PS. Please CC when responding to this message.

Compilation error between SVN trunk revision 190444 and 190442

2012-08-16 Thread Iyer, Balaji V

Hello Everyone,
When my HEAD is at (svn+ssh://gcc.gnu.org/svn/gcc/trunk@190444 
138bc75d-0d04-0410-961f-82ee72b054a4) I get the following error (please see it 
pasted below). When I revert to 1 commit before that, the problem seem to go 
away... Is it something to do with the GMP version I am using? Mine is a couple 
months older. 

Also, I am using a x86_64 machine with SUSE Linux Enterprise Server 11 
(x86_64).
Thanks,

Balaji V. Iyer.

PS. Please CC me when responding to this message.
 
===
HEADERS="auto-host.h ansidecl.h" DEFINES="" \
/bin/sh ../../trunk-gcc-untouched/gcc/mkconfig.sh bconfig.h
g++ -c   -g -DIN_GCC   -fno-exceptions -fno-rtti -W -Wall -Wwrite-strings 
-Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long 
-Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H 
-DGENERATOR_FILE -I. -Ibuild -I../../trunk-gcc-untouched/gcc 
-I../../trunk-gcc-untouched/gcc/build 
-I../../trunk-gcc-untouched/gcc/../include 
-I../../trunk-gcc-untouched/gcc/../libcpp/include 
-I/export/users/gcc-trunk/b-trunk-gcc-untouched/./gmp 
-I/export/users/gcc-trunk/trunk-gcc-untouched/gmp 
-I/export/users/gcc-trunk/b-trunk-gcc-untouched/./mpfr 
-I/export/users/gcc-trunk/trunk-gcc-untouched/mpfr 
-I/export/users/gcc-trunk/trunk-gcc-untouched/mpc/src  
-I../../trunk-gcc-untouched/gcc/../libdecnumber 
-I../../trunk-gcc-untouched/gcc/../libdecnumber/bid -I../libdecnumber\
-o build/genconstants.o 
../../trunk-gcc-untouched/gcc/genconstants.c
In file included from /usr/include/sys/resource.h:25,
 from /usr/include/sys/wait.h:32,
 from ../../trunk-gcc-untouched/gcc/system.h:351,
 from ../../trunk-gcc-untouched/gcc/genconstants.c:29:
/usr/include/bits/resource.h:127: error: declaration does not declare anything
In file included from ../../trunk-gcc-untouched/gcc/genconstants.c:29:
../../trunk-gcc-untouched/gcc/system.h:443: error: declaration of C function 
âvoid* sbrk(int)â conflicts with
/usr/include/unistd.h:1046: error: previous declaration âvoid* sbrk(intptr_t)â 
here
In file included from ../../trunk-gcc-untouched/gcc/genconstants.c:29:
../../trunk-gcc-untouched/gcc/system.h:499: error: declaration of C function 
âconst char* strsignal(int)â conflicts with
/usr/include/string.h:564: error: previous declaration âchar* strsignal(int)â 
here
make[3]: *** [build/genconstants.o] Error 1
make[3]: Leaving directory `/export/users/gcc-trunk/b-trunk-gcc-untouched/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/export/users/gcc-trunk/b-trunk-gcc-untouched'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/export/users/gcc-trunk/b-trunk-gcc-untouched'
make: *** [all] Error 2
===

Setting LD_LIBRARY_PATH in gcc testsuite

2012-08-12 Thread Iyer, Balaji V

Hello Everyone,
I would like to add some tests into the testsuite of GCC that depend on a 
library for execution. Is it possible for me to set the ld_library_path to 
point to the library's location? The shared object is stored in  
$build_dir/i686-pc-linux-gnu/libcilkrts -OR- $install_dir/lib. 

Any help is greatly appreciated!

Thanks,

Balaji V. Iyer.

RE: build6_stat removed?

2012-07-27 Thread Iyer, Balaji V

I think I am ok without it.  I did find a workaround.

Thanks,

Balaji V. Iyer.

-Original Message-
From: Eric Botcazou [mailto:ebotca...@adacore.com] 
Sent: Friday, July 27, 2012 10:26 AM
To: Iyer, Balaji V
Cc: gcc@gcc.gnu.org
Subject: Re: build6_stat removed?

>   I have a question regarding build6_stat. I saw that in 7/25 merge,
>   someone removed this function. Why was it removed?

Because it has been unused for a while, as TARGET_MEM_REF has 5 operands now.

>   I am currently using it in my Cilk Plus branch. What is a work around
>   for this? Am I allowed to put this function back in?

Sure, if you use it; but you are thus encouraged to trim down the number of 
operands of your new tree codes. ;-)

--
Eric Botcazou

build6_stat removed?

2012-07-26 Thread Iyer, Balaji V

Hello Everyone,
I have a question regarding build6_stat. I saw that in 7/25 merge, 
someone removed this function. Why was it removed? I am currently using it in 
my Cilk Plus branch. What is a work around for this? Am I allowed to put this 
function back in?

Thanks,

Balaji V. Iyer.

RE: Enabling a function based on Language

2012-05-22 Thread Iyer, Balaji V

Thanks Tobias,

I am wanting to call this function right before we hit the 
gimplify_function_tree (), so I guess I am right before the middle-end...

-Balaji V. Iyer.

-Original Message-
From: Tobias Burnus [mailto:bur...@net-b.de] 
Sent: Tuesday, May 22, 2012 3:25 AM
Cc: i...@google.com; Iyer, Balaji V; 'gcc@gcc.gnu.org'
Subject: Re: Enabling a function based on Language

Ian Lance Taylor wrote:
> "Iyer, Balaji V"  writes:
>
>>  Is there a #define in GCC that will turn on only for certain languages? 
>> I am trying to use build_array_ref but it is giving me a undefined reference 
>> for f951. This code that I am trying to use will ONLY execute  if we have a 
>> C/C++ code.  Is it possible for me to enclose this inside some #defines (or 
>> a combination of them)?
>
> By definition, no, there isn't.  The middle-end is compiled once, into 
> a library.  Then each frontend is linked against that library.
>
> Calling a frontend function like build_array_ref from the middle-end 
> is always a mistake.  In the middle-end you should probably be making 
> a POINTER_PLUS_EXPR node or something along those lines.

Unless, of course, one goes the route which Richard once suggested: 
Adding array and scalarizer support to the middle end, 
http://gcc.gnu.org/wiki/GCCGathering2011Fortran#Scalarizer

(See all three links; mistakes in the Wiki are mine, made when I tried to 
summarize/understand Richard's draft patches. The project got stalled as there 
was not enough developer time on the Fortran side and as the current approach 
works relatively well. ME support would be beneficial as it would allow for 
certain optimizations which are not possible in the front end.)

Tobias

Enabling a function based on Language

2012-05-21 Thread Iyer, Balaji V

Hello Everyone,
Is there a #define in GCC that will turn on only for certain languages? 
I am trying to use build_array_ref but it is giving me a undefined reference 
for f951. This code that I am trying to use will ONLY execute  if we have a 
C/C++ code.  Is it possible for me to enclose this inside some #defines (or a 
combination of them)?

Any help is greatly appreciated!

Thanks,

Balaji V. Iyer.

Vectorizer question

2012-05-16 Thread Iyer, Balaji V

Hello Everyone,
I have a question regarding the vectorizer. In the following code 
below...

Int func (int x, int y)
{
If (x==y)
Return (x+y);
Else
Return (x-y);
}

If we force the x and y to be vectors of vectorlength 4, then will the 
if-statement get a vector of booleans or does it get 1 boolean that compares 2 
very large values? I guess another way to ask is that, will it logically break 
it up into 4 if-statements or just 1?

Any help is greatly appreciated!

Thanks,

Balaji V. Iyer.

PS. Please CC me in response  so that I can get to it quickly.

cgraph_nodes_queue replacement?

2012-04-26 Thread Iyer, Balaji V

Hello Everyone,
I just recently pulled the trunk and I noticed that cgraph_nodes_queue 
is taken out. Is it renamed (or #defined) to something else? I am using it for 
some code in my Cilk plus branch. So what is the appropriate replacement for 
the following code? 

for (n = cgraph_nodes_queue; n ; n = n->next_needed)

Any help is greatly appreciated!

Thanks,

Balaji V. Iyer.

GIT Mirror Down?

2012-04-18 Thread Iyer, Balaji V

Hello Everyone,
Is the GIT mirror for GCC down? I tried clicking on the snapshot link 
near a commit and it is timing out.


Thanks,

Balaji V. Iyer.

RE: Question about Tree_function_versioning

2012-03-26 Thread Iyer, Balaji V

I have another question along the same lines. Is it possible to tell gcc to 
never delete a certain function even if it is never called in the executable?

Any help is greatly appreciated!

Thanks,

Balaji V. Iyer.

-Original Message-
From: Martin Jambor [mailto:mjam...@suse.cz] 
Sent: Monday, March 26, 2012 8:52 AM
To: Iyer, Balaji V
Cc: 'gcc@gcc.gnu.org'
Subject: Re: Question about Tree_function_versioning

Hi,

On Mon, Mar 26, 2012 at 01:34:55AM +0000, Iyer, Balaji V wrote:
> Hello Everyone,
> I am currently trying to take certain functions (marked by certain
> attributes) and create vector version along with the scalar versions 
> of the function. For example, let's say I have a function my_add that 
> is marked with a certain attribute, I am trying to clone it into 
> my_add_vector and still keep the original my_add. For this, I am 
> trying to use tree_function_versioning in cgraphunit.c to clone the 
> cgraph_node into a new function. Does this function actually create a 
> 2nd function (called my_add_vector) and copy the body from my_add 
> function to the my_add_vector function or does it just create a node 
> called my_add_vector and then create a pointer to the body of the 
> my_add?
> 
> Is there a better approach for doing this?
> 

tree_function_versioning indeed does copy the body of a function into a new 
one, but that's the only thing it does.  You might be better served by its 
callers such as cgraph_function_versioning.  But I believe all cloning 
functions currently also make the new clone private to the current compilation 
unit (and thus subject to unreachable node removal if they have no callers) 
which is something you might not want.  If it is a problem, you'd either need 
to re-set the relevant decl and node attributes subsequently or change the 
cloning functions themselves.

I assume you're not operating within an IPA pass, in that case you'd need 
cgraph_create_virtual_clone and a transformation hook.

Martin

RE: GSoC :Project Idea(Before final Submission) for review and feedback

2012-03-25 Thread Iyer, Balaji V



-Original Message-
From: Subrata Biswas [mailto:subrata.i...@gmail.com] 
Sent: Sunday, March 25, 2012 12:22 PM
To: Oleg Endo
Cc: gcc
Subject: Re: GSoC :Project Idea(Before final Submission) for review and feedback

Thank you sir for your excellent example.

On 25 March 2012 15:25, Oleg Endo  wrote:
> Please reply in CC to the GCC mailing list, so others can follow the 
> discussion.
>
> On Sun, 2012-03-25 at 09:21 +0530, Subrata Biswas wrote:
>> On 25 March 2012 03:59, Oleg Endo  wrote:
>> >
>> > I might be misunderstanding the idea...
>> > Let's assume you've got a program that doesn't compile, and you 
>> > leave out those erroneous blocks to enforce successful compilation 
>> > of the broken program.  How are you going to figure out for which 
>> > blocks it is actually safe to be removed and for which it isn't?
>>
>> I can do it by tracing the code blocks which are dependent on the 
>> erroneous block. i.e if any block is data/control dependent(the 
>> output or written value of the erroneous part is read) on this 
>> erroneous block or line of code will be eliminated.
>>
>> > Effectively, you'll
>> > be changing the original semantics of a program, and those semantic 
>> > changes might be completely not what the programmer originally had 
>> > in mind.  In the worst case, something might end up with an 
>> > (un)formatted
>> > harddisk...*
>> >
>> > Cheers,
>> > Oleg
>> >
>> Thank you sir for your great feedback. You have understood it 
>> correctly. Now the programmer will be informed about the change in 
>> code and the semantics.(Notice that this plug-in is not going to 
>> modify the original code!, it just copy the original code and perform 
>> all the operations on the temporary file!!!) Even from the partial 
>> execution of the code the programmer will get an overview of his 
>> actual progress.
>>
>> suppose the program written by the programmer be:
>>
>> 1 int main(void)
>> 2 {
>> 3    int arr[]={3,4,-10,22,33,37,11};
>> 4    sort(arr);
>> 5    int a = arr[3] // Now suppose the programmer missed the 
>> semicolon here. Which generates a compilation error at line 5;
>> 6    printf("%d\n",a);
>> 7    for(i=0;i<7;i++)
>> 8    {
>> 9        printf("%d\n",arr[i]);
>> 10    }
>> 11  }
>>
>>
>> Now if we just analyze the data (i.e. variable), we can easily find 
>> that there is only data dependency exists between line 5 and line 6.
>> The rest of the program is not being effected due to elimination or 
>> commenting line 5.
>>
>> Hence the temporary source file after commenting out the erroneous 
>> part of the code and the code segment that is dependent on this 
>> erroneous  part would be:
>>
>> 1 int main(void)
>> 2 {
>> 3    int arr[]={3,4,-10,22,33,37,11};
>> 4    sort(arr);
>> 5    //int a = arr[3] // Now suppose the programmer missed the 
>> semicolon here. Which generates a compilation error at line 5;
>> 6   // printf("%d\n",a);
>> 7    for(i=0;i<7;i++)
>> 8    {
>> 9        printf("%d\n",arr[i]);
>> 10    }
>> 11  }
>>
>> Now this part of the program(broken program) is error free. Now we 
>> can compile this part using GCC and get the partial executable.
>>
>> Now the possible output after compilation using this plug in(if 
>> programmer use it) with GCC would be:
>>
>> "You have syntax error at Line no. 5. and to generate the partial 
>> executable Line 5 and Line 6 have removed in the temporary executable 
>> execute the partial executable excute p.out"
>>
>> Advantages to the Programmer:
>> 1. If programmer can see the result of the partial executable he can 
>> actually quantify his/her progress in code.
>> 2. The debug become easier as this plug-in would suggest about 
>> possible correction in the code etc.
>
> I don't think it will make the actual debugging task easier.  It might 
> make writing code easier (that's what IDEs are doing these days while 
> you're typing code...).  In order to debug a program, the actual bugs 
> need to be _in_ the program, otherwise there is nothing to debug.
> Removing arbitrary parts of the program could potentially introduce 
> new artificial bugs, just because of a missing semicolon.
>
>> * I did not understand the  worst case that you have mentioned as 
>> (un)formatted hard disk. Can you kindly explain it?
>>
>
> Let's say I'm writing a kind of disk utility that reads and writes 
> sectors...
>
> -
> source1.c:
>
> bool
> copy_sector (void* outbuf, const void* inbuf, int bytecount) {
>  if (bytecount < 4)
>    return false;
>
>  if ((bytecount & 3) != 0)
>    return false;
>
>  int* out_ptr = (int*)outbuf;
>  const int* in_ptr = (const int*)inbuf;
>  int count = bytecount / 4;
>
>  do
>  {
>    int i = *in_ptr++;
>    if (i & 1)
>      i = do_something_special0 (i);
>    else if (i & (1 << 16))
>      i = do_something_special1 (i);
>    *out_ptr++ = i;
>  } while (--count);
>
>  return true;
> }
>
> -
> source0.c:
>
> int main (void)
> {
>  ...
>  int sector_size = get_sector_size (...);
>  vo

Question about Tree_function_versioning

2012-03-25 Thread Iyer, Balaji V

Hello Everyone,
I am currently trying to take certain functions (marked by certain 
attributes) and create vector version along with the scalar versions of the 
function. For example, let's say I have a function my_add that is marked with a 
certain attribute, I am trying to clone it into my_add_vector and still keep 
the original my_add. For this, I am trying to use tree_function_versioning in 
cgraphunit.c to clone the cgraph_node into a new function. Does this function 
actually create a 2nd function (called my_add_vector) and copy the body from 
my_add function to the my_add_vector function or does it just create a node 
called my_add_vector and then create a pointer to the body of the my_add?

Is there a better approach for doing this?

Any help is greatly appreciated!

Thanks,

Balaji V. Iyer.

RE: Differences in GCC and ICC compiled objects, GCC relocations broken?

2012-02-23 Thread Iyer, Balaji V

Hello J. K.,
Have you tried with a newer version of GCC? GCC 4.1 is pretty old

Thanks,

Balaji V. Iyer.

-Original Message-
From: J K [mailto:jkwi...@gmail.com] 
Sent: Thursday, February 23, 2012 10:31 AM
To: gcc@gcc.gnu.org
Subject: Differences in GCC and ICC compiled objects, GCC relocations broken?

 Posted in the Intel forums but this may be more of a GCC issue.
 Please advise if I should post elsewhere.

 Compiling a C module in with a large app (>2GB data) and getting relocatable 
errors with GCC and  not ICC.

./classification_dpr_BB.o: In function `BB_detection_dpr':
/homedata/johnk/dpr/src_
20120126/DD2_V2.20120126/src/./
classification_dpr_BB.c:118: relocation truncated to fit:
R_X86_64_PC32 against `.bss'

 Can anyone familiar with the output of readelf see why the GCC
 object is not relocatable and the ICC one is? Would another tool
 be more suitable?

icc -I../include -g -v -sox -fPIC -mcmodel=medium -DDEBUG  -c 
./classification_dpr_BB.c cc -I../include -g -v -fPIC -mcmodel=medium -DDEBUG  
-c ./classification_dpr_BB.c

  This module does not use more than 2GB data itself, I just need it to be 
linked with
  code that does, so -fPIC.  I left off the medium memory model switch on both 
with no impact.
  Everything is static except for the -shared-intel -mcmodel=medium on the main 
link (ifort is used).

  Could it have something to do with the relocation types? Are there switches 
to GCC to force relocations
  like ICC?

GCC
Relocation section '.rela.text' at offset 0xd040 contains 449 entries:
 Offset          Info           Type           Sym. Value    Sym.
Name + Addend
004e  00170002 R_X86_64_PC32      .rodata
+ fffc
008e  00040002 R_X86_64_PC32      .bss + 1e5c 
00bc  00040002 R_X86_64_PC32      .bss + 105c


ICC
Relocation section '.rela.text' at offset 0xf222 contains 732 entries:
 Offset          Info           Type           Sym. Value    Sym.
Name + Addend
0030  0078001a R_X86_64_GOTPC32   
_GLOBAL_OFFSET_TABLE_ + fffc
0036  00060019 R_X86_64_GOTOFF64 
_2il0floatpacket.15 + 0
0057  00070019 R_X86_64_GOTOFF64 0008
_2il0floatpacket.16 + 0
009f  0078001a R_X86_64_GOTPC32   
_GLOBAL_OFFSET_TABLE_ + fffc

gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-51) icc (ICC) 11.1 20100806

 The full output of readelf -all are at these links.

ICC
http://www.box.com/s/2iqnqydmi0mdz52xs9ac

GCC
http://www.box.com/s/jjcgq1x2s5ybpg7s9b6g

Thanks for any help.

Function-Specific Optimization Branch

2012-02-23 Thread Iyer, Balaji V

Hello Everyone,
Does anyone know the status of the function specific optimization 
branch (http://gcc.gnu.org/wiki/FunctionSpecificOpt)?  I am specifically 
looking for stage3 __clone__ attribute. Has it been implemented/merged into the 
mainline or in the branch?

Thanks,

Balaji V. Iyer.

Template Handling in G++

2012-02-06 Thread Iyer, Balaji V

Hello Everyone,
Can someone please tell me the entry point function (and stage) where the 
template functions are separated for different data types?

Please CC me when responding to this message.

Thanks,

Balaji V. Iyer.

RE: GCC Account

2011-12-16 Thread Iyer, Balaji V

Hello Everyone,
I filled out this form that Jeff Law mentioned ~4-5 days ago, can 
someone please tell me how long it would take for the form to get processed and 
get me write approval? I used my personal email when I submitted the form 
(bvi...@gmail.com), will that be a problem?

Thanking You,

Yours Sincerely,

Balaji V. Iyer.

-Original Message-
From: Jeff Law [mailto:l...@redhat.com] 
Sent: Friday, December 09, 2011 11:08 AM
To: gcc@gcc.gnu.org
Subject: Re: GCC Account

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/09/11 08:32, Iyer, Balaji V wrote:
> Hello Everyone, I am Balaji V. Iyer, and I have been maintaining the 
> Cilkplus branch of the GCC compiler. I have been working on the 
> Cilkplus branch for approximately 6 months and I have been working 
> different GCC projects for the past 5 years. I do not have write 
> access for the Cilkplus branch and thus I have to have someone else 
> check in my patches into the branch. Is it possible for me to get an 
> account so that I can check in my patches myself?

You'll need to fill out this form to get write access:


http://sourceware.org/cgi-bin/pdw/ps_form.cgi
Jeff
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJO4jJsAAoJEBRtltQi2kC7lDYH/2+qgAq6Rlc6yBqiWTPsT9ZA
23GkKTIhGlw1QPFPw6osk2lFIO08DsY7C9kCEG2xnUCStJfnatLYwK1/yUitf6Mz
jAYRnrmnGhCxSBWqNf9LBqwLPrCTENfkZqEz8igZL/SD1XnNyKwj2ACVXCIa6Rud
6Syr835HC60lxTMazzySFX4q5gtuL7IVaWSEdNZNtPMkdv3ARmzOmtaJUVNHmDRk
jpjDAMGvf2uH7J6+8nMMnmtwzpR7qAkxNeCHvk4RyT0jFnXx/0YuX5Uvf2Ghni7h
Rw7Zu/5QXOWwXSlNWauitlqc8a0+jiqSM7N90+438cPfOhggucTOQG8vaCJon08=
=xheJ
-END PGP SIGNATURE-

GCC Account

2011-12-09 Thread Iyer, Balaji V

Hello Everyone,
I am Balaji V. Iyer, and I have been maintaining the Cilkplus branch of 
the GCC compiler. I have been working on the Cilkplus branch for approximately 
6 months and I have been working different GCC projects for the past 5 years. I 
do not have write access for the Cilkplus branch and thus I have to have 
someone else check in my patches into the branch. Is it possible for me to get 
an account so that I can check in my patches myself?

Thanking You,

Yours Sincerely,

Balaji V. Iyer.

Preserve labels for the life of Compliation

2011-11-29 Thread Iyer, Balaji V

Hello Everyone,
I would like to insert labels at certain instances of the program as a 
marker and then print them out at a separate section at the end of the assembly 
file. I am able to do that but the garbage collector seem to be deleting the 
labels. Is it possible for me to stop this?

The way I am creating the labels are doing the following:

new_label = gen_label_rtx ()
LABEL_PRESERVE_P (new_label) = 1;
INSN_UID (new_label) = ctrl->emit.x_cur_insn_uid++;
LABEL_NUSES(new_label) = 1;

Is there any other tag I can add to make sure the garbage collector doesn't 
touch it?

Thanks,

Balaji V. Iyer.

RE: Bootstrap Failure Question

2011-11-04 Thread Iyer, Balaji V

Thanks Jeff for your help! 

So, are the errors confined to these files? Or could it be anywhere?

Comparing stages 2 and 3
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
Bootstrap comparison failure!
gcc/i386-common.o differs
gcc/bitmap.o differs
libiberty/timeval-utils.o differs
libiberty/pic/timeval-utils.o differs

Is there anything else I can do to pin-point the problem? (like maybe gdb a 
certain file or pass a certain flag to get some debug info)

Thanks,

Balaji V. Iyer.

-Original Message-
From: Jeff Law [mailto:l...@redhat.com] 
Sent: Friday, November 04, 2011 2:41 PM
To: Iyer, Balaji V
Cc: 'gcc@gcc.gnu.org'
Subject: Re: Bootstrap Failure Question

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/04/11 12:34, Iyer, Balaji V wrote:
> Hello Everyone, I am getting a bootstrap failure right now when I try 
> to build GCC. Here is the output. Can someone please tell me how to 
> fix this? Is this something I have modified? I just configured using 
> the following command (../gcc/configure -prefix=). I 
> haven't modified any of the .o files mentioned in the error.
Typically a comparison failure means GCC has mis-compiled itself.  You have to 
figure out why.

I typically start with a small test which is compiled differently by the stage1 
and stage2 compilers.  Then I figure out where they diverge in their behavior 
(say at a pass level).  Then I figure out where they first diverge at a 
function within a pass.  That's usually the function that is being mis-compiled.

Sometimes you can make some educated guesses based recent changes and comparing 
how something was compiled before/after the change.

In all these are some of the most annoying bugs to tackle.

jeff
> 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOtDHBAAoJEBRtltQi2kC7L20H/1SCJSyusm+MG3oL3SIS2AWz
ahbGFPnIQO0jPi7KGGuH0Cb1ynk1yvHlyLGOoLMAxvRU4zzoKVpXfg7PD966C8Ad
m7Lak7kTlyX6i+rB4+CIAsAA24u0Q1vzvnyzW4gEYk7v1dvvee1nqEMR5p/DbfUU
iXei/L+tZJ4Vq5lf/+0B8Zz7+P10KmU1VydAlFS9OeK2QKuESXUADUiVZtrWZXsB
ClzXOqm6F9Zq/HpK/Va5SGeiYy3sXGzFIzYUnV/RlZcExWH7kPTgbkLXky/D4lKS
CyTzXsfo5mvqZuIp7HtOXGrSZPl2/w2Y1KF0LlQntkJKVR81sic/KG2CfeAVGPA=
=5ZYe
-END PGP SIGNATURE-

Bootstrap Failure Question

2011-11-04 Thread Iyer, Balaji V

Hello Everyone,
I am getting a bootstrap failure right now when I try to build GCC. 
Here is the output. Can someone please tell me how to fix this? Is this 
something I have modified? I just configured using the following command 
(../gcc/configure -prefix=). I haven't modified any of the .o 
files mentioned in the error.

Any help is greatly appreciated!

Also, please CC me when you respond.

Thanks,

Balaji V. Iyer.

make[2]: Leaving directory `/home/ME/gcc-source/gcc-4.7/b-gcc'
make "DESTDIR=" "RPATH_ENVVAR=LD_LIBRARY_PATH" 
"TARGET_SUBDIR=x86_64-unknown-linux-gnu" 
"bindir=/home/ME/gcc-source/gcc-4.7/install/bin" 
"datadir=/home/ME/gcc-source/gcc-4.7/install/share" 
"exec_prefix=/home/ME/gcc-source/gcc-4.7/install" 
"includedir=/home/ME/gcc-source/gcc-4.7/install/include" 
"datarootdir=/home/ME/gcc-source/gcc-4.7/install/share" 
"docdir=/home/ME/gcc-source/gcc-4.7/install/share/doc/" 
"infodir=/home/ME/gcc-source/gcc-4.7/install/share/info" 
"pdfdir=/home/ME/gcc-source/gcc-4.7/install/share/doc/" 
"htmldir=/home/ME/gcc-source/gcc-4.7/install/share/doc/" 
"libdir=/home/ME/gcc-source/gcc-4.7/install/lib" 
"libexecdir=/home/ME/gcc-source/gcc-4.7/install/libexec" "lispdir=" 
"localstatedir=/home/ME/gcc-source/gcc-4.7/install/var" 
"mandir=/home/ME/gcc-source/gcc-4.7/install/share/man" 
"oldincludedir=/usr/include" "prefix=/home/ME/gcc-source/gcc-4.7/install" 
"sbindir=/home/ME/gcc-source/gcc-4.7/install/sbin" 
"sharedstatedir=/home/ME/gcc-source/gcc-4.7/install/com" 
"sysconfdir=/home/ME/gcc-source/gcc-4.7/install/etc" 
"tooldir=/home/ME/gcc-source/gcc-4.7/install/x86_64-unknown-linux-gnu" 
"build_tooldir=/home/ME/gcc-source/gcc-4.7/install/x86_64-unknown-linux-gnu" 
"target_alias=x86_64-unknown-linux-gnu" "AWK=gawk" "BISON=bison" 
"CC_FOR_BUILD=gcc" "CFLAGS_FOR_BUILD=-g -O2" "CXX_FOR_BUILD=g++" 
"EXPECT=expect" "FLEX=flex" "INSTALL=/usr/bin/install -c" 
"INSTALL_DATA=/usr/bin/install -c -m 644" "INSTALL_PROGRAM=/usr/bin/install -c" 
"INSTALL_SCRIPT=/usr/bin/install -c" "LDFLAGS_FOR_BUILD=" "LEX=flex" "M4=m4" 
"MAKE=make" "RUNTEST=runtest" "RUNTESTFLAGS=" "SED=/bin/sed" "SHELL=/bin/bash" 
"YACC=bison -y" "`echo 'ADAFLAGS=' | sed -e s'/[^=][^=]*=$/XFOO=/'`" 
"ADA_CFLAGS=" "AR_FLAGS=rc" "`echo 'BOOT_ADAFLAGS=-gnatpg -gnata' | sed -e 
s'/[^=][^=]*=$/XFOO=/'`" "BOOT_CFLAGS=-g -O2" "BOOT_LDFLAGS=" "CFLAGS=-g -O2" 
"CXXFLAGS=-g -O2" "LDFLAGS=" "LIBCFLAGS=-g -O2" "LIBCXXFLAGS=-g -O2 
-fno-implicit-templates" "STAGE1_CHECKING=--enable-checking=yes,types" 
"STAGE1_LANGUAGES=c,c++,lto" "GNATBIND=no" "GNATMAKE=no" "AR_FOR_TARGET=ar" 
"AS_FOR_TARGET=as" "CC_FOR_TARGET=/home/ME/gcc-source/gcc-4.7/b-gcc/./gcc/xgcc 
-B/home/ME/gcc-source/gcc-4.7/b-gcc/./gcc/" "CFLAGS_FOR_TARGET=-g -O2" 
"CPPFLAGS_FOR_TARGET=" "CXXFLAGS_FOR_TARGET=-g -O2 -D_GNU_SOURCE" 
"DLLTOOL_FOR_TARGET=dlltool" 
"FLAGS_FOR_TARGET=-B/home/ME/gcc-source/gcc-4.7/install/x86_64-unknown-linux-gnu/bin/
 -B/home/ME/gcc-source/gcc-4.7/install/x86_64-unknown-linux-gnu/lib/ -isystem 
/home/ME/gcc-source/gcc-4.7/install/x86_64-unknown-linux-gnu/include -isystem 
/home/ME/gcc-source/gcc-4.7/install/x86_64-unknown-linux-gnu/sys-include" 
"GCJ_FOR_TARGET=/home/ME/gcc-source/gcc-4.7/b-gcc/./gcc/gcj 
-B/home/ME/gcc-source/gcc-4.7/b-gcc/./gcc/" 
"GFORTRAN_FOR_TARGET=/home/ME/gcc-source/gcc-4.7/b-gcc/./gcc/gfortran 
-B/home/ME/gcc-source/gcc-4.7/b-gcc/./gcc/" "GOC_FOR_TARGET=" 
"GOCFLAGS_FOR_TARGET=-O2 -g" "LD_FOR_TARGET=ld" "LIPO_FOR_TARGET=lipo" 
"LDFLAGS_FOR_TARGET=" "LIBCFLAGS_FOR_TARGET=-g -O2" "LIBCXXFLAGS_FOR_TARGET=-g 
-O2 -D_GNU_SOURCE -fno-implicit-templates" "NM_FOR_TARGET=nm" 
"OBJDUMP_FOR_TARGET=objdump" "RANLIB_FOR_TARGET=ranlib" 
"STRIP_FOR_TARGET=strip" "WINDRES_FOR_TARGET=windres" 
"WINDMC_FOR_TARGET=windmc" "BUILD_CONFIG=bootstrap-debug" "`echo 'LANGUAGES=' | 
sed -e s'/[^=][^=]*=$/XFOO=/'`" "LEAN=false" "STAGE1_CFLAGS=-g 
-fkeep-inline-functions" "STAGE1_CXXFLAGS=-g -fkeep-inline-functions" 
"STAGE1_TFLAGS=" "STAGE2_CFLAGS=-g -O2 -gtoggle" "STAGE2_CXXFLAGS=-g -O2 
-gtoggle" "STAGE2_TFLAGS=" "STAGE3_CFLAGS=-g -O2" "STAGE3_CXXFLAGS=-g -O2" 
"STAGE3_TFLAGS=" "STAGE4_CFLAGS=-g -O2" "STAGE4_CXXFLAGS=-g -O2" 
"STAGE4_TFLAGS=" "STAGEprofile_CFLAGS=-g -O2 -gtoggle -fprofile-generate" 
"STAGEprofile_CXXFLAGS=-g -O2 -gtoggle -fprofile-generate" 
"STAGEprofile_TFLAGS=" "STAGEfeedback_CFLAGS=-g -O2 -fprofile-use" 
"STAGEfeedback_CXXFLAGS=-g -O2 -fprofile-use" "STAGEfeedback_TFLAGS=" 
"CXX_FOR_TARGET= $r/./gcc/g++ -B$r/./gcc/ -nostdinc++ `if test -f 
$r/x86_64-unknown-linux-gnu/libstdc++-v3/scripts/testsuite_flags; then 
/bin/bash $r/x86_64-unknown-linux-gnu/libstdc++-v3/scripts/testsuite_flags 
--build-includes; else echo -funconfigured-libstdc++-v3 ; fi` 
-L$r/x86_64-unknown-linux-gnu/libstdc++-v3/src 
-L$r/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs" "TFLAGS=" 
"CONFIG_SHELL=/bin/bash" "MAKEINFO=makeinfo --split-size=500 
--split-size=500"  compare
make[2]: Entering directory `/home/ME/gcc-source/gcc-4.7/b-gcc'
make[3]: Entering directory

Dependent Labels Question

2011-11-03 Thread Iyer, Balaji V

Hello Everyone,
Is it possible in GCC to create a label that is some-how dependent on a 
RTL INSN (i.e. if the RTL INSN moves, the label moves with it)?

For example: In the below code

...
Add r1, r2, r3
Call some_function
LABELX:
Sub r3, r4, r5
...
...

Is it possible to make sure that the "LABELX" occurs right after the "Call 
some_function" instruction (and the instruction scheduler moves the label with 
the call INSN)? I insert the label right after the call is expanded and LABELX 
is being moved above the Call instruction by the schedule_insns function.

Thanks,

Balaji V. Iyer.

RE: Getting DWARF codes from RTX

2011-10-20 Thread Iyer, Balaji V

Please see my comments embedded with "BVI>"

-Original Message-
From: Ian Lance Taylor [mailto:i...@google.com] 
Sent: Thursday, October 20, 2011 2:18 PM
To: Iyer, Balaji V
Cc: 'gcc@gcc.gnu.org'
Subject: Re: Getting DWARF codes from RTX

"Iyer, Balaji V"  writes:

>   What I want to do is to look at certain function calls and mark them 
> with a special label and then create a table  with a specialized 
> section with contains the label name, the function name (as ascii 
> string) and then the dwarf code of the register (assuming the 
> parameters can be passed in through registers, otherwise the stack 
> address location) in which the parameters for the function is stored. 
> (Please note that this is something that is customized for another 
> package and I don't have much leeway on how to store this information)
>
> Eg.
>
> If you have:   
> some_func_call (x, y, z)
>
> We will have an assembly like this
>
>   Set R1, x
>   Set R2, y
>   Set R3, z
> LABEL_X:<=== SOMETHING I PUT IN
>   Call some_func_call
>
>
> In my data section I would have something like this:
>
> LABEL_X
> some_func_call
> DW_OP_REG1, DW_OP_REG2, DW_OP_REG3

OK, I think I mostly understand all that.

> So, I need the equivalent dwarf code (in hex) for DW_OP_REG1, DW_OP_REG2 and 
> DW_OP_REG3, so that a dwarf decoder can decode it correctly.

I'm not sure I understand that.  The code for DW_OP_reg1 is 0x51, as you can 
see in include/dwarf2.h.  But I don't think that is what you mean.

BVI> Actually what I want is to have a way to go from the rtx value e.g (REG: 
SI 1 di) to 0x51

It sounds like you might be asking for a way to get the DWARF representation of 
the argument locations of the function call.  See loc_descriptor in 
gcc/dwarf2out.c.

BVI> I will look into the loc descriptor. Thank you!

Ian

Thanks,

Balaji V. Iyer.

RE: Getting DWARF codes from RTX

2011-10-20 Thread Iyer, Balaji V

Hi Ian,
What I want to do is to look at certain function calls and mark them 
with a special label and then create a table  with a specialized section with 
contains the label name, the function name (as ascii string) and then the dwarf 
code of the register (assuming the parameters can be passed in through 
registers, otherwise the stack address location) in which the parameters for 
the function is stored. (Please note that this is something that is customized 
for another package and I don't have much leeway on how to store this 
information)

Eg.

If you have:   
some_func_call (x, y, z)

We will have an assembly like this

Set R1, x
Set R2, y
Set R3, z
LABEL_X:<=== SOMETHING I PUT IN
Call some_func_call

In my data section I would have something like this:

LABEL_X 
some_func_call
DW_OP_REG1, DW_OP_REG2, DW_OP_REG3

So, I need the equivalent dwarf code (in hex) for DW_OP_REG1, DW_OP_REG2 and 
DW_OP_REG3, so that a dwarf decoder can decode it correctly.

Thanks,

Balaji V. Iyer.

-Original Message-
From: Ian Lance Taylor [mailto:i...@google.com] 
Sent: Thursday, October 20, 2011 2:03 AM
To: Iyer, Balaji V
Cc: 'gcc@gcc.gnu.org'
Subject: Re: Getting DWARF codes from RTX

"Iyer, Balaji V"  writes:

>   Is there a function (or a series of functions) in GCC using which I can 
> convert a register number (either in RTX or int) to DWARF code?

Are you looking for DWARF_FRAME_REGNUM?

If not, what do you mean by DWARF code?  Do you mean inside gcc, or in code 
compiled by gcc?  Please give an example.

Ian

Getting DWARF codes from RTX

2011-10-19 Thread Iyer, Balaji V

Hello Everyone,
Is there a function (or a series of functions) in GCC using which I can 
convert a register number (either in RTX or int) to DWARF code?

Any help is greatly appreciated!


Thanks,

Balaji V. Iyer.

RE: GCC 4.7.0 Status Report (2011-09-09)

2011-10-19 Thread Iyer, Balaji V

-Original Message-
From: Gary Funck [mailto:g...@intrepid.com] 
Sent: Thursday, September 22, 2011 5:00 PM
To: Jakub Jelinek
Cc: gcc@gcc.gnu.org; Joseph S. Myers
Subject: Re: GCC 4.7.0 Status Report (2011-09-09)

On 09/09/11 09:09:30, Jakub Jelinek wrote:
> [...] What is the status of lra, reload-2a, pph, cilkplus, gupc (I 

I apologize for the late response, my radar didn't catch this message. Cilkplus 
is not currently feature-complete. We definitely hope to have it completed as 
soon as we can.

> assume at least some of these are 4.8+ material)?

For GUPC, we are targeting GCC 4.8.

thanks,
- Gary

RE: Function Name from CALL_INSN RTX

2011-10-18 Thread Iyer, Balaji V

Thanks for the help Ian. The function get_callee_fndecl takes in a tree and 
returns a tree. I would like to get the function name from the RTX. Is there a 
function for this purpose? 

Thanks,

Balaji V. Iyer.

From: Ian Lance Taylor [i...@google.com]
Sent: Tuesday, October 18, 2011 12:47 AM
To: Iyer, Balaji V
Cc: 'gcc@gcc.gnu.org'
Subject: Re: Function Name from CALL_INSN RTX

"Iyer, Balaji V"  writes:

>Is it possible to extract the function name (as a tree or char *)  
> from a CALL_INSN RTX? Is there a #define or a series of #defines that can 
> accomplish this?

Not always, of course.  A call through a function pointer has no name.

The function get_callee_fndecl will do its best to get the function decl
from a CALL_EXPR.

Ian

Function Name from CALL_INSN RTX

2011-10-17 Thread Iyer, Balaji V

Hello Everyone,
   Is it possible to extract the function name (as a tree or char *)  from 
a CALL_INSN RTX? Is there a #define or a series of #defines that can accomplish 
this? 
   
   The tried to find this information by stepping through the print_rtx 
function using gdb and the information (as a char *) is currently stored in the 
following location of a CALL_INSN: 
"insn->u.fld[4]->rt_rtx->u.fld[1]->rt_rtx->u.fld[0]->rt_rtx->u.fld[0]->rt_rtx->u.fld[0]->rt_str
 "

  Does anyone know of a #define or a function I can call to retrieve this 
information? I would prefer to use functions or #defines rather than absolute 
locations for future compatibility.

Any help is greatly appreciated!

Thanks,

Balaji V. Iyer.

RE: Question about default_elf_asm_named_section function

2011-10-14 Thread Iyer, Balaji V

Attached, please find a patch fixing this issue.

2011-10-14  Balaji V. Iyer  

* varasm.c (default_elf_asm_named_section): Removed ATTRIBUTE_UNUSED 
tag 
before decl.


Thanks,

Balaji V. Iyer.


-Original Message-
From: Ian Lance Taylor [mailto:i...@google.com] 
Sent: Friday, October 14, 2011 4:29 PM
To: Iyer, Balaji V
Cc: 'gcc@gcc.gnu.org'
Subject: Re: Question about default_elf_asm_named_section function

"Iyer, Balaji V"  writes:

> Can I submit a patch for it? Or is it a small thing that patch is not 
> necessary?

I will preapprove such a patch for anybody with commit access.

Ian

> -Original Message-
> From: Ian Lance Taylor [mailto:i...@google.com] 
> Sent: Friday, October 14, 2011 12:38 AM
> To: Iyer, Balaji V
> Cc: 'gcc@gcc.gnu.org'
> Subject: Re: Question about default_elf_asm_named_section function
>
> "Iyer, Balaji V"  writes:
>
>>  This email is in reference to the "default_elf_asm_named_section" 
>> function in the varasm.c file. 
>>
>> This function is defined like this:
>>
>> void
>> default_elf_asm_named_section (const char *name, unsigned int flags,
>>tree decl ATTRIBUTE_UNUSED)
>>
>>
>> But, inside the function, there is this if-statement:
>>
>>
>>   if (HAVE_COMDAT_GROUP && (flags & SECTION_LINKONCE))
>> {
>>   if (TREE_CODE (decl) == IDENTIFIER_NODE)
>> fprintf (asm_out_file, ",%s,comdat", IDENTIFIER_POINTER (decl));
>>   else
>> fprintf (asm_out_file, ",%s,comdat",
>>  IDENTIFIER_POINTER (DECL_COMDAT_GROUP (decl)));
>> }
>>
>>
>> The decl is set with "ATTRIBUTE_UNUSED" but the if-statement is using 
>> "decl." Should we remove the attribute unused tag near the "tree decl" or is 
>> the if-statement a deadcode that should never be ?
>
>
> ATTRIBUTE_UNUSED does not mean "this parameter is never used."  It means 
> "this parameter may not be used."  The difference is due to #ifdefs--if a 
> parameter is only used in code that is something #ifdef'ed out, then the 
> parameter should be marked as ATTRIBUTE_UNUSED.
>
> In this case the parameter is always used, so we might as well remove the 
> ATTRIBUTE_UNUSED.
>
> Ian
diff --git a/gcc/varasm.c b/gcc/varasm.c
index e83bebb..94c865c 100644
--- a/gcc/varasm.c
+++ b/gcc/varasm.c
@@ -6142,7 +6142,7 @@ default_no_named_section (const char *name 
ATTRIBUTE_UNUSED,
 
 void
 default_elf_asm_named_section (const char *name, unsigned int flags,
-  tree decl ATTRIBUTE_UNUSED)
+  tree decl)
 {
   char flagchars[10], *f = flagchars;

RE: Question about default_elf_asm_named_section function

2011-10-14 Thread Iyer, Balaji V

Can I submit a patch for it? Or is it a small thing that patch is not necessary?

Thanks,

Balaji V. Iyer.

-Original Message-
From: Ian Lance Taylor [mailto:i...@google.com] 
Sent: Friday, October 14, 2011 12:38 AM
To: Iyer, Balaji V
Cc: 'gcc@gcc.gnu.org'
Subject: Re: Question about default_elf_asm_named_section function

"Iyer, Balaji V"  writes:

>   This email is in reference to the "default_elf_asm_named_section" 
> function in the varasm.c file. 
>
> This function is defined like this:
>
> void
> default_elf_asm_named_section (const char *name, unsigned int flags,
>tree decl ATTRIBUTE_UNUSED)
>
>
> But, inside the function, there is this if-statement:
>
>
>   if (HAVE_COMDAT_GROUP && (flags & SECTION_LINKONCE))
> {
>   if (TREE_CODE (decl) == IDENTIFIER_NODE)
> fprintf (asm_out_file, ",%s,comdat", IDENTIFIER_POINTER (decl));
>   else
> fprintf (asm_out_file, ",%s,comdat",
>  IDENTIFIER_POINTER (DECL_COMDAT_GROUP (decl)));
> }
>
>
> The decl is set with "ATTRIBUTE_UNUSED" but the if-statement is using "decl." 
> Should we remove the attribute unused tag near the "tree decl" or is the 
> if-statement a deadcode that should never be ?


ATTRIBUTE_UNUSED does not mean "this parameter is never used."  It means "this 
parameter may not be used."  The difference is due to #ifdefs--if a parameter 
is only used in code that is something #ifdef'ed out, then the parameter should 
be marked as ATTRIBUTE_UNUSED.

In this case the parameter is always used, so we might as well remove the 
ATTRIBUTE_UNUSED.

Ian

Question about default_elf_asm_named_section function

2011-10-12 Thread Iyer, Balaji V

Hello Everyone,
This email is in reference to the "default_elf_asm_named_section" 
function in the varasm.c file. 

This function is defined like this:

void
default_elf_asm_named_section (const char *name, unsigned int flags,
   tree decl ATTRIBUTE_UNUSED)


But, inside the function, there is this if-statement:


  if (HAVE_COMDAT_GROUP && (flags & SECTION_LINKONCE))
{
  if (TREE_CODE (decl) == IDENTIFIER_NODE)
fprintf (asm_out_file, ",%s,comdat", IDENTIFIER_POINTER (decl));
  else
fprintf (asm_out_file, ",%s,comdat",
 IDENTIFIER_POINTER (DECL_COMDAT_GROUP (decl)));
}


The decl is set with "ATTRIBUTE_UNUSED" but the if-statement is using "decl." 
Should we remove the attribute unused tag near the "tree decl" or is the 
if-statement a deadcode that should never be ?

Thanks,

Balaji V. Iyer.

Question about Offsets

2011-10-11 Thread Iyer, Balaji V

Hello Everyone,
This question is regarding adding offsets into a user-defined section 
into gcc.

Let’s say I have a section called “my_section” and I want the section to have 
some sub-sections (e.g. a string table). One of the fields in my section is the 
offset to the next header. How do I represent this in GCC? I think I have to do 
it in RTL expressions (RTX).

Here is an example of what I am trying to do (please note that what I have 
below is a semi-pseudo code). 

.section “.my_section”

START_LABEL:   
# The next 5 lines are headers
.ascii “My Section Magic Header”
.int STRING_TABLE_LABEL – START_LABEL  ⇐== HOW TO DO THIS? I 
WOULD LIKE THE LINKER TO THEN CONVERT IT TO A NUMBER.
.int  10 
…  # Here I have other data which could be of 
variable length

STRING_TABLE_LABEL:
.string “HELLO”
.string “WORLD”

.end “my_section”
.section “.text”
……




Thanks,

Balaji V. Iyer.

RE: compile a bounch of file

2011-10-09 Thread Iyer, Balaji V

Hello Esmaeil,
I have used Simplescalar a long time back, so my memory is not very 
up-to-date. If I remember correctly, all you do is to go to the simplesim-2.0 
directory and type "make" after you modify an existing file. This should create 
a new executable. Please refer to these websites for more information 
(http://www.simplescalar.com/docs/install_guide_v2.txt, 
http://www.simplescalar.com/docs/users_guide_v2.pdf).

To run a make file, all you do is to type "make" in your command prompt 
and it should run the makefile. For this command to work, you should have a 
program called "gmake" installed in your machine. This should come standard 
with most unix/linux install. If not, your system administrator can help you 
install it.

Thanks,

Balaji V. Iyer.


-Original Message-
From: esmaeil mirzaee [mailto:esmaeil.deb...@gmail.com] 
Sent: Sunday, October 09, 2011 6:06 AM
To: gcc
Subject: compile a bounch of file

Hi
Apologize in advanced for weak English and interrupt.
I'm new in programming, I did some changes in a bounch of code and now I want 
to compile it but I have problem and I don't know. How can resolve the problem. 
some one said to me you must run the makefile
:(

I've got Simplescalar and I change some part of the cache.c, Now I want compile 
it and saw the changes I did.
--
Best
Esmaeil
https://sites.google.com/site/esmaeilmirzaee

RE: The AST tree modification. Edited.

2011-10-04 Thread Iyer, Balaji V

Hello,
For most of the things you are looking for, please look for a function 
called build_decl. It is used in several places inside GCC. Let me give you a 
small example, 

If you do the following:

tree x = build_decl (UNKNOWN_LOCATION, VAR_DECL, get_identifer("ii"), 
integer_type_node)

you will declare a variable called "ii" of type "integer."

Similarly, to create a new internal structure, if do something like this:

tree struct_frame = lang_hooks.make_type (RECORD_TYPE);
tree struct_field = build_decl (UNKNOWN_LOCATION, FIELD_DECL, 
get_identifier("variable"), integer_type_node)
TREE_CHAIN(struct_field) = struct_frame

You will create the following internal structure

struct {
   int variable;
}

I hope this helps you get started.

Thanks,

Balaji V .Iyer.

-Original Message-
From: niXman [mailto:i.nix...@gmail.com] 
Sent: Monday, October 03, 2011 6:51 PM
To: gcc@gcc.gnu.org
Subject: The AST tree modification. Edited.

Hi everybody!
It is necessary to implement a plug-in for GCC designed to collect the 
information on types of translation unit, and generate static const array of 
types rtti_ex _ on its base;  //
enum class type_ {
   char_, uchar_, short_, ushort_, int_, uint_, long_, ulong_,
   int64_, uint64_, array_, pointer_, double_, long_double_, float_,
   class_
};

struct rtti_ex_ { // <
   const char* name;
   const type_ type;
   const size_t size;
   const size_t align;
   const size_t offset;
};

// generated from plugin.
static const rtti_ex_ rtti_ex_array_[] = {
   {...},
   {...},
   {...}
};
/

There aren't any problems with information collection from AST. There is a 
complexity with AST modification:
1. How to declare a variable?
2. How to declare the typedef?
3. How to declare a structure?
4. How to declare an array of structures?
I suppose that there should be a function like: tree make_subtree (const char* 
source); which result I could insert in the corresponding node. But I haven't 
found it.

Please, give me some links on this subject. It is very desirable, if you could 
give some links with examples.

Thanks.

GCC Wiki Write Access

2011-10-03 Thread Iyer, Balaji V

Hello Everyone,
I contributed the Cilk Plus branch of GCC and I would like to create a 
page in GCC Wiki (link: http://gcc.gnu.org/wiki/HomePage) with the information 
about this branch and maybe some future work. Can someone please tell me how I 
can get write access to the GCC wiki?

Thanks,

Balaji V. Iyer.

ARRAY_RANGE_REF

2011-09-27 Thread Iyer, Balaji V

Hello Everyone,
Is there a test-case which emits the ARRAY_RANGE_REF tree node for C or 
C++ Compiler? Can someone tell me an example (or even a line of code) that will 
make the compiler create/emit this tree node?

Thanks,

Balaji V. Iyer.

RE: [gimplefe] Ran into a internal compiler error

2011-09-20 Thread Iyer, Balaji V

HI Sandeep,
I think what it is saying is that it is requiring an identifier, but 
you are passing in a variable declaration. Please try to do the following and 
see if it works.

+  return IDENTIFIER_HASH_VALUE (base->decl); }

With

 return IDENTIFIER_HASH_VALUE (DECL_NAME (base->decl));


Thanks,

Balaji V. Iyer.

-Original Message-
From: Sandeep Soni [mailto:soni.sande...@gmail.com] 
Sent: Monday, September 19, 2011 11:32 PM
To: GCC LIST
Cc: Diego Novillo
Subject: [gimplefe] Ran into a internal compiler error

Hi,
I was trying to make a symbol table for all the variable declarations for the 
gimple front end. Following is a patch:

Index: parser.c
===
--- parser.c(revision 174754)
+++ parser.c(working copy)
@@ -28,6 +28,7 @@
 #include "tree.h"
 #include "gimple.h"
 #include "parser.h"
+#include "hashtab.h"
 #include "ggc.h"

 /* The GIMPLE parser.  Note: do not use this variable directly.  It is @@ 
-807,6 +808,31 @@
 }
 }

+
+struct gimple_symtab_entry_def
+{
+  tree decl;
+};
+
+static hashval_t
+gimple_symtab_entry_hash (const void *entry) {
+  const struct gimple_symtab_entry_def *base =
+(const struct gimple_symtab_entry_def *)entry;
+  return IDENTIFIER_HASH_VALUE (base->decl); }
+
+static int
+gimple_symtab_eq_hash (const void *entry1, const void *entry2) {
+  const struct gimple_symtab_entry_def *p1 =
+(const struct gimple_symtab_entry_def *)entry1;
+  const struct gimple_symtab_entry_def *p2 =
+(const struct gimple_symtab_entry_def *)entry2;
+
+  return (p1->decl == p2->decl);
+}
+
 /* The Declaration section within a .gimple file can consist of
a) Declaration of variables.
b) Declaration of functions.
@@ -871,10 +897,29 @@
 gp_parse_var_decl (gimple_parser *parser)  {
   const gimple_token *next_token;
+  const gimple_token *name_token;
+  const char* name;
   enum tree_code code ;

+  htab_t gimple_symtab;
+  void **slot1, **slot2;
+  struct gimple_symtab_entry_def e;
+
+  gimple_symtab = htab_create_ggc (10, gimple_symtab_entry_hash,
gimple_symtab_eq_hash, NULL);
   gl_consume_expected_token (parser->lexer, CPP_LESS);
-  gl_consume_expected_token (parser->lexer, CPP_NAME);
+  name_token = gl_consume_expected_token (parser->lexer, CPP_NAME);  
+ name = gl_token_as_text(name_token);  e.decl = build_decl 
+ (UNKNOWN_LOCATION, VAR_DECL,
get_identifier(name), void_type_node);
+  slot1 = htab_find_slot (gimple_symtab ,&e, INSERT);
+  slot2 = htab_find_slot (gimple_symtab, &e, NO_INSERT);  if (slot1 == 
+ slot2)
+{
+  printf ("I think this is right\n");
+}
+  else
+{
+  printf ("Or this is wrong\n");
+}
   gl_consume_expected_token (parser->lexer, CPP_COMMA);

   next_token = gl_consume_token (parser->lexer); @@ -1391,7 +1436,6 @@
   parser_gc_root__ = NULL;
 }

-
 /* Main entry point for the GIMPLE front end.  */

 void
@@ -1402,7 +1446,6 @@
   parser_gc_root__ = parser = gp_init (main_input_filename);
   if (parser->lexer->filename == NULL)
 return;
-
   gl_lex (parser->lexer);
   gp_parse (parser);
   gp_finish (parser);


It gives me a internal compiler error saying:
gimple1: internal compiler error: tree check: expected identifier_node, have 
var_decl in gimple_symtab_entry_hash

Is there something that I have gotten wrong or something that I had to do 
before that I missed?

--
Cheers
Sandy

Announcing the Port of Intel(r) Cilk (TM) Plus into GCC

2011-08-15 Thread Iyer, Balaji V

Hello Everyone,
   This letter describes the recently created GCC branch called "cilkplus" that 
ports the Intel(R) Cilk(TM) Plus language extensions to the C and C++ 
front-ends of gcc-4.7. We are looking for collaborators and advice as we 
proceed - both on this open-source gcc project, and on the open language 
specification. The compiler and its associated runtime are available at:  
http://gcc.gnu.org/svn/gcc/branches/cilkplus . The URL for the patch is 
available at: http://software.intel.com/file/38093 .

   Intel Cilk Plus is a set of C and C++ constructs for task-parallel and 
data-parallel programming for improving performance on multicore and vector 
processors. This language extension includes the following features:

1.  Three keywords provide a simple yet powerful model for parallel 
programming: _Cilk_spawn, _Cilk_sync and _Cilk_for. Reducers provide an easy, 
lock-free way to deal with shared data.

2.  Simple array notations including elemental functions allow programmers 
to easily use data-parallelism.

3.  Pragmas communicate SIMD information to the vectorizer to help ensure 
that loops are vectorized correctly.

   The implementation of Intel Cilk Plus language extensions to gcc requires 
the above patches to the C and C++ front-ends, plus a copy of the Intel Cilk 
Plus runtime library (Cilk Plus RTL).  Both of these have been checked into the 
new gcc branch.  The Cilk Plus RTL is being maintained by using an upstream, 
BSD-licensed version available at http://www.cilkplus.org .  Changes to the 
Cilk Plus RTL are welcome and must be contributed to the upstream version via 
this web site.  A contribution process is in place for receiving such changes; 
see http://www.cilkplus.org for details.

   In this release, the C and C++ compiler parsers now accept the three 
keywords _Cilk_spawn, _Cilk_sync, and _Cilk_for, as well as a pragma to adjust 
the grainsize of _Cilk_for. The list below provides a brief explanation of each 
of the keywords. For more details, see the "Intel(r) Cilk(tm) Plus Language 
Specification" at http://www.cilkplus.org .

1.  _Cilk_spawn - Annotates a function-call and indicates that execution 
may (but is not required to) continue without waiting for the function to 
return. The syntax is:
[   = ] _Cilk_spawn  ( 
(optional)) ;

2.  _Cilk_sync - Indicates that all the statements in the current Cilk 
block must finish executing before any statements after the _Cilk_sync begin 
executing. The syntax is:
_Cilk_sync ;

3.  _Cilk_for - Is a variant of a for-statement where any or all iterations 
may (but are not required to) execute in parallel. You can optionally precede 
_Cilk_for with a grainsize-pragma to specify the number of serial iterations 
desired for each chunk of the parallel loop. If there is no grainsize pragma or 
if the grainsize evaluates to '0', then the runtime will pick a grainsize using 
its own internal heuristics. The syntax:
[ #pragma cilk grainsize =  ] _Cilk_for ( ; 
 ; )
 

   The parser will accept these keywords and insert the appropriate functions 
to interact with the runtime library. Along with these keywords, you can use 
#pragma simd directives to communicate loop information to the vectorizer so it 
can generate better vectorized code. The five #pragma simd directives are: 
vectorlength, private, linear, reduction, and assert. The list below summarizes 
the five directives. For a detailed explanation please refer to the "Intel(r) 
Cilk(tm) Plus Language Specification" at http://www.cilkplus.org .

1)  #pragma simd vectorlength (n1, n2 ...): Specify a choice vector width 
that the back-end may use to vectorize the loop.

2)  #pragma simd private (var1, var2, ...): Specify a set of variables for 
which each loop iteration is independent of each other iterations.

3)  #pragma simd linear (var1:stride1, var2:stride2, ...): Specify a set of 
variables that increase monotonically in each iteration of the loop.

4)  #pragma simd reduction (operator: var1, var2...): Specify a set of 
variables whose value is computed by vector reduction using the specified 
operator.

5)  #pragma simd assert: Directs the compiler to halt if the vectorizer is 
unable to vectorize the loop.

   The current implementation of the runtime library has been tested on x86 
(both 32 and 64 bit) architectures. In theory, the runtime library should not 
be too difficult for you to port to other architectures. However, be aware that 
access to shared variables currently assumes sequential consistency, so 
architectures that use a different memory model may require you to insert 
additional memory barriers.

   These language extensions provide a simple, well-structured, and powerful 
model for parallel programming. Intel hopes that you will find these extensions 
to be a useful and significant enhancement to the GCC C and C++ compiler. In 
this initial release, the array notations and elemental functions present in 
the full Int

RE: Adding elements into tree data structure

2011-06-07 Thread Iyer, Balaji V

Hello Ian and Everyone,
 Here is my problem specifically. I apologize in advance if this email is 
long.

I am trying to mark all for loop *top* labels with a integer value. 
This integer value is an index to another data structure that I'm trying to 
maintain. 

   I just added the index value (as unsigned int) into the following data 
structure (in tree.h):

struct GTY(()) tree_label_decl {
  struct tree_decl_with_rtl common;
  int label_decl_uid;
  int eh_landing_pad_nr;
  unsigned int My_INDEX;   /* <== THIS IS WHAT I AM TRYING TO DO */
};

I put the above modification and then I set My_INDEX in the "top" tree (top is 
created using build1(LABEL_EXPR, void_type_node, NULL_TREE)) in the 
c_finish_loop() and tried to reconfigure & build the gcc. Now, it is crashing 
when it is trying to compile the files using "prev-gcc/xgcc" (mainly at the 
gimplification phase).

I tried to gdb through the cc1 executable and did a tree dump (using 
"debug_function" and "debug_c_tree" commands when I was using gdb) and it is 
converting some labels into <<>> or .

If I comment out the line where I am setting the My_INDEX, the gcc builds and 
works correctly. I am accessing My_INDEX on top as: top->label_decl.My_INDEX

Is there any other files, functions or structures I need to modify for me to 
add and use My_INDEX? Also, am I accessing the "My_INDEX" correctly?

I am using gcc-4.6

Any help is highly appreciated!

Thanking You,

Yours Sincerely,

Balaji V. Iyer.

PS. Please CC me when you reply this message.

-Original Message-
From: Ian Lance Taylor [mailto:i...@google.com] 
Sent: Monday, May 09, 2011 7:34 PM
To: Iyer, Balaji V
Cc: gcc@gcc.gnu.org
Subject: Re: Adding elements into tree data structure

"Iyer, Balaji V"  writes:

>   I would like to add 8 integer array fields (I am also OK if they are 
> tree-lists) into the tree data structure. I want to update this fields every 
> time I see loops. This value will be used later by the optimizer. I tried to 
> just add them into the structure in tree.h (under struct tree_base) and it is 
> seg-faulting. I am using GCC 4.6.0.
>
>   Can someone please tell me the procedure for adding elements into the 
> tree structure?

Hard to say what is wrong without more information.  Make sure that
tree_code_size returns the right values.  But really I would recommend
just using the debugger to find out what is causing the segfault.

Ian

Adding elements into tree data structure

2011-05-09 Thread Iyer, Balaji V

Hello Everyone,
I would like to add 8 integer array fields (I am also OK if they are 
tree-lists) into the tree data structure. I want to update this fields every 
time I see loops. This value will be used later by the optimizer. I tried to 
just add them into the structure in tree.h (under struct tree_base) and it is 
seg-faulting. I am using GCC 4.6.0.

Can someone please tell me the procedure for adding elements into the 
tree structure?

Any help is highly appreciated!

Thanking You,

Yours Sincerely,

Balaji V. Iyer.

PS. Please CC me when replying to this message.

RE: Frame Pointer Usage

2011-04-11 Thread Iyer, Balaji V

Yes, that is what I want. Thank you!

-Balaji V. Iyer.

-Original Message-
From: Ian Lance Taylor [mailto:i...@google.com] 
Sent: Monday, April 11, 2011 4:40 PM
To: Iyer, Balaji V
Cc: gcc@gcc.gnu.org
Subject: Re: Frame Pointer Usage

"Iyer, Balaji V"  writes:

> Thanks Ian for your help. If I set the frame pointer required hook (using 
> SUBTARGET_FRAME_POINTER_REQUIRED and TARGET_FRAME_POINTER_REQUIRED) it will 
> set the frame-pointer for all the functions..am I correct?  I would like to 
> force it to use the frame-pointer for a certain functions in a program that I 
> figure out during compile time. Is there a feature to do this? If one doesn't 
> exist, then how much of a major change is this to the GCC mainline for me to 
> add this functionality?

In current gcc, the frame pointer required hook is a function
implemented in the backend.  Your backend can decide, on a
function-by-function basis, whether a frame pointer is required.  It
seems to me that that is what you want.  Please let me know if I
misunderstand.

I'm not sure why you are referring to SUBTARGET_FRAME_POINTER_REQUIRED.
A few backends define that macro, most do not.

Ian

1 2 >

1 - 100 of 103 matches

Mail list logo