Getting a virtual functions VT lookup index

[Brendon Costa]

Hi all,

How can I find a FUNCTION_DECL node from a CALL_EXPR node for virtual
function calls?

Note: I am not after the node for the function that will be executed
at runtime as I know this is not possible to determine in most
situations.


Thanks for any help in advance,
Brendon.



---
I have tried the following:

When I encounter a CALL_EXPR for a virtual function call, I can get
the index for the virtual function table from the OBJ_TYPE_REF object
operand: 2 is an INTEGER_CST that seems to have a different index for
the various virtual functions.

However I need to find the FUNCTION_DECL node that is associated with
a particular type with the given virtual function table index.

For example if I have a index value of: 1 that I have obtained from
the OBJ_TYPE_REF node operand 2 I can also get the METHOD_TYPE node
and thus get the RECORD_TYPE node for the object.

How can I find the FUNCTION_DECL node given the virtual table index of
the function and the classes RECORD_TYPE node?

* I have tried using class.c: get_vcall_index() but it seems to return
negative integers.

* I have also looked in the TYPE_BINFO with the BINFO_VIRTUALS for the
BV_CALL_INDEX but that is NULL.

* I have also tried using CLASSTYPE_VCALL_INDICES and all these have
failed to give me a value that seems correct.

Re: Issue with hard regs

[Rask Ingemann Lambertsen]

On Mon, Oct 16, 2006 at 02:03:44PM +0300, [EMAIL PROTECTED] wrote:
> I thought i had added the necessary information (new register classes, 
> character
> to match for the reg class) however i get the following error message:
> 
> "unable to find a register to spill in class"

   Please provide more information, such as the list of reload for the insn.
There could be a number of reasons for a reload failure, some more obvious
than others. The least obvious one I've come across (just a few days ago) is
an unfortunate specification of CLASS_MAX_NREGS(), causing reloads to be
sorted in the wrong order (see reload_reg_class_lower() in reload.c),
thereby exhausting a small register class.

> Can i disable filling/spilling for this register class?

-ffixed-name_of_register

-- 
Rask Ingemann Lambertsen

Re: Abt RTL expression

[Rask Ingemann Lambertsen]

On Mon, Oct 16, 2006 at 09:32:58PM -0700, Mohamed Shafi wrote:
> 
> In th document 
> http://gcc.gnu.org/onlinedocs/gccint/Insns.html#Insns
> 
> it is said that "An integer that says which pattern in the machine 
> description matches
> this insn, or -1 if the matching has not yet been attempted.Such matching is 
> never attempted and this field remains -1 on an insn
> whose pattern consists of a single use, clobber "
> 
> The integer in my pattern is -1. In fact integer for all the insn for a 
> program (980602-2.c) like 

   It is quite normal for the first 6-7 dump files. It is because matching
has not yet been attempted.

-- 
Rask Ingemann Lambertsen

[cygwin] gcc/boehm-gc/misc.c:680: undefined reference to `_GC_get_thread_stack_base'

[Christian Joensson]

well, trying to bootstrap on cygwin current gcc with lava and libs,
gets me into this

ar rc .libs/libgcj-tools.a  classpath/tools/libgcj_tools_la-tools.o
ranlib .libs/libgcj-tools.a
creating libgcj-tools.la
(cd .libs && rm -f libgcj-tools.la && ln -s ../libgcj-tools.la libgcj-tools.la)
/bin/sh ./libtool --tag=GCJ --mode=link
/usr/local/src/trunk/objdir/gcc/gcj
-B/usr/local/src/trunk/objdir/i686-pc-cygwin/libjava/
-B/usr/local/src/trunk/objdir/gcc/
-L/usr/local/src/trunk/objdir/i686-pc-cygwin/libjava -ffloat-store
-fomit-frame-pointer -g -O2  -o jv-convert.exe
--main=gnu.gcj.convert.Convert -rpath
/usr/local/lib/gcc/i686-pc-cygwin/4.2.0 -shared-libgcc
-L/usr/local/src/trunk/objdir/i686-pc-cygwin/libjava/.libs libgcj.la
/usr/local/src/trunk/objdir/gcc/gcj
-B/usr/local/src/trunk/objdir/i686-pc-cygwin/libjava/
-B/usr/local/src/trunk/objdir/gcc/ -ffloat-store -fomit-frame-pointer
-g -O2 -o jv-convert.exe --main=gnu.gcj.convert.Convert -shared-libgcc
-L/usr/local/src/trunk/objdir/i686-pc-cygwin/libjava
-L/usr/local/src/trunk/objdir/i686-pc-cygwin/libjava/.libs
./.libs/libgcj.a
-L/usr/local/src/trunk/objdir/i686-pc-cygwin/libstdc++-v3/src
-L/usr/local/src/trunk/objdir/i686-pc-cygwin/libstdc++-v3/src/.libs
-ldl -lz -L/usr/local/src/trunk/objdir/./gcc -L/usr/local/lib -lgcc
-lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc
./.libs/libgcj.a(misc.o): In function `GC_init_inner':
/usr/local/src/trunk/objdir/i686-pc-cygwin/boehm-gc/../../../gcc/boehm-gc/misc.c:680:
undefined reference to `_GC_get_thread_stack_base'
collect2: ld returned 1 exit status
make[3]: *** [jv-convert.exe] Error 1
make[3]: Leaving directory `/usr/local/src/trunk/objdir/i686-pc-cygwin/libjava'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/usr/local/src/trunk/objdir/i686-pc-cygwin/libjava'
make[1]: *** [all-target-libjava] Error 2
make[1]: Leaving directory `/usr/local/src/trunk/objdir'
make: *** [bootstrap] Error 2

Any idea on what this would be about? tls related?
--
Cheers,

/ChJ

Re: Abt RTL expression

[Mohamed Shafi]

> It is because matching has not yet been attempted.

ok.. so what is the option to get hold of a rtl dump after all the matching is 
done

- Original Message 
From: Rask Ingemann Lambertsen <[EMAIL PROTECTED]>
To: Mohamed Shafi <[EMAIL PROTECTED]>
Cc: gcc@gcc.gnu.org; Revital1 Eres <[EMAIL PROTECTED]>
Sent: Tuesday, October 17, 2006 1:21:30 PM
Subject: Re: Abt RTL expression

On Mon, Oct 16, 2006 at 09:32:58PM -0700, Mohamed Shafi wrote:
> 
> In th document 
> http://gcc.gnu.org/onlinedocs/gccint/Insns.html#Insns
> 
> it is said that "An integer that says which pattern in the machine 
> description matches
> this insn, or -1 if the matching has not yet been attempted.Such matching is 
> never attempted and this field remains -1 on an insn
> whose pattern consists of a single use, clobber "
> 
> The integer in my pattern is -1. In fact integer for all the insn for a 
> program (980602-2.c) like 

   It is quite normal for the first 6-7 dump files. It is because matching
has not yet been attempted.

-- 
Rask Ingemann Lambertsen

Re: g++ -print-prefix or -print-install-prefix

[Benjamin Kosnik]

> Why do you need this?  For installed-compiler testing, the compiler 
> already searches the obvious places.  (I'm not trying to be cute: I'm 
> genuinely curious.)

This is needed if you need to find the C++ includes, but are not using
the C++ compiler.

> I agree that it would be nice if -print-search-dirs listed include 
> directories.  It already lists the paths searched for programs and 
> libraries, so that seems like a logical place to add header directories.

Yep. Mostly, I was just curious: it seemed like an omission.

-benjamin

Re: Abt RTL expression

[Rask Ingemann Lambertsen]

On Tue, Oct 17, 2006 at 01:10:02AM -0700, Mohamed Shafi wrote:
> > It is because matching has not yet been attempted.
> 
> ok.. so what is the option to get hold of a rtl dump after all the matching 
> is done

   -fdump-rtl-vregs, although if you want to see the prologue and epilogue
code too, -fdump-rtl-rnreg.

-- 
Rask Ingemann Lambertsen

Re: [PATCH] COND_EXPRs in GIMPLE code and vectorizer

[Roberto COSTA]

Roberto COSTA wrote:

Diego Novillo wrote:


Roberto COSTA wrote on 09/28/06 05:51:


If time allows me, I'd like to try to see what happens if COND_EXPRs 
are kept throughout the GIMPLE passes (I confess I'm curious). 
Logically, I see them as richer constructs (they carry more 
information than the equivalent control-flow code), like MIN_EXPRs 
and MAX_EXPRs.




Be wary of VRP and thread jumping if you do this.  Both rely on the
current COND_EXPR format quite heavily.



Before committing into anything, I will study the implications on these 
in order to evaluate the effort needed.


I've recently spent some time to study how vrp, dom and jump threading 
work; such implications are now clear to me.
I don't know yet how to solve them in the hypothesis that as many 
COND_EXPRs as possible are kept throughout the GIMPLE passes.


In the meantime, there are a few changes I made to some of the 
middle-end passes that I think are useful even when the gimplifier 
expands COND_EXPR expressions (the current behavior).
Basically, such passes currently handle COND_EXPR nodes only as 
statements and they may miss optimization opportunities in the presence 
of COND_EXPR expressions.

The following patch extends them to support COND_EXPR expressions.

I succesfully bootstrapped all languages on my i686 machine, with no 
regressions.


Comments?

Cheers,
Roberto
2006-10-17  Roberto Costa  <[EMAIL PROTECTED]>

* tree-vrp.c (extract_range_from_cond_expr): New.
(extract_range_from_expr): Handle COND_EXPR nodes used as expressions.
* fold-const.c (fold_cond_expr_with_comparison): Bug fix, avoid
infinite recursion when folding COND_EXPRs.
* tree-ssa-ccp.c (get_maxval_strlen): Handle COND_EXPR nodes
used as expressions.
* tree-ssa-forwprop.c (simplify_cond, forward_propagate_into_cond,
tree_ssa_forward_propagate_single_use_vars): Handle COND_EXPR nodes
used as expressions.
* tree-object-size.c (cond_expr_object_size): New.
(collect_object_sizes_for): Handle COND_EXPR nodes used as expressions.

Index: gcc/tree-vrp.c
===
--- gcc/tree-vrp.c  (revision 117639)
+++ gcc/tree-vrp.c  (working copy)
@@ -43,6 +43,7 @@ static sbitmap found_in_subgraph;
 
 /* Local functions.  */
 static int compare_values (tree val1, tree val2);
+static void vrp_meet (value_range_t *, value_range_t *);
 
 /* Location information for ASSERT_EXPRs.  Each instance of this
structure describes an ASSERT_EXPR for an SSA name.  Since a single
@@ -1947,6 +1948,40 @@ extract_range_from_unary_expr (value_ran
 }
 
 
+/* Extract range information from a conditional expression EXPR based on
+   the ranges of each of its operands and the expression code.  */
+
+static void
+extract_range_from_cond_expr (value_range_t *vr, tree expr)
+{
+  tree op0, op1;
+  value_range_t vr0 = { VR_UNDEFINED, NULL_TREE, NULL_TREE, NULL };
+  value_range_t vr1 = { VR_UNDEFINED, NULL_TREE, NULL_TREE, NULL };
+
+  /* Get value ranges for each operand.  For constant operands, create
+ a new value range with the operand to simplify processing.  */
+  op0 = COND_EXPR_THEN (expr);
+  if (TREE_CODE (op0) == SSA_NAME)
+vr0 = *(get_value_range (op0));
+  else if (is_gimple_min_invariant (op0))
+set_value_range (&vr0, VR_RANGE, op0, op0, NULL);
+  else
+set_value_range_to_varying (&vr0);
+
+  op1 = COND_EXPR_ELSE (expr);
+  if (TREE_CODE (op1) == SSA_NAME)
+vr1 = *(get_value_range (op1));
+  else if (is_gimple_min_invariant (op1))
+set_value_range (&vr1, VR_RANGE, op1, op1, NULL);
+  else
+set_value_range_to_varying (&vr1);
+
+  /* The resulting value range is the union of the operand ranges */
+  vrp_meet (&vr0, &vr1);
+  copy_value_range (vr, &vr0);
+}
+
+
 /* Extract range information from a comparison expression EXPR based
on the range of its operand and the expression code.  */
 
@@ -1988,6 +2023,8 @@ extract_range_from_expr (value_range_t *
 extract_range_from_binary_expr (vr, expr);
   else if (TREE_CODE_CLASS (code) == tcc_unary)
 extract_range_from_unary_expr (vr, expr);
+  else if (code == COND_EXPR)
+extract_range_from_cond_expr (vr, expr);
   else if (TREE_CODE_CLASS (code) == tcc_comparison)
 extract_range_from_comparison (vr, expr);
   else if (is_gimple_min_invariant (expr))
Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 117639)
+++ gcc/fold-const.c(working copy)
@@ -4626,9 +4626,14 @@ fold_cond_expr_with_comparison (tree typ
 switch (comp_code)
   {
   case EQ_EXPR:
-   /* We can replace A with C1 in this case.  */
-   arg1 = fold_convert (type, arg01);
-   return fold_build3 (COND_EXPR, type, arg0, arg1, arg2);
+/* Avoid infinite recursion */
+if (TREE_CODE (arg1) != INTEGER_CST)
+  {
+/* We can replace A with C1 in this case.

Building gcc-4.2 failure on MinGW

[Y.Tomino]

Hello.

gcc-4.2-20061007 and gcc-4.2-20061014 failed to build on MinGW.
Does anybody see the same and understand?
I used the options for configure that was --prefix=/mingw and 
--enabled-languages.

My platform is WindowsXP, with MinGW and MSYS.

Thank you.

YT

Case 1, C only:

...
/home/usr/build/./prev-gcc/xgcc -B/home/usr/build/./prev-gcc/ 
-B/mingw/i686-pc-m
ingw32/bin/ -c   -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings 
-Wstrict-prototypes
-Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros 
-Wno-overleng
th-strings -Wold-style-definition -Wmissing-format-attribute -Werror 
-fno-common
   -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.2-20061014/gcc 
-I../../gcc-4.2-20061014
/gcc/. -I../../gcc-4.2-20061014/gcc/../include -I./../intl 
-I../../gcc-4.2-20061
014/gcc/../libcpp/include  -I../../gcc-4.2-20061014/gcc/../libdecnumber 
-I../lib
decnumber../../gcc-4.2-20061014/gcc/tree-pretty-print.c -o 
tree-pretty-print

.o
cc1.exe: warnings being treated as errors
../../gcc-4.2-20061014/gcc/tree-pretty-print.c: In function 
'dump_bb_header':
../../gcc-4.2-20061014/gcc/tree-pretty-print.c:2652: ｷﾙｹ・ ISO C ､ﾏ the 
'I' prin

tf flag ､ｱﾉﾕ､ｱ､ﾞ､ｻ､
../../gcc-4.2-20061014/gcc/tree-pretty-print.c:2652: ｷﾙｹ・ format 
'%I64d' expect

s type 'int', but argument 3 has type 'gcov_type'
make[3]: *** [tree-pretty-print.o] Error 1
make[3]: Leaving directory `/home/usr/build/gcc'
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory `/home/usr/build'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/home/usr/build'
make: *** [all] Error 2

Maybe, I think that hwint.h is a cause.
For ad-hoc correction, insert these #undef/#define to the end of hwint.h.

#undef HOST_WIDE_INT
#define HOST_WIDE_INT long long
#undef HOST_WIDEST_INT_PRINT_DEC
#define HOST_WIDEST_INT_PRINT_DEC "%lld"

And restart make.

...
/home/usr/build/./prev-gcc/xgcc -B/home/usr/build/./prev-gcc/ 
-B/mingw/i686-pc-m
ingw32/bin/ -c   -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings 
-Wstrict-prototypes
-Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros 
-Wno-overleng
th-strings -Wold-style-definition -Wmissing-format-attribute -Werror 
-fno-common
   -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild 
-I../../gcc-4.2-20061014/gcc -I.
./../gcc-4.2-20061014/gcc/build -I../../gcc-4.2-20061014/gcc/../include 
-I./../i
ntl -I../../gcc-4.2-20061014/gcc/../libcpp/include 
-I../../gcc-4.2-20061014/gcc
/../libdecnumber -I../libdecnumber-o build/genmodes.o 
../../gcc-4.2-20061014

/gcc/genmodes.c
../../gcc-4.2-20061014/gcc/genmodes.c:1: internal compiler error: in 
stabstr_O,

at dbxout.c:754
ｴｰﾁｴ､ﾊ･ﾐ･ｰﾊﾃ､ﾆｲｼ､ｵ､､｡｣
ﾅｬﾀﾚ､ﾊ､鬢ﾐ･ﾗ･・ﾗ･愠ｻ･ｹｸ螟ﾎ･ｽ｡ｼ･ｹ､ﾄ､ｱ､ﾆ､ｯ､ﾀ､ｵ､､｡｣
http://gcc.gnu.org/bugs.html> ､ｫ､・ﾐﾊﾋ｡､ｬｽ､､ﾆ､｢､熙ﾞ､ｹ｡｣
make[3]: *** [build/genmodes.o] Error 1
make[3]: Leaving directory `/home/usr/build/gcc'
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory `/home/usr/build'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/home/usr/build'
make: *** [all] Error 2

An internal compiler error.

As for the reason for the garbage characters, the character-code is 
different.

It seems EUC-Code, but Windows-console can not display it.

Case 2, including Ada:

When --enable-languages=c,ada, the making process stopped short of Case 1.

...
gnatbind -C -I- -I. -Iada -I../../gcc-4.2-20061014/gcc/ada -o 
ada/b_gnat1.c -n a

da/gnat1drv.ali
fatal error: file gnat1drv.ali is incorrectly formatted
make sure you are using consistent versions of gcc/gnatbind
10.
 |
make[3]: *** [ada/b_gnat1.c] Error 4
make[3]: Leaving directory `/home/usr/build/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/home/usr/build'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/home/usr/build'
make: *** [all] Error 2

Maybe, it should use (/mingw)/bin/gnatbind, instead of gnatbind in 
current building directory.

generation of gt-*.h files

[Basile STARYNKEVITCH]

Dear All,

I'm still a newbie, and do not understand very well the machinery behind the
GCC garbage collector, in particular the following behavior on a recently
svn update-ed GCC trunk. My system is an AMD64/Debian/Sid


cd /usr/src/Lang/gcc # my trunk
svn info

Path: .
URL: svn://gcc.gnu.org/svn/gcc/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 117825
Node Kind: directory
Schedule: normal
Last Changed Author: bkoz
Last Changed Rev: 117825
Last Changed Date: 2006-10-17 14:53:40 +0200 (Tue, 17 Oct 2006)

mkdir ../_GccObj
cd ../_GccObj
/usr/src/Lang/gcc/configure  --disable-multilib --enable-languages=c,c++
make -j4 
## lots of output, compilation is successful
ls -l gcc/xgcc
-rwxr-xr-x 1 basile src 539143 Oct 17 15:51 gcc/xgcc
ls -l gcc/gt-tree-ssa-operands.h
-rw-r--r-- 1 basile src 1086 Oct 17 15:49 gcc/gt-tree-ssa-operands.h
mv gcc/gt-tree-ssa-operands.h /tmp
## I removed a generated header (for GC support within GCC)
### 
make[2]: Entering directory `/usr/src/Lang/_TrunkGccObj/gcc'
gcc -c   -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes 
-Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute 
-fno-common   -DHAVE_CONFIG_H -I. -I. -I/usr/src/Lang/gcc/gcc 
-I/usr/src/Lang/gcc/gcc/. -I/usr/src/Lang/gcc/gcc/../include 
-I/usr/src/Lang/gcc/gcc/../libcpp/include  
-I/usr/src/Lang/gcc/gcc/../libdecnumber -I../libdecnumber
/usr/src/Lang/gcc/gcc/tree-ssa-operands.c -o tree-ssa-operands.o
/usr/src/Lang/gcc/gcc/tree-ssa-operands.c:2571:34: error: 
gt-tree-ssa-operands.h: No such file or directory

Why is the gt-tree-ssa-operands.h not rebuilt if removed?

More generally, I have trouble adding a pass basile-analys.c (which does
nothing useful yet) which includes its header basile-analys.h which contains
struct-ures with GTY(()) so I need to have gt-basile-analys.h generated from
basile-analys.h

If you really want to dive into my sources (nothing interesting yet, I'm
still earning Gcc with some pain), you could get them from
http://ours.starynkevitch.net/basile/ggcc-basile.tgz (but this is a home
computer on ADSL) - this is an archive of all the source files I added or
changed to the GCC trunk


Regards

-- 
Basile STARYNKEVITCH http://starynkevitch.net/Basile/ 
email: basilestarynkevitchnet 
aliases: basiletunesorg = bstarynknerimnet
8, rue de la Faïencerie, 92340 Bourg La Reine, France

build error

[bob_rossi]

Hi,

I just ran these commands:

svn -q checkout svn://gcc.gnu.org/svn/gcc/trunk gcc
mkdir builddir
cd builddir
CFLAGS="-g" ../gcc/configure --enable-languages=c,c++ --enable-checking \
 --disable-bootstrap --prefix=$PWD/../prefixdir
make -s
make install

and I got the attached compile error. Is this a known issue on an
Althlon64 processor? Are there any work arounds?

Thanks,
Bob Rossimake[1]: Entering directory `/home/bob/source/svn/gcc/builddir'
make[2]: Entering directory `/home/bob/source/svn/gcc/builddir/libiberty'
make[3]: Entering directory 
`/home/bob/source/svn/gcc/builddir/libiberty/testsuite'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory 
`/home/bob/source/svn/gcc/builddir/libiberty/testsuite'
make[2]: Leaving directory `/home/bob/source/svn/gcc/builddir/libiberty'
make[2]: Entering directory `/home/bob/source/svn/gcc/builddir/fixincludes'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/bob/source/svn/gcc/builddir/fixincludes'
make[2]: Entering directory `/home/bob/source/svn/gcc/builddir/intl'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/bob/source/svn/gcc/builddir/intl'
make[2]: Entering directory 
`/home/bob/source/svn/gcc/builddir/build-x86_64-unknown-linux-gnu/libiberty'
make[3]: Entering directory 
`/home/bob/source/svn/gcc/builddir/build-x86_64-unknown-linux-gnu/libiberty/testsuite'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory 
`/home/bob/source/svn/gcc/builddir/build-x86_64-unknown-linux-gnu/libiberty/testsuite'
make[2]: Leaving directory 
`/home/bob/source/svn/gcc/builddir/build-x86_64-unknown-linux-gnu/libiberty'
make[2]: Entering directory 
`/home/bob/source/svn/gcc/builddir/build-x86_64-unknown-linux-gnu/fixincludes'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory 
`/home/bob/source/svn/gcc/builddir/build-x86_64-unknown-linux-gnu/fixincludes'
make[2]: Entering directory `/home/bob/source/svn/gcc/builddir/libcpp'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/bob/source/svn/gcc/builddir/libcpp'
make[2]: Entering directory `/home/bob/source/svn/gcc/builddir/libdecnumber'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/bob/source/svn/gcc/builddir/libdecnumber'
make[2]: Entering directory `/home/bob/source/svn/gcc/builddir/gcc'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/bob/source/svn/gcc/builddir/gcc'
Checking multilib configuration for libstdc++-v3...
Checking multilib configuration for libiberty...
make[2]: Entering directory 
`/home/bob/source/svn/gcc/builddir/x86_64-unknown-linux-gnu/libiberty'
make[3]: Entering directory 
`/home/bob/source/svn/gcc/builddir/x86_64-unknown-linux-gnu/libiberty/testsuite'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory 
`/home/bob/source/svn/gcc/builddir/x86_64-unknown-linux-gnu/libiberty/testsuite'
make[3]: Entering directory 
`/home/bob/source/svn/gcc/builddir/x86_64-unknown-linux-gnu/libiberty'
if [ -z "32" ]; then \
  true; \
else \
  rootpre=`${PWDCMD-pwd}`/; export rootpre; \
  srcrootpre=`cd ../../../gcc/libiberty; ${PWDCMD-pwd}`/; export 
srcrootpre; \
  lib=`echo ${rootpre} | sed -e 's,^.*/\([^/][^/]*\)/$,\1,'`; \
  compiler="/home/bob/source/svn/gcc/builddir/./gcc/xgcc 
-B/home/bob/source/svn/gcc/builddir/./gcc/ 
-B/home/bob/source/svn/gcc/builddir/../prefixdir/x86_64-unknown-linux-gnu/bin/ 
-B/home/bob/source/svn/gcc/builddir/../prefixdir/x86_64-unknown-linux-gnu/lib/ 
-isystem 
/home/bob/source/svn/gcc/builddir/../prefixdir/x86_64-unknown-linux-gnu/include 
-isystem 
/home/bob/source/svn/gcc/builddir/../prefixdir/x86_64-unknown-linux-gnu/sys-include";
 \
  for i in `${compiler} --print-multi-lib 2>/dev/null`; do \
dir=`echo $i | sed -e 's/;.*$//'`; \
if [ "${dir}" = "." ]; then \
  true; \
else \
  if [ -d ../${dir}/${lib} ]; then \
flags=`echo $i | sed -e 's/^[^;]*;//' -e 's/@/ -/g'`; \
if (cd ../${dir}/${lib}; make "AR=ar" "AR_FLAGS=rc" 
"CC=/home/bob/source/svn/gcc/builddir/./gcc/xgcc 
-B/home/bob/source/svn/gcc/builddir/./gcc/ 
-B/home/bob/source/svn/gcc/builddir/../prefixdir/x86_64-unknown-linux-gnu/bin/ 
-B/home/bob/source/svn/gcc/builddir/../prefixdir/x86_64-unknown-linux-gnu/lib/ 
-isystem 
/home/bob/source/svn/gcc/builddir/../prefixdir/x86_64-unknown-linux-gnu/include 
-isystem 
/home/bob/source/svn/gcc/builddir/../prefixdir/x86_64-unknown-linux-gnu/sys-include"
 "CFLAGS=-O2 -g " "DESTDIR=" "LIBCFLAGS=-O2 -g " "EXTRA_OFILES=" "HDEFINES=" 
"INSTALL=/usr/bin/install -c" "INSTALL_DATA=/usr/bin/install -c -m 644" 
"INSTALL_PROGRAM=/usr/bin/install -c" "LDFLAGS=" "LOADLIBES=" "RANLIB=ranlib" 
"SHELL=/bin/sh" "prefix=/home/bob/source/svn/gcc/builddir/../prefixdir" 
"exec_prefix=/home/bob/source/svn/gcc/builddir/../prefixdir" 
"libdir=/home/bob/source/svn/gcc/builddir/../prefixdir/lib"

Re: How can a front-end know what integer mode corresponds to int_fastN_t?

[Tobias Schlüter]

FX Coudert <[EMAIL PROTECTED]> wrote on Mon, 16 Oct 2006:

For Fortran 2003 standard conformance, the Fortran front-end has to
know at compile-time what integer mode corresponds to some C99 types,
like intmax_t, intN_t, int_leastN_t, int_fastN_t.

For intN_t and int_leastN_t, I can see how to get them by looking at
the width of the different integer modes. For intmax_t, it is defined
in c-common.h as:

#define INTMAX_TYPE ((INT_TYPE_SIZE == LONG_LONG_TYPE_SIZE) \
 ? "int"\
 : ((LONG_TYPE_SIZE == LONG_LONG_TYPE_SIZE) \
? "long int"\
: "long long int"))

But I cannot see how the front-end can know the integer mode for
int_leastN_t. We're likely to include this functionality for the 4.3
release, so I'll be happy to get a large number of suggestions around
on how to implement that.



The code in trans-types.c already matches Fortran types to C types, so  
you might get some inspiration there.


- Tobi


This message was sent using IMP, the Internet Messaging Program.

Expressions simplification statistic

[Dino Puller]

Hi all,
  i'm looking for a statistic of how many expressions simplification
may be possible on source code, for example in some linux project.
Otherwise how can i produce a statistic like that?

tnx,
  Dino

Compiling with profiling flags

[Revital1 Eres]

Hello,

Is there an option to change the name of the .gcno file that is generated
by using profiling
flags like -fprofile-generate and later used by -fprofile-use?
I read that "For each source file compiled with `-fprofile-arcs', an
accompanying
 `.gcda' file will be placed in the object file directory. " - Can I change
it such that
the .gcda will be named as I wish?

Thanks

"insn outside basic block" in custom back end

[Frank Riese]

Hi,

I have the following problem with a back end I've written after the following 
changes in the machine header, to tell GCC that the machine is word-addressed 
with a word width of 16 Bit:

#define BITS_PER_UNIT   16
#define UNITS_PER_WORD  1
#define BITS_PER_WORD   16

After that, I get the following error, even with simple programs. E.g:

int foo (int i) {
return i;
}

$ gcc-zykluno-none -S -c foo.c

function8.c: In function 'foo':
function8.c:3: error: insn outside basic block
(insn 28 20 29 (set (reg/f:QI 20)
(subreg:QI (reg:HI 18) 0)) 3 {movqi} (nil)
(nil))
function8.c:3: internal compiler error: in rtl_verify_flow_info, at 
cfgrtl.c:2065

No code is output at all. I have a custom funtion to output the function 
prologue but the compiler does not even get that far to call it.

I have searched through the sources for quite some time but haven't been able 
to fix it. Does anyone know a solution or the cause of that error? 

I was not sure what other information I should provide. If anything else is 
needed to trace this error to its root, please ask.

Frank

r117741

[Jack Howarth]

Geoff,
   I noticed that the automake maintainers
accepted your patch for fixing the multilib
issues in automake. However they also seemed
to indicate that there would be no more 1.9.x
automake releases.
   Is the r117741 svn checkin related to this
issue? I ask because it was unclear to me how
the multilib issues with gcc could be resolved
until a new automake was released with the
required patch (so that it could be used to
regenerate the necessary configure files in
gcc trunk). Thanks in advance for any
clarifications.
  Jack

Re: r117741

[David Fang]

>I noticed that the automake maintainers accepted your patch for
> fixing the multilib issues in automake. However they also seemed to
> indicate that there would be no more 1.9.x automake releases.
>Is the r117741 svn checkin related to this issue? I ask because it
> was unclear to me how the multilib issues with gcc could be resolved
> until a new automake was released with the required patch (so that it
> could be used to regenerate the necessary configure files in gcc
> trunk). Thanks in advance for any clarifications.

Hi,

Not sure if you noticed, but automake-1.10 was released two days
ago, on the 15th.  The announcement made no mention of multilib issues in
the summary, so you might have to dig through revision logs to hunt for
the patch.

>8 snip 8<-
You can find the new release here:

ftp://ftp.gnu.org/gnu/automake/automake-1.10.tar.gz
ftp://ftp.gnu.org/gnu/automake/automake-1.10.tar.gz.sig
ftp://ftp.gnu.org/gnu/automake/automake-1.10.tar.bz2
ftp://ftp.gnu.org/gnu/automake/automake-1.10.tar.bz2.sig
ftp://sources.redhat.com/pub/automake/automake-1.10.tar.gz
ftp://sources.redhat.com/pub/automake/automake-1.10.tar.gz.sig
ftp://sources.redhat.com/pub/automake/automake-1.10.tar.bz2
ftp://sources.redhat.com/pub/automake/automake-1.10.tar.bz2.sig

Finally, here are the MD5 checksums:

0e2e0f757f9e1e89b66033905860fded  automake-1.10.tar.bz2
452163c32d061c53a7acc0e8c1b689ba  automake-1.10.tar.gz
>8 snip 8<-


Fang

Re: Issue with hard regs

[Nikolaos Kavvadias]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
Hi Ian and fellow GCC'ers

thanks for the info. Compiling "libgcc2.c" for MIPS (-mips1) works OK,
I mean "divdi3" produces correct results.

I'll get back to this in a couple of hours (at my home PC), but i
think i had overseen something important here.
I was coding the DLX backend based on one for nios-2 (very nice
single/double float emulation routines there; they
have written their own). However, both the nios2 backend and an old
DLX backend that i used for reference
(for GCC-2.7.2.3) didn't include patterns for 64-bit moves (like the
MIPS "movdi"). Due to this and some other
observations, I tend to think that neither backend (of these two) was
ever tested for "double" integer arithmetic.

Thus, 64-bit integer arithmetic does not work on my processor and this
is due to the fact that i have not included
patterns (or code emission routines in "dlx.c") for handling 64-bit
moves. Am I missing something else here
(not in detail but any coarse grained info)?

thanks in advance

Nikolaos Kavvadias
PS: libgcc2.{c,h} looks OK, both gcc-3.4.1 and current CVS versions
(actually 16-Oct-06  version)


Ian Lance Taylor wrote:

> Right, libgcc2.c is quite stable.
>
> In a normal build it is the first complicated code to be compiled
> with the new compiler, so it is a normal place for reload problems
> to arise.
>
> Ian


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
 
iD8DBQFFNSgpMPiy0tCWlz4RAs0uAJ0Y5rGfP27Gbbo2wtXq5u8TKF31WwCeLbZA
55TgLRUnr4yWd+KLE7A2Yyc=
=MR8j
-END PGP SIGNATURE-

Re: Proposed semantics for attributes in C++ (and in C?)

[Mark Mitchell]

Geoffrey Keating wrote:


A typedef declaration which adds semantic attributes to a non-class
type is valid, but again creates an entirely new type. 


>> It is invalid to

do anything that would require either type_info or a mangled name for
"Q", including using it as an argument to typeid, thowing an exception
of a type involving "Q", or declaring a template to take a parameter
of a type involving "Q".  (We could relax some of these restrictions
in future, if we add mangling support for attributes.)


Declaring a function which takes a 'Q' also requires the mangled name of 'Q'.


Good point!


where T is some invented type name different from all others in the program.

For example given:

   __attribute__((packed)) S v;

the type of "&v" is "__attribute__((packed)) S *", and cannot be
passed to a function expecting an "S*", but can of course be passed to
a function expecting an "__attribute__((packed)) S *", or a typedef
for such a type.


... except that there can't be any such functions.  You could assign
it to another variable of the same type, or a field of a class with
that type.


Right.  And, since there seems to be consensus that you shouldn't be 
able to apply semantic attributes to class types, "packed" is a bad 
example there too.  (If you applied "packed" at the point of declaration 
of "S", then "S" has a different layout than it otherwise would, but we 
don't need to do anything regarding mangling, etc.)


Thanks,

--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: generation of gt-*.h files

[Mike Stump]

On Oct 17, 2006, at 7:07 AM, Basile STARYNKEVITCH wrote:

mv gcc/gt-tree-ssa-operands.h /tmp


/usr/src/Lang/gcc/gcc/tree-ssa-operands.c:2571:34: error: gt-tree- 
ssa-operands.h: No such file or directory


Patient: Doctor, it hurts when I hit myself in the head.
Doctor: Don't do that.


Why is the gt-tree-ssa-operands.h not rebuilt if removed?


The Makefile contains the answer to your question.  Hint, see the s-*  
rules and the rules with gtype in them.


More generally, I have trouble adding a pass basile-analys.c (which  
does
nothing useful yet) which includes its header basile-analys.h which  
contains
struct-ures with GTY(()) so I need to have gt-basile-analys.h  
generated from

basile-analys.h


Check to ensure that it is in GTFILES in Makefile.in.

Re: Expressions simplification statistic

[Mike Stump]

On Oct 17, 2006, at 8:05 AM, Dino Puller wrote:

i'm looking for a statistic of how many expressions simplification
may be possible on source code


One way would be:

  http://www.cs.fit.edu/~mmahoney/compression/text.html

though, this assumes a particular definition of simplification.  For  
other definitions, gcc doesn't just tell you an answer, you'd have to  
define what you think a simplification is and then instrument gcc to  
provide that answer.  This would be lots of hard work at best.

Re: r117741

[Geoffrey Keating]

On 17/10/2006, at 11:45 AM, Jack Howarth wrote:


Geoff,
   I noticed that the automake maintainers
accepted your patch for fixing the multilib
issues in automake. However they also seemed
to indicate that there would be no more 1.9.x
automake releases.
   Is the r117741 svn checkin related to this
issue? I ask because it was unclear to me how
the multilib issues with gcc could be resolved
until a new automake was released with the
required patch (so that it could be used to
regenerate the necessary configure files in
gcc trunk). Thanks in advance for any
clarifications.


Hi Jack,

I believe all this was covered in my message to gcc-patches relating  
to that checkin.




smime.p7s
Description: S/MIME cryptographic signature

Help with openGL

[gbiaki]

Hey folks, 

I have just downloaded the openGL libs through cygwin/setup.exe
Included in the package are example programs which I would like to get
running before continuing development. I'm no expert with gcc so I gues I'm
probably doingsomething dumbass wrong.
When I run make from within the example progs folder (cygwin on WIN32 by the
way) the build falls over complaining that it cant find the definitions for
the references to the openGL functions, i.e. I dont think it can find the
library.

Any clues?

Cheers
Ian
-- 
View this message in context: 
http://www.nabble.com/Help-with-openGL-tf2462089.html#a6863598
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: r117741

[Andrew Pinski]

> On 17/10/2006, at 11:45 AM, Jack Howarth wrote:
> 
> > Geoff,
> >I noticed that the automake maintainers
> > accepted your patch for fixing the multilib
> > issues in automake. However they also seemed
> > to indicate that there would be no more 1.9.x
> > automake releases.
> >Is the r117741 svn checkin related to this
> > issue? I ask because it was unclear to me how
> > the multilib issues with gcc could be resolved
> > until a new automake was released with the
> > required patch (so that it could be used to
> > regenerate the necessary configure files in
> > gcc trunk). Thanks in advance for any
> > clarifications.
> 
> Hi Jack,
> 
> I believe all this was covered in my message to gcc-patches relating  
> to that checkin.

Except it got lost because of a typo in the spam filter, see:
http://gcc.gnu.org/ml/gcc/2006-10/msg00316.html

-- Pinski

Re: r117741

[Geoffrey Keating]

On 17/10/2006, at 1:39 PM, Andrew Pinski wrote:


On 17/10/2006, at 11:45 AM, Jack Howarth wrote:


Geoff,
   I noticed that the automake maintainers
accepted your patch for fixing the multilib
issues in automake. However they also seemed
to indicate that there would be no more 1.9.x
automake releases.
   Is the r117741 svn checkin related to this
issue? I ask because it was unclear to me how
the multilib issues with gcc could be resolved
until a new automake was released with the
required patch (so that it could be used to
regenerate the necessary configure files in
gcc trunk). Thanks in advance for any
clarifications.


Hi Jack,

I believe all this was covered in my message to gcc-patches relating
to that checkin.


Except it got lost because of a typo in the spam filter, see:
http://gcc.gnu.org/ml/gcc/2006-10/msg00316.html


That's a shame, because I don't remember everything I said.  I've re- 
sent the patch and maybe that will help answer Jack's question.




smime.p7s
Description: S/MIME cryptographic signature

Re: build error

[Brian Dessent]

Consider posting this kind of question to gcc-help@ instead.

[EMAIL PROTECTED] wrote:

> I just ran these commands:
> 
> svn -q checkout svn://gcc.gnu.org/svn/gcc/trunk gcc
> mkdir builddir
> cd builddir
> CFLAGS="-g" ../gcc/configure --enable-languages=c,c++ --enable-checking \
>  --disable-bootstrap --prefix=$PWD/../prefixdir
> make -s
> make install
> 
> and I got the attached compile error. Is this a known issue on an
> Althlon64 processor? Are there any work arounds?

I don't think it has anything to do with your processor, but the fact
that your build directory is a subdirectory of the source tree is
generally a no-no.  See .

Brian

Re: r117741

[Jack Howarth]

Geoff,
Should gcc/doc/install.texi be changed now to require
automake version 1.10 or later rather than the current
1.9.3?
   Jack

On Tue, Oct 17, 2006 at 12:36:21PM -0700, Geoffrey Keating wrote:
> 
> Hi Jack,
> 
> I believe all this was covered in my message to gcc-patches relating  
> to that checkin.
> 

Re: Help with openGL

[Mike Stump]

On Oct 17, 2006, at 1:32 PM, gbiaki wrote:

I have just downloaded the openGL libs through cygwin/setup.exe


Wrong list.  Try the cygwin list instead.



Sent from the gcc - Dev mailing list archive at Nabble.com.


:-(

How can I put gcc on NCR MP-RAS with no ncr compiler?

[Saul Krasny]

Hi,

I need to put up a cc development environment on an MCR SVR4 MP RAS unix. 
The machines I have don't have any c compiler except the hidden one the os 
build uses.


How can I go about this? Is there a place to download a prebuilt version. 
(What else will I need? for example make)


Any help would be greatly appreciated.

Saul Krasny
[EMAIL PROTECTED]
508 992 0620

Re: r117741

[Joseph S. Myers]

On Tue, 17 Oct 2006, Jack Howarth wrote:

> Geoff,
> Should gcc/doc/install.texi be changed now to require
> automake version 1.10 or later rather than the current
> 1.9.3?

Upgrading the version of automake used will require upgrading the version 
of autoconf used.  Because of the changes in installation directories and 
the addition of new configure options and directory variables, this 
requires careful planning and coordination between GCC and src.  (This is 
definitely a matter for 4.3, not 4.2.)

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: r117741

[Jack Howarth]

Geoff,
The repost answers my questions. I was wondering if
the changes required the new automake and if so whether
they could be undone if someone regenerated those
configure files with a version of automake before
1.10? It would appear that's not the case.
  Jack

98, it is! (was: C++ PATCH: PR 28261)

[Gerald Pfeifer]

On Tue, 17 Oct 2006, Mark Mitchell wrote:
> This patch fixes PR c++/28261, an ICE-on-invalid when an
> enum-definition appeared in an constructor parmeter declaration.

Unless I'm mistaken, this means we are down to less than 100 serious 
regressions!

(Richi has been giving me the current number twice a day recently, I
guess he'll open a big bottle of $BEVERAGE now. :-)

Gerald

Re: r117741

[Geoffrey Keating]

On 17/10/2006, at 3:27 PM, Jack Howarth wrote:


Geoff,
Should gcc/doc/install.texi be changed now to require
automake version 1.10 or later rather than the current
1.9.3?


No.


   Jack

On Tue, Oct 17, 2006 at 12:36:21PM -0700, Geoffrey Keating wrote:


Hi Jack,

I believe all this was covered in my message to gcc-patches relating
to that checkin.








smime.p7s
Description: S/MIME cryptographic signature

Re: How can I put gcc on NCR MP-RAS with no ncr compiler?

[Mike Stump]

On Oct 17, 2006, at 3:12 PM, Saul Krasny wrote:
I need to put up a cc development environment on an MCR SVR4 MP RAS  
unix. The machines I have don't have any c compiler except the  
hidden one the os build uses.


How can I go about this?


Build a cross compiler.  See the web site on how to build one.  This  
assumes that the software you're interested in building has been  
ported.  If not, first, port the software, then build it.  Once you  
have a cross compiler, then just build up gcc, install it, copy the  
binaries over, and presto, you then have a native build system on your  
box.


Is there a place to download a prebuilt version. (What else will I  
need? for example make)


Nope, not that we know of.  You'd need to venture someplace that has  
software for your box to find binaries.  Google might be able to find  
a binary for you, ask him.

Donna Arellano wrote:

[Donna Arellano]

hi Donna i hope this is your mailbox.
I was pleased to meet you the other day. I expect you was excited about   New 
York.
So much so much happening all the time, lots of great opportunities.  
And speaking of opportunities, the deal I was speaking you about other day 
embraces a company 
known as Tex-Homa (TXHE).
It's already growing up, but the big news isn't even 
out yet, so there's still time. I have got this shares already and made
2000. I counsel you to do the same today.

Hope this helps you out.  I'll see you this weekend.
Yours Donna Arellano

GCC 4.2/4.3 Status Report (2006-10-17)

[Mark Mitchell]

As Gerald noticed, there are now fewer than 100 serious regressions open 
against mainline, which means that we've met the criteria for creating 
the 4.2 release branch.  (We still have 17 P1s, so we've certainly got 
some work left to do before creating a 4.2 release, and I hope people 
will continue to work on them so that we can get 4.2 out the door in 
relatively short order.)


The SC has reviewed the primary/secondary platform list, and approved it 
unchanged, with the exception of adding S/390 GNU/Linux as a secondary 
platform.  I will reflect that in the GCC 4.3 criteria.html page when I 
create it.


In order to allow people to organize themselves for Stage 1, I'll create 
the branch, and open mainline as Stage 1, at some point on Friday, 
October 20th.  Between now and then, I would like to see folks negotiate 
amongst themselves to get a reasonable order for incorporating patches.


See:

  http://gcc.gnu.org/ml/gcc/2006-09/msg00454.html

I've also reviewed the projects listed here:

  http://gcc.gnu.org/wiki/GCC_4.3_Release_Planning

The variadic templates project is in limbo, I'm afraid.  The SC doesn't 
seem to have a clear opinion on even the general C++ policy discussed on 
the lists, which means that Jason, Nathan, and I have to talk about 
variadic templates and work out what to do.


IMA for C++ is another difficult case.  This is unambiguously useful, 
though duplicative of what we're trying to build with LTO.  That's not a 
bad thing, since LTO is clearly at least one more release cycle away, 
and IMA might be ready sooner.  On the other hand, if the IMA changes 
were disruptive to the C++ front end in general, then that might be a 
problem.  I guess we just have to evaluate the patch, when it's ready.


--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Why does GCC allow '$' character in variable and function names?

[Sajish V]

I think that C does not allow special characters ( '~' '!' '@' '#' '$' '%' '^' 
'&' '*' ) in variable and function names. My knowledge is purely based on the 
books that I have been reading to learn C.

To verify this when I tried to compile a C program using GCC with '$' in 
variable names and function names I found that GCC does not complain. No errors 
or warnings. 

I used the basic command with no option to compile. 

bash$ gcc 

Can someone please let me know why GCC allows '$' character in variable and 
function names?

Thanks.

Re: Why does GCC allow '$' character in variable and function names?

[Ian Lance Taylor]

Sajish V <[EMAIL PROTECTED]> writes:

> I think that C does not allow special characters ( '~' '!' '@' '#' '$' '%' 
> '^' '&' '*' ) in variable and function names. My knowledge is purely based on 
> the books that I have been reading to learn C.
> 
> To verify this when I tried to compile a C program using GCC with '$' in 
> variable names and function names I found that GCC does not complain. No 
> errors or warnings. 
> 
> I used the basic command with no option to compile. 
> 
> bash$ gcc 
> 
> Can someone please let me know why GCC allows '$' character in variable and 
> function names?

The C99 standard permits identifiers to contain implementation defined
characters.  See section 6.4.2.1.  The standard does this to permit
implementations to support identifiers written in languages which
require characters which do not appear in English, such as 'ñ' or 'ö'.

gcc permits '$' as an implementation defined character.  It does this
mainly for historical reasons.

Ian

expand_omp_parallel typo?

[Marcin Dalecki]

Looking at the function expand_omp_parallel in omp-low.c I have found  
the following line of code:


  bsi_insert_after (&si, t, TSI_SAME_STMT);

Shouldn't this bee

  bsi_insert_after (&si, t, BSI_SAME_STMT);

instead?

Marcin Dalecki