Re: Question about gcc-lib and building on SPARC
On 4/13/06, Mark Cuss <[EMAIL PROTECTED]> wrote: > Hello - this is definitely a newbie question, so bear with me... > > We've been using gcc under Solaris on SPARC hardware for some time now. The > guy who was here before me set up the previous version (gcc-3.3.3) and now > I'm trying to get gcc-3.4.4 to build. > > In the old gcc-3.3.3 install tree, I have the following directory: > $prefix/lib/gcc-lib/sparc-sun-solaris2.9/3.3.3 > > gcc 3.3.3 was compiled with the following configure flags: > [EMAIL PROTECTED] mark]$ gcc -v > Reading specs from > /cdl/apps/.software/sun/gcc-3.3.3/lib/gcc-lib/sparc-sun-solaris2.9/3.3.3/specs > Configured with: > configure --with-gnu-as --with-as=/cdl/apps/bin/sun/as --with-gnu-ld > --with-ld=/cdl/apps/bin/sun/ld > --enable-langauges=c,c++ --disable-shared > --prefix=/cdl/apps/.software/sun/gcc-3.3.3 > Thread model: posix > gcc version 3.3.3 > [EMAIL PROTECTED] mark]$ > > I've successfully built and installed gcc-3.4.4 with the following configure > flags: > [EMAIL PROTECTED] bin]$ ./gcc -v > Reading specs from > /cdl/apps/.software/sun/gcc-3.4.4/bin/../lib/gcc/sparc-sun-solaris2.9/3.4.4/specs > Configured with: > /cdl/apps/.software/sun/build/gcc-3.4.4-build/gcc-3.4.4/configure > --disable-shared > --prefix=/cdl/apps/.software/sun/gcc-3.4.4/ --enable-languages=c,c++ > Thread model: posix > gcc version 3.4.4 > [EMAIL PROTECTED] bin]$ > > However, in this case, I don't have the "gcc-lib" directory anymore. When I > try to build stuff with this compiler (a simple helloworld), the linker > returns symbol errors, likely because the Sun-supplied ld and not the GNU ld > is being used (even though a GNU ld exists in my PATH) Using a different linker is going to cause many problems .So better using GNU ld. > > The obvious answer is that I didn't specify --with-gnu-ld > and --with-ld= in my gcc-3.4.4 configure. Thats the best thing to do. > I would have done this, but > our Developers need to use Purify Plus on Sun, and if I do this, it breaks > Purify because it somehow uses it's own linker at buld time. The solution > from Purify tech support was to go into > $prefix/lib/gcc-lib/sparc-sun-solaris2.9/ and drop in symbolic > links to the GNU ld and as. When I attempted to do this though, I realized > this directory doesn't seem to exist under gcc-3.4.4 Which directory doesn't exist ? Well if you built bintuils , you can point a symlink to $prefix/bin. You can find xx-as , xx-ld in that directory or in $prefix/$target/bin. I prefer you but the former . > > So, to make a painfully long story short, I need to know how gcc 3.4.4 > decides upon which linker / assembler it uses. I read the configure > instructions and found that when the compiler is built is uses a whole bunch > of rules to find as and ld, and it seems apparent that I'm using the Sun ld > and as instead of the GNU one. However, the old trick of putting symlinks > in $prefix/lib/gcc-lib/sparc-sun-solaris2.9/ doesn't work anymore. > Could someone please point a newbie in the right direction? Those are some hints . After building the crosstoolchain you find the symlinks if not that directory but some other directory. You have to do a find. Moreover for gnu ld and as you have to build binutils not gcc. > > Thanks in advance, > Mark > > Mark Cuss, B. Sc. > Software Developer > Systems Administrator > CDL Systems Ltd. > Suite 220 > 3553 31 Street NW > Calgary, AB, Canada > T2L 2K7 > > Phone 403 289 1733 ext 226 > Fax 403 289 3967 > [EMAIL PROTECTED] > www.cdlsystems.com > > >
RE: Question about gcc-lib and building on SPARC
On 12 April 2006 22:18, Mark Cuss wrote: > The > guy who was here before me set up the previous version (gcc-3.3.3) > gcc 3.3.3 was compiled with the following configure flags: > configure --with-gnu-as --with-as=/cdl/apps/bin/sun/as --with-gnu-ld > --with-ld=/cdl/apps/bin/sun/ld --enable-langauges=c,c++ --disable-shared > --prefix=/cdl/apps/.software/sun/gcc-3.3.3 > I've successfully built and installed gcc-3.4.4 with the following configure > flags: > /cdl/apps/.software/sun/build/gcc-3.4.4-build/gcc-3.4.4/configure > --disable-shared --prefix=/cdl/apps/.software/sun/gcc-3.4.4/ > --enable-languages=c,c++ > However, in this case, I don't have the "gcc-lib" directory anymore. > When I > try to build stuff with this compiler (a simple helloworld), the linker > returns symbol errors, likely because the Sun-supplied ld and not the GNU ld > is being used (even though a GNU ld exists in my PATH) I don't understand what your last guy was doing, but he's configured it to point at the sun 'as' and 'ld' but tried to tell it that they're gnu 'as' and 'ld'. Weird. Maybe he's overwritten the binaries in /cdl/apps/bin/sun with gnu versions or something odd like that. > our Developers need to use Purify Plus on Sun, and if I do this, it breaks > Purify because it somehow uses it's own linker at buld time. The solution > from Purify tech support was to go into > $prefix/lib/gcc-lib/sparc-sun-solaris2.9/ and drop in symbolic > links to the GNU ld and as. When I attempted to do this though, I realized > this directory doesn't seem to exist under gcc-3.4.4 How about $prefix/lib/gcc/sparc-sun-etc.etc.etc. ? 'gcc-lib' got changed to 'gcc' at some point between 3.3 and 3.4. > So, to make a painfully long story short, I need to know how gcc 3.4.4 > decides upon which linker / assembler it uses. I read the configure > instructions and found that when the compiler is built is uses a whole bunch > of rules to find as and ld, and it seems apparent that I'm using the Sun ld > and as instead of the GNU one. However, the old trick of putting symlinks > in $prefix/lib/gcc-lib/sparc-sun-solaris2.9/ doesn't work anymore. > Could someone please point a newbie in the right direction? Why didn't you just use the exact same configure options that worked so well for the last guy? That's the first thing I'd try. cheers, DaveK -- Can't think of a witty .sigline today
Simplification of combine patterns with subreg and zero_extract
Combine is trying to find this instruction (when compiling _popcountsi2 from libgcc2.c for my i8086 experiment): (set (subreg:QI (reg:HI 30) 0) (mem/s/u:QI (plus:HI (subreg:HI (zero_extract:SI (subreg:HI (reg/v:SI 22 [ x ]) 0) (const_int 8 [0x8]) (const_int 8 [0x8])) 0) (reg/f:HI 25)) [0 __popcount_tab S1 A8])) The part (subreg:HI (zero_extract:SI (subreg:HI (reg/v:SI 22 [ x ]) 0) (const_int 8 [0x8]) (const_int 8 [0x8])) 0) should, IMHO, be simplified to (zero_extract:HI (subreg:HI (reg/v:SI 22 [ x ]) 0) (const_int 8 [0x8]) (const_int 8 [0x8])) or perhaps (subreg:HI (zero_extract:SI (reg/v:SI 22 [ x ]) (const_int 8 [0x8]) (const_int 8 [0x8])) 0) or maybe even (zero_extract:HI (reg/v:SI 22 [ x ]) (const_int 8 [0x8]) (const_int 8 [0x8])) which seems to be the simplest way of saying "zero extend byte 1 of register 22 to 16 bits". Also, is there a function for simplifying a zero_extract? -- Rask Ingemann Lambertsen
Re: Simplification of combine patterns with subreg and zero_extract
Also, is there a function for simplifying a zero_extract? What combine is doing is to expand compound operations such as zero_extract, simplifying them, and try to make new compound operations. Therefore you should first try to understand what's causing combine to miss the simplification. However, if you add these simplifications to simplify-rtx.c, it will be picked up by combine. For example, you can add simplification of (zero_extract:M (subreg:N (something:M))) in simplify_ternary_operation, and of (subreg:M (zero_extract:N (something:M))) in simplify_subreg. Paolo
Re: Problem in function in-lining
On Thu, Apr 13, 2006 at 01:34:10PM +0800, Ching-Hua Chang wrote: > We had ported gcc-3.4.2 to our own RISC, and meet a strange > case in optimization level 3 (-O3). > > The compiler produce wrong assembly code in O3 and > correct result if we add -fno-inline flag. > > It seems that there some problem in function in-lining. > What can I do and what should I do to solve this problem ? I ran into a similar problem with function inlining on a x86->powerpc405 cross compiler with gcc-3.4.5. As you say, when you explicitly forbid inlining it works fine. I posted a couple weeks ago to the list, but never got any responses. http://gcc.gnu.org/ml/gcc/2006-04/msg00054.html mh -- Martin Hicks || [EMAIL PROTECTED] || PGP/GnuPG: 0x4C7F2BEE signature.asc Description: Digital signature
Re:question about treelang modification and debug
Seems the question has been solved, here is the changes of
treelang/parse.y, just for fun :-)
$ diff treelang/parse.y treelang/parse_new.y -u
--- treelang/parse.y2004-01-08 15:50:46.0 +0800
+++ treelang/parse_new.y2006-04-13 18:00:34.390625000 +0800
@@ -48,6 +48,7 @@
#include "tm.h"
#include "diagnostic.h"
#include "timevar.h"
+#include "tree.h"
#include "treelang.h"
#include "treetree.h"
@@ -182,7 +183,7 @@
;
variable_def:
-storage typename NAME init_opt SEMICOLON {
+storage_opt typename NAME init_opt SEMICOLON {
struct prod_token_parm_item* tok;
struct prod_token_parm_item *prod;
tok = $3;
@@ -225,6 +226,15 @@
}
;
+storage_opt:
+/* Nil. */ {
+ $$ = 0;
+}
+|storage {
+ $$ = $1;
+}
+;
+
storage:
STATIC
|AUTOMATIC
@@ -254,7 +264,7 @@
;
function_prototype:
-storage typename NAME LEFT_PARENTHESIS parameters RIGHT_PARENTHESIS SEMICOLON
+storage_opt typename NAME LEFT_PARENTHESIS parameters RIGHT_PARENTHESIS SEMIC
ON {
struct prod_token_parm_item* tok;
struct prod_token_parm_item *prod;
struct prod_token_parm_item *type;
@@ -951,6 +961,11 @@
{
struct prod_token_parm_item* stg_class;
stg_class = STORAGE_CLASS_TOKEN (prod);
+ if(stg_class==NULL_TREE)
+ {
+STORAGE_CLASS (prod) = EXTERNAL_DEFINITION_STORAGE;
+return;
+ }
switch (stg_class->type)
{
case STATIC:
Reload problem
Hi,
I had wrote doloop_end instruction to support hwloop.
When try to compile linux kernel, I meet a reload problem,
the error message as follow.
What kinds of instuction pattern should I add to support
the reload that compiler need ?
Thanks,
Aladdin
the constrant 'q' mean the non-general "counter" register
(define_expand "doloop_end"
[(use (match_operand:SI 0 "register_operand" ""))
(use (match_operand:SI 1 "const_int_operand" ""))
(use (match_operand:SI 2 "const_int_operand" ""))
(use (match_operand:SI 3 "const_int_operand" ""))
(use (label_ref (match_operand 4 "" "")))]
""
{
if(operands[3] != const1_rtx || flag_unroll_loops ||
flag_unroll_all_loops)
FAIL;
emit_jump_insn(gen_bcounter(operands[0], operands[4]));
DONE;
})
(define_insn "bcounter"
[(set(pc) (if_then_else
(ge (match_operand:SI 0 "register_operand" "=q") (const_int 0))
(label_ref (match_operand 1 "" ""))
(pc)))
(set(match_dup 0)
(plus:SI (match_dup 0)
(const_int -1)))]
""
"bcnz %1"
[(set_attr "type" "branch")])
Error message
===
panic.c: In function `panic':
panic.c:104: error: unable to generate reloads for:
(jump_insn 222 152 158 7 (parallel [
(set (pc)
(if_then_else (ge (reg:SI 5 r5 [orig:199 msec ] [199])
(const_int 0 [0x0]))
(label_ref 224)
(pc)))
(set (reg:SI 5 r5 [orig:199 msec ] [199])
(plus:SI (reg:SI 5 r5 [orig:199 msec ] [199])
(const_int -1 [0x])))
]) 0 {bcounter} (nil)
(expr_list:REG_BR_PROB (const_int 8900 [0x22c4])
(nil)))
panic.c:104: internal compiler error: in find_reloads, at reload.c:3672
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
Toolchain relocation
Hi, I've been having some odd problems with relocation of 4.x toolchains - i.e. when a toolchain is configured, built and installed with one prefix but later moved to another location. The binaries appear to be checking something in the old location before reading from the new path. The problem is only obvious on windows machines where the configured prefix is a removable medium such as a CD/DVD or memory card drive when the prebuilt toolchain is moved to a different machine. In this case a dialog box pops up asking the user to insert a disk as shown in this screenshot -> http://img159.imageshack.us/img159/9030/devkiterror3zp.jpg . When a disk is inserted everything works as it should. The error does not occur if the drive doesn't exist, is non removable media, or a disk is inserted in the drive. -print-search-dirs output from relocated toolchain, paths have been separated for clarity. It looks like some paths are being relocated but others are not. $ /c/devkitARM/bin/arm-elf-gcc -print-search-dirs install: e:/devkitPro/devkitARM/lib/gcc/arm-elf/4.1.0/ programs: = c:/devkitarm/bin/../libexec/gcc/arm-elf/4.1.0/; c:/devkitarm/bin/../libexec/gcc/; e:/devkitPro/devkitARM/libexec/gcc/arm-elf/4.1.0/; e:/devkitPro/devkitARM/libexec/gcc/arm-elf/4.1.0/; e:/devkitPro/devkitARM/libexec/gcc/arm-elf/; e:/devkitPro/devkitARM/lib/gcc/arm-elf/4.1.0/; e:/devkitPro/devkitARM/lib/gcc/arm-elf/;/usr/libexec/gcc/arm-elf/4.1.0/; /usr/libexec/gcc/arm-elf/; /usr/lib/gcc/arm-elf/4.1.0/;/usr/lib/gcc/arm-elf/; c:/devkitarm/bin/../lib/gcc/arm-elf/4.1.0/../../../../arm-elf/bin/arm-elf/4.1.0/; c:/devkitarm/bin/../lib/gcc/arm-elf/4.1.0/../../../../arm-elf/bin/; e:/devkitPro/devkitARM/arm-elf/bin/arm-elf/4.1.0/; e:/devkitPro/devkitARM/arm-elf/bin/ libraries: = c:/devkitarm/bin/../lib/gcc/arm-elf/4.1.0/; c:/devkitarm/bin/../lib/gcc/; e:/devkitPro/devkitARM/lib/gcc/arm-elf/4.1.0/; /usr/lib/gcc/arm-elf/4.1.0/; c:/devkitarm/bin/../lib/gcc/arm-elf/4.1.0/../../../../arm-elf/lib/arm-elf/4.1.0/; c:/devkitarm/bin/../lib/gcc/arm-elf/4.1.0/../../../../arm-elf/lib/; e:/devkitPro/devkitARM/arm-elf/lib/arm-elf/4.1.0/; e:/devkitPro/devkitARM/arm-elf/lib/ I can work around this for now by configuring with a c:/ prefix but is there a better way? Dave
Re: Toolchain relocation
On Thu, Apr 13, 2006 at 03:49:43PM +0100, Dave Murphy wrote: > Hi, > > I've been having some odd problems with relocation of 4.x toolchains - > i.e. when a toolchain is configured, built and installed with one prefix > but later moved to another location. The binaries appear to be checking > something in the old location before reading from the new path. How did you configure the toolchain? Which was the configured install directory and which was the relocated install directory? -- Daniel Jacobowitz CodeSourcery
A question about tree-ssa-structalias.h.
Hi Daniel and Diego, I see that tree-ssa-structalias.h contains varray_type num_references; around line 58 as a member of alias_info, but it doesn't seem to be used anywhere. Is this going to be used in near future? VARRAY is going away pretty soon, so we have to do something -- either remove the line or convert it to VEC somehow. Thanks, Kazu Hirata
Re: Toolchain relocation
Daniel Jacobowitz wrote: On Thu, Apr 13, 2006 at 03:49:43PM +0100, Dave Murphy wrote: Hi, I've been having some odd problems with relocation of 4.x toolchains - i.e. when a toolchain is configured, built and installed with one prefix but later moved to another location. The binaries appear to be checking something in the old location before reading from the new path. How did you configure the toolchain? Which was the configured install directory and which was the relocated install directory? Sorry, meant to include this with the mail. $ arm-elf-gcc -v Using built-in specs. Target: arm-elf Configured with: ../../gcc-4.1.0/configure --enable-languages=c,c++ --with-cpu=arm7tdmi --enable-interwork --enable-multilib --with-gcc --with-gnu-ld --with-gnu-as --with-stabs --disable-shared --disable-threads --disable-win32-registry --disable-nls --disable-debug --disable-libmudflap --disable-libssp --target=arm-elf --with-newlib --prefix=e:/devkitPro/devkitARM Thread model: single gcc version 4.1.0 (devkitARM release 18) configured install directory was e:/devkitPro/devkitARM, relocated to c:/devkitARM This was built with mingw ( gcc 3.4.2 ) & minsys. Dave
Re: A question about tree-ssa-structalias.h.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kazu Hirata wrote: > either remove the line or convert it to VEC somehow. > Remove it. It's now done with NUM_REFERENCES which just uses common.aux. Dan probably forgot to remove it when he converted it. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEPmx4UTa2oAUaiwQRAgThAJ0VAJl370eTA9dQo2xUhxGBq7Kx9wCfWYE4 JcAXhgW4J+WG8rLskU0Cwus= =fIkR -END PGP SIGNATURE-
Re: Toolchain relocation
On 4/13/06, Dave Murphy <[EMAIL PROTECTED]> wrote: > Daniel Jacobowitz wrote: > > On Thu, Apr 13, 2006 at 03:49:43PM +0100, Dave Murphy wrote: > > > >> Hi, > >> > >> I've been having some odd problems with relocation of 4.x toolchains - > >> i.e. when a toolchain is configured, built and installed with one prefix > >> but later moved to another location. The binaries appear to be checking > >> something in the old location before reading from the new path. > >> > > > > How did you configure the toolchain? Which was the configured install > > directory and which was the relocated install directory? > > > Sorry, meant to include this with the mail. > > > $ arm-elf-gcc -v > Using built-in specs. > Target: arm-elf > Configured with: ../../gcc-4.1.0/configure --enable-languages=c,c++ > --with-cpu=arm7tdmi --enable-interwork --enable-multilib --with-gcc > --with-gnu-ld --with-gnu-as --with-stabs --disable-shared > --disable-threads --disable-win32-registry --disable-nls --disable-debug > --disable-libmudflap --disable-libssp --target=arm-elf --with-newlib > --prefix=e:/devkitPro/devkitARM > Thread model: single > gcc version 4.1.0 (devkitARM release 18) > > configured install directory was e:/devkitPro/devkitARM, relocated to > c:/devkitARM > > This was built with mingw ( gcc 3.4.2 ) & minsys. Maybe you could do a gcc -v hello.c and see what all it is looking for and where it is searching for. > > > Dave > > >
Re: Question about gcc-lib and building on SPARC
On 12 April 2006 22:18, Mark Cuss wrote: The guy who was here before me set up the previous version (gcc-3.3.3) gcc 3.3.3 was compiled with the following configure flags: configure --with-gnu-as --with-as=/cdl/apps/bin/sun/as --with-gnu-ld --with-ld=/cdl/apps/bin/sun/ld --enable-langauges=c,c++ --disable-shared --prefix=/cdl/apps/.software/sun/gcc-3.3.3 I've successfully built and installed gcc-3.4.4 with the following configure flags: /cdl/apps/.software/sun/build/gcc-3.4.4-build/gcc-3.4.4/configure --disable-shared --prefix=/cdl/apps/.software/sun/gcc-3.4.4/ --enable-languages=c,c++ However, in this case, I don't have the "gcc-lib" directory anymore. When I try to build stuff with this compiler (a simple helloworld), the linker returns symbol errors, likely because the Sun-supplied ld and not the GNU ld is being used (even though a GNU ld exists in my PATH) I don't understand what your last guy was doing, but he's configured it to point at the sun 'as' and 'ld' but tried to tell it that they're gnu 'as' and 'ld'. Weird. Maybe he's overwritten the binaries in /cdl/apps/bin/sun with gnu versions or something odd like that. The as and ld in /cdl/apps/bin/sun are GNU as and ld, built from binutils 2.14. I must not have explained this properly - the whole mess is confusing! our Developers need to use Purify Plus on Sun, and if I do this, it breaks Purify because it somehow uses it's own linker at buld time. The solution from Purify tech support was to go into $prefix/lib/gcc-lib/sparc-sun-solaris2.9/ and drop in symbolic links to the GNU ld and as. When I attempted to do this though, I realized this directory doesn't seem to exist under gcc-3.4.4 How about $prefix/lib/gcc/sparc-sun-etc.etc.etc. ? 'gcc-lib' got changed to 'gcc' at some point between 3.3 and 3.4. That's the thing I was looking for - I need to know where to put the symlinks to the as and ld that I want to use... It looks like this did the trick - thanks! So, to make a painfully long story short, I need to know how gcc 3.4.4 decides upon which linker / assembler it uses. I read the configure instructions and found that when the compiler is built is uses a whole bunch of rules to find as and ld, and it seems apparent that I'm using the Sun ld and as instead of the GNU one. However, the old trick of putting symlinks in $prefix/lib/gcc-lib/sparc-sun-solaris2.9/ doesn't work anymore. Could someone please point a newbie in the right direction? Why didn't you just use the exact same configure options that worked so well for the last guy? That's the first thing I'd try. I did try that, but if I hardcode the assembler and linker at configure time, then this breaks Purify. This is why I need to do this symbolic link thing - apparently Purify needs this... Thanks! Mark
Re: Reload problem
Right : A way to work around this would be to hold to not match this
instruction until reload has been completed and have a define_split to
convert this to a cmp , bne when its a memory operand matching . Look at
rs6000.md or mt.md for a sample implementation.
What I am saying is the following.
1. Add an extra scratch register with a clobber pattern in your bcounter
insn .
2. Have a define_insn which matches this if the 'q' register could be
given for this .
3. Have a define_split pattern for the case where your first operand is
a memory_operand in which case you take care of loading this into a
register and then generate equivalent cmp and jmp instructions.
My 2 cents .
HTH
cheers
Ramana
On Thu, 2006-04-13 at 21:17 +0800, Ching-Hua Chang wrote:
> Hi,
> I had wrote doloop_end instruction to support hwloop.
> When try to compile linux kernel, I meet a reload problem,
> the error message as follow.
>
> What kinds of instuction pattern should I add to support
> the reload that compiler need ?
>
> Thanks,
> Aladdin
>
>
> the constrant 'q' mean the non-general "counter" register
>
> (define_expand "doloop_end"
> [(use (match_operand:SI 0 "register_operand" ""))
>(use (match_operand:SI 1 "const_int_operand" ""))
>(use (match_operand:SI 2 "const_int_operand" ""))
>(use (match_operand:SI 3 "const_int_operand" ""))
>(use (label_ref (match_operand 4 "" "")))]
> ""
> {
> if(operands[3] != const1_rtx || flag_unroll_loops ||
> flag_unroll_all_loops)
> FAIL;
> emit_jump_insn(gen_bcounter(operands[0], operands[4]));
> DONE;
> })
>
> (define_insn "bcounter"
> [(set(pc) (if_then_else
> (ge (match_operand:SI 0 "register_operand" "=q") (const_int
> 0))
> (label_ref (match_operand 1 "" ""))
> (pc)))
>(set(match_dup 0)
> (plus:SI (match_dup 0)
> (const_int -1)))]
> ""
> "bcnz %1"
> [(set_attr "type" "branch")])
>
>
> Error message
> ===
> panic.c: In function `panic':
> panic.c:104: error: unable to generate reloads for:
> (jump_insn 222 152 158 7 (parallel [
> (set (pc)
> (if_then_else (ge (reg:SI 5 r5 [orig:199 msec ] [199])
> (const_int 0 [0x0]))
> (label_ref 224)
> (pc)))
> (set (reg:SI 5 r5 [orig:199 msec ] [199])
> (plus:SI (reg:SI 5 r5 [orig:199 msec ] [199])
> (const_int -1 [0x])))
> ]) 0 {bcounter} (nil)
> (expr_list:REG_BR_PROB (const_int 8900 [0x22c4])
> (nil)))
> panic.c:104: internal compiler error: in find_reloads, at reload.c:3672
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See http://gcc.gnu.org/bugs.html> for instructions.
--
Ramana Radhakrishnan
GNU Tools
codito ergo sum (http://www.codito.com)
Re: Reload problem
On Thu, 2006-04-13 at 22:37 +0530, Ramana Radhakrishnan wrote:
> Right : A way to work around this would be to hold to not match this
> instruction until reload has been completed and have a define_split to
> convert this to a cmp , bne when its a memory operand matching . Look at
> rs6000.md or mt.md for a sample implementation.
>
> What I am saying is the following.
>
> 1. Add an extra scratch register with a clobber pattern in your bcounter
> insn .
>
> 2. Have a define_insn which matches this if the 'q' register could be
> given for this .
Oh I meant to say match the insn only after reload_completed .Add
"reload_completed" to your bcounter pattern.
>
> 3. Have a define_split pattern for the case where your first operand is
> a memory_operand in which case you take care of loading this into a
> register and then generate equivalent cmp and jmp instructions.
Do this split after reload_completed.
>
> My 2 cents .
>
> HTH
>
> cheers
> Ramana
>
> On Thu, 2006-04-13 at 21:17 +0800, Ching-Hua Chang wrote:
> > Hi,
> > I had wrote doloop_end instruction to support hwloop.
> > When try to compile linux kernel, I meet a reload problem,
> > the error message as follow.
> >
> > What kinds of instuction pattern should I add to support
> > the reload that compiler need ?
> >
> > Thanks,
> > Aladdin
> >
> >
> > the constrant 'q' mean the non-general "counter" register
> >
> > (define_expand "doloop_end"
> > [(use (match_operand:SI 0 "register_operand" ""))
> >(use (match_operand:SI 1 "const_int_operand" ""))
> >(use (match_operand:SI 2 "const_int_operand" ""))
> >(use (match_operand:SI 3 "const_int_operand" ""))
> >(use (label_ref (match_operand 4 "" "")))]
> > ""
> > {
> > if(operands[3] != const1_rtx || flag_unroll_loops ||
> > flag_unroll_all_loops)
> > FAIL;
> > emit_jump_insn(gen_bcounter(operands[0], operands[4]));
> > DONE;
> > })
> >
> > (define_insn "bcounter"
> > [(set(pc) (if_then_else
> > (ge (match_operand:SI 0 "register_operand" "=q") (const_int
> > 0))
> > (label_ref (match_operand 1 "" ""))
> > (pc)))
> >(set(match_dup 0)
> > (plus:SI (match_dup 0)
> > (const_int -1)))]
> > ""
> > "bcnz %1"
> > [(set_attr "type" "branch")])
> >
> >
> > Error message
> > ===
> > panic.c: In function `panic':
> > panic.c:104: error: unable to generate reloads for:
> > (jump_insn 222 152 158 7 (parallel [
> > (set (pc)
> > (if_then_else (ge (reg:SI 5 r5 [orig:199 msec ] [199])
> > (const_int 0 [0x0]))
> > (label_ref 224)
> > (pc)))
> > (set (reg:SI 5 r5 [orig:199 msec ] [199])
> > (plus:SI (reg:SI 5 r5 [orig:199 msec ] [199])
> > (const_int -1 [0x])))
> > ]) 0 {bcounter} (nil)
> > (expr_list:REG_BR_PROB (const_int 8900 [0x22c4])
> > (nil)))
> > panic.c:104: internal compiler error: in find_reloads, at reload.c:3672
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> > See http://gcc.gnu.org/bugs.html> for instructions.
Re: v850, dwarf2, too many fp-sp compensations?
On Tue, Apr 04, 2006 at 04:41:25PM -0400, DJ Delorie wrote: > The v850 is a dwarf-debug target, but not a dwarf-unwind target. In > dwarf2out.c we first calculate the "fp to fb offset" in > compute_frame_pointer_to_fb_displacement. The frame pointer is not > needed, so note that we include the fp-sp elimination offset in > frame_pointer_fb_offset. Note that this is the *negative* offset. > Later, when we calculate function parameter locations, we end up in > based_loc_descr(). We call eliminate_regs again, adjust for the > elimination offset, then adjust for frame_pointer_fb_offset, which > *also* includes the elimination offset: And this is the *positive* offset. > The net result is that the dwarf2 debug information is off by the > fp-sp offset. My question is: which of these adjustments isn't > supposed to happen in this case? Both are supposed to happen. I can't really debug this without a test case. This works on ia64, which is a non-dwarf-unwind target, so that in-and-of itself isn't the problem. r~
Oddity with REG_DEP_TRUE and subregs of multiword registers?
Consider the file xordi.c:
signed long long int xordi (signed long long int a, signed long long int b)
{
return (a ^ b);
}
Compile like this (GCC version 4.1.0 20060304 (Red Hat 4.1.0-3)):
/usr/bin/gcc -march=pentium2 -O3 -fomit-frame-pointer \
/mnt/sysfs/rask/cvssrc/xordi.c -S -o /tmp/xordi.s -fdump-rtl-all
Then, in /tmp/xordi.c.26.life1, I get:
[cut]
;; Start of basic block 0, registers live: 6 [bp] 7 [sp] 16 [argp] 20 [frame]
(note 10 2 6 0 [bb 0] NOTE_INSN_BASIC_BLOCK)
(insn 6 10 7 0 (set (reg/v:DI 59 [ a ])
(mem/c/i:DI (reg/f:SI 16 argp) [2 a+0 S8 A32])) 56 {*movdi_2} (nil)
(nil))
(insn 7 6 8 0 (set (reg/v:DI 60 [ b ])
(mem/c/i:DI (plus:SI (reg/f:SI 16 argp)
(const_int 8 [0x8])) [2 b+0 S8 A32])) 56 {*movdi_2} (nil)
(nil))
(note 8 7 14 0 NOTE_INSN_FUNCTION_BEG)
(insn 14 8 12 0 (clobber (reg:DI 61)) -1 (nil)
(insn_list:REG_LIBCALL 15 (nil)))
(insn 12 14 13 0 (parallel [
(set (subreg:SI (reg:DI 61) 0)
(xor:SI (subreg:SI (reg/v:DI 59 [ a ]) 0)
(subreg:SI (reg/v:DI 60 [ b ]) 0)))
(clobber (reg:CC 17 flags))
]) 235 {*xorsi_1} (insn_list:REG_DEP_TRUE 6 (insn_list:REG_DEP_TRUE 7
(insn_list:REG_DEP_TRUE 14 (nil
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_NO_CONFLICT (reg/v:DI 59 [ a ])
(expr_list:REG_NO_CONFLICT (reg/v:DI 60 [ b ])
(nil)
(insn 13 12 15 0 (parallel [
(set (subreg:SI (reg:DI 61) 4)
(xor:SI (subreg:SI (reg/v:DI 59 [ a ]) 4)
(subreg:SI (reg/v:DI 60 [ b ]) 4)))
(clobber (reg:CC 17 flags))
]) 235 {*xorsi_1} (insn_list:REG_DEP_TRUE 12 (nil))
(expr_list:REG_DEAD (reg/v:DI 59 [ a ])
(expr_list:REG_DEAD (reg/v:DI 60 [ b ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_NO_CONFLICT (reg/v:DI 59 [ a ])
(expr_list:REG_NO_CONFLICT (reg/v:DI 60 [ b ])
(nil)))
[cut]
I don't understand why insn 13 is supposed to have a dependency on insn 12.
There is no overlap between the subregs. I would have thought that insn 13
should have a dependency on insn 6, 7 and possibly 14, like insn 12.
Am I simply misunderstanding the purpose of (undocumented) REG_DEP_TRUE?
--
Rask Ingemann Lambertsen
Re: v850, dwarf2, too many fp-sp compensations?
> Both are supposed to happen. I can't really debug this without a
> test case. This works on ia64, which is a non-dwarf-unwind target,
> so that in-and-of itself isn't the problem.
This is from the gdb.base testsuite:
int factorial (int value)
{
if (value > 1) { /* set breakpoint 7 here */
value *= factorial (value - 1);
}
return (value); /* set breakpoint 19 here */
}
./cc1 -quiet -gdwarf-2 -fomit-frame-pointer dj.c -o dj.s
v850-elf-gcc -c dj.s
v850-elf-readelf -wio dj.o
v850-elf-objdump -d dj.o
<1><60>: Abbrev Number: 2 (DW_TAG_subprogram)
. . .
DW_AT_frame_base : 1 byte block: 53 (DW_OP_reg3)
<2><81>: Abbrev Number: 3 (DW_TAG_formal_parameter)
. . .
DW_AT_location: 2 byte block: 91 0 (DW_OP_fbreg: 0)
Which indicates the parameter is at 0[sp]. However...
<_factorial>:
0: 03 1e ec ff addi-20, sp, sp
4: 63 ff 11 00 st.wlp, 16[sp]
8: 63 37 15 00 st.wr6, 20[sp]
c: 23 57 15 00 ld.w20[sp],r10
10: 61 52 cmp 1, r10
...the parameter is *really* in 20[sp].
RE: Problem in function in-lining
On 13 April 2006 13:37, Martin Hicks wrote: > On Thu, Apr 13, 2006 at 01:34:10PM +0800, Ching-Hua Chang wrote: >> We had ported gcc-3.4.2 to our own RISC, and meet a strange >> case in optimization level 3 (-O3). >> >> The compiler produce wrong assembly code in O3 and >> correct result if we add -fno-inline flag. >> >> It seems that there some problem in function in-lining. >> What can I do and what should I do to solve this problem ? > > I ran into a similar problem with function inlining on a x86->powerpc405 > cross compiler with gcc-3.4.5. As you say, when you explicitly forbid > inlining it works fine. There's really no reason to assume it's the same bug. Inlining a function has /vast/ knock-on effects and can expose all sorts of bugs in function calling, sibcalls, CSE, etc. etc. etc; disabling inlining seems to 'cure' the bug but you can't deduce that inlining itself is the problem, it's just that with inlining you get greater complexity in the generated code, greater pressure on register allocation, and so more scope for things that haven't been properly stress-tested to fail. > I posted a couple weeks ago to the list, but never got any responses. > http://gcc.gnu.org/ml/gcc/2006-04/msg00054.html > > mh I'm afraid that's probably because your question was terribly vague. "Does the wrong thing", with no explanation, demonstration, or testcase, is not exactly anything anyone can help you with, so the answer to your question "Does anyone have any ideas what this bug is?" is "No, nobody could possibly guess from that little information", and the answer to "Is there an open bug?" is "Why don't you look in bugzilla yourself?" cheers, DaveK -- Can't think of a witty .sigline today
RE: Oddity with REG_DEP_TRUE and subregs of multiword registers?
On 13 April 2006 18:52, Rask Ingemann Lambertsen wrote:
> Consider the file xordi.c:
>
> signed long long int xordi (signed long long int a, signed long long int b)
> {
> return (a ^ b);
> }
> (insn 6 10 7 0 (set (reg/v:DI 59 [ a ])
> (mem/c/i:DI (reg/f:SI 16 argp) [2 a+0 S8 A32])) 56 {*movdi_2} (nil)
> (nil))
>
> (insn 7 6 8 0 (set (reg/v:DI 60 [ b ])
> (mem/c/i:DI (plus:SI (reg/f:SI 16 argp)
> (const_int 8 [0x8])) [2 b+0 S8 A32])) 56 {*movdi_2} (nil)
> (nil))
> (insn 14 8 12 0 (clobber (reg:DI 61)) -1 (nil)
> (insn_list:REG_LIBCALL 15 (nil)))
>
> (insn 12 14 13 0 (parallel [
> (set (subreg:SI (reg:DI 61) 0)
> (xor:SI (subreg:SI (reg/v:DI 59 [ a ]) 0)
> (subreg:SI (reg/v:DI 60 [ b ]) 0)))
> (clobber (reg:CC 17 flags))
> ]) 235 {*xorsi_1} (insn_list:REG_DEP_TRUE 6 (insn_list:REG_DEP_TRUE
> 7 (insn_list:REG_DEP_TRUE 14 (nil (expr_list:REG_UNUSED (reg:CC 17
> flags) (expr_list:REG_NO_CONFLICT (reg/v:DI 59 [ a ])
> (expr_list:REG_NO_CONFLICT (reg/v:DI 60 [ b ])
> (nil)
>
> (insn 13 12 15 0 (parallel [
> (set (subreg:SI (reg:DI 61) 4)
> (xor:SI (subreg:SI (reg/v:DI 59 [ a ]) 4)
> (subreg:SI (reg/v:DI 60 [ b ]) 4)))
> (clobber (reg:CC 17 flags))
> ]) 235 {*xorsi_1} (insn_list:REG_DEP_TRUE 12 (nil))
> (expr_list:REG_DEAD (reg/v:DI 59 [ a ])
> (expr_list:REG_DEAD (reg/v:DI 60 [ b ])
> (expr_list:REG_UNUSED (reg:CC 17 flags)
> (expr_list:REG_NO_CONFLICT (reg/v:DI 59 [ a ])
> (expr_list:REG_NO_CONFLICT (reg/v:DI 60 [ b ])
> (nil)))
> I don't understand why insn 13 is supposed to have a dependency on insn 12.
> There is no overlap between the subregs. I would have thought that insn 13
> should have a dependency on insn 6, 7 and possibly 14, like insn 12.
>
> Am I simply misunderstanding the purpose of (undocumented) REG_DEP_TRUE?
I can't say either, since I don't know much about dependency tracking, but
one thing jumps out at me: insn 13 couldn't have all those REG_DEAD notes on
it unless it was /somehow/ guaranteed that insn 12 won't get scheduled after
it, because they kill the whole DImode register, which is to say both of the
SImode hard regs to which it gets allocated, and it would be bad if only half
of the move had been completed at that time!
So my guess is it's a design compromise because it's too tricky to track the
lives of the subreg parts of the DImode values independently.
cheers,
DaveK
--
Can't think of a witty .sigline today
Re: Problem in function in-lining
On Thu, Apr 13, 2006 at 07:32:39PM +0100, Dave Korn wrote: > On 13 April 2006 13:37, Martin Hicks wrote: > > > On Thu, Apr 13, 2006 at 01:34:10PM +0800, Ching-Hua Chang wrote: > >> We had ported gcc-3.4.2 to our own RISC, and meet a strange > >> case in optimization level 3 (-O3). > >> > >> The compiler produce wrong assembly code in O3 and > >> correct result if we add -fno-inline flag. > >> > >> It seems that there some problem in function in-lining. > >> What can I do and what should I do to solve this problem ? > > > > I ran into a similar problem with function inlining on a x86->powerpc405 > > cross compiler with gcc-3.4.5. As you say, when you explicitly forbid > > inlining it works fine. > > There's really no reason to assume it's the same bug. Inlining a function > has /vast/ knock-on effects and can expose all sorts of bugs in function > calling, sibcalls, CSE, etc. etc. etc; disabling inlining seems to 'cure' the > bug but you can't deduce that inlining itself is the problem, it's just that > with inlining you get greater complexity in the generated code, greater > pressure on register allocation, and so more scope for things that haven't > been properly stress-tested to fail. Okay, that's fine. Inlining exposes the bug. > > > I posted a couple weeks ago to the list, but never got any responses. > > http://gcc.gnu.org/ml/gcc/2006-04/msg00054.html > > > > mh > > I'm afraid that's probably because your question was terribly vague. "Does > the wrong thing", with no explanation, demonstration, or testcase, is not > exactly anything anyone can help you with, so the answer to your question Hmm...perhaps I posted the URL to my one reply to the thread and that confused you. If you had looked at the reference post you would see the piece of code that failed along with disassembly of the inlined and non-inlined version. mh -- Martin Hicks || [EMAIL PROTECTED] || PGP/GnuPG: 0x4C7F2BEE
Re: Problem in function in-lining
On Apr 12, 2006, at 10:34 PM, Ching-Hua Chang wrote:
We had ported gcc-3.4.2 to our own RISC, and meet a strange
case in optimization level 3 (-O3).
We don't have the resources to help with very old versions of gcc on
this list. I'd recommend upgrading to gcc-4.2. If it then works,
you can then compare the old and new compilers to see how the do
things differently and what you need to backport to fix the problem.
It seems that there some problem in function in-lining.
What can I do and what should I do to solve this problem?
There is a process called debugging that can be used to solve the
problem. First step, -da, and then identify the pass that produces
the wrong result. Then, find that pass in the code, then, set a
breakpoint at the start of that pass and step forward until you find
the bug. You can use the insn UIDs to help narrow the search.
Note, that process doesn't work for things that aren't bugs of
course. In this case, I suspect there isn't actually a bug in the
compiler. I suspect, it is doing exactly what you told it to do.
SemiHostedSyscall ();
has no arguments, no inputs and no outputs. If you need help writing
C code, that's beyond the scope of this list. Briefly, to pass three
arguments, you'd need:
SemiHostedSyscall (fd, buf, nbytes);
Another way might be to put:
@item noinline
@cindex @code{noinline} function attribute
This function attribute prevents a function from being considered for
inlining.
on _write.
Re: Oddity with REG_DEP_TRUE and subregs of multiword registers?
Rask Ingemann Lambertsen <[EMAIL PROTECTED]> writes:
> (insn 12 14 13 0 (parallel [
> (set (subreg:SI (reg:DI 61) 0)
> (xor:SI (subreg:SI (reg/v:DI 59 [ a ]) 0)
> (subreg:SI (reg/v:DI 60 [ b ]) 0)))
> (clobber (reg:CC 17 flags))
> ]) 235 {*xorsi_1} (insn_list:REG_DEP_TRUE 6 (insn_list:REG_DEP_TRUE 7
> (insn_list:REG_DEP_TRUE 14 (nil
> (expr_list:REG_UNUSED (reg:CC 17 flags)
> (expr_list:REG_NO_CONFLICT (reg/v:DI 59 [ a ])
> (expr_list:REG_NO_CONFLICT (reg/v:DI 60 [ b ])
> (nil)
>
> (insn 13 12 15 0 (parallel [
> (set (subreg:SI (reg:DI 61) 4)
> (xor:SI (subreg:SI (reg/v:DI 59 [ a ]) 4)
> (subreg:SI (reg/v:DI 60 [ b ]) 4)))
> (clobber (reg:CC 17 flags))
> ]) 235 {*xorsi_1} (insn_list:REG_DEP_TRUE 12 (nil))
> (expr_list:REG_DEAD (reg/v:DI 59 [ a ])
> (expr_list:REG_DEAD (reg/v:DI 60 [ b ])
> (expr_list:REG_UNUSED (reg:CC 17 flags)
> (expr_list:REG_NO_CONFLICT (reg/v:DI 59 [ a ])
> (expr_list:REG_NO_CONFLICT (reg/v:DI 60 [ b ])
> (nil)))
> [cut]
>
> I don't understand why insn 13 is supposed to have a dependency on insn 12.
> There is no overlap between the subregs. I would have thought that insn 13
> should have a dependency on insn 6, 7 and possibly 14, like insn 12.
The dependency code does not track subregs independently. It only
tracks entire registers. Insn 13 only sets part of register 61;
therefore it reads register 61. And insn 12 writes register 61.
Therefore insn 13 has a read-after-write dependency on insn 12.
Yes, subregs should be handled better. I have some work in progress
which may help.
> Am I simply misunderstanding the purpose of (undocumented) REG_DEP_TRUE?
REG_DEP_TRUE is documented, sort of, in reg-notes.def.
Ian
gcc-4.0-20060413 is now available
Snapshot gcc-4.0-20060413 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20060413/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.0 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_0-branch revision 112930 You'll find: gcc-4.0-20060413.tar.bz2 Complete GCC (includes all of below) gcc-core-4.0-20060413.tar.bz2 C front end and core compiler gcc-ada-4.0-20060413.tar.bz2 Ada front end and runtime gcc-fortran-4.0-20060413.tar.bz2 Fortran front end and runtime gcc-g++-4.0-20060413.tar.bz2 C++ front end and runtime gcc-java-4.0-20060413.tar.bz2 Java front end and runtime gcc-objc-4.0-20060413.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.0-20060413.tar.bz2The GCC testsuite Diffs from 4.0-20060406 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.0 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: v850, dwarf2, too many fp-sp compensations?
The problem appears to be that you've got *partial* debug_frame information, but it's wrong. I'm not 100% clear on what's the First Cause on the wrongness. I will say that I suspect that we probably want to just say that any target that doesn't provide DWARF2_UNWIND_INFO or TARGET_UNWIND_INFO with the appropriate dwarf2 callbacks, is simply broken and needs to be fixed. Even if that is 22 targets, because those 22 targets aren't going to be tested regularly, and the 8 that do support unwind info are. Oh, I see, DWARF2_FRAME_INFO defaults to on, despite the setting of DWARF2_UNWIND_INFO. So things are already as I suggested. You'll simply have to fix up the port such that the information for DWARF2_FRAME_INFO isn't wrong. r~
Re: question about treelang modification and debug
"Eric Fisher" <[EMAIL PROTECTED]> writes:
> Seems the question has been solved, here is the changes of
> treelang/parse.y, just for fun :-)
>
> $ diff treelang/parse.y treelang/parse_new.y -u
> --- treelang/parse.y2004-01-08 15:50:46.0 +0800
> +++ treelang/parse_new.y2006-04-13 18:00:34.390625000 +0800
> @@ -48,6 +48,7 @@
> #include "tm.h"
> #include "diagnostic.h"
> #include "timevar.h"
> +#include "tree.h"
>
> #include "treelang.h"
> #include "treetree.h"
> @@ -182,7 +183,7 @@
> ;
>
> variable_def:
> -storage typename NAME init_opt SEMICOLON {
> +storage_opt typename NAME init_opt SEMICOLON {
>struct prod_token_parm_item* tok;
>struct prod_token_parm_item *prod;
>tok = $3;
Don't you have to deal with $1 being NULL?
> @@ -225,6 +226,15 @@
> }
> ;
>
> +storage_opt:
> +/* Nil. */ {
> + $$ = 0;
> +}
> +|storage {
> + $$ = $1;
> +}
> +;
> +
> storage:
> STATIC
> |AUTOMATIC
> @@ -254,7 +264,7 @@
> ;
>
> function_prototype:
> -storage typename NAME LEFT_PARENTHESIS parameters RIGHT_PARENTHESIS SEMICOLON
>
> +storage_opt typename NAME LEFT_PARENTHESIS parameters RIGHT_PARENTHESIS SEMIC
> ON {
>struct prod_token_parm_item* tok;
>struct prod_token_parm_item *prod;
>struct prod_token_parm_item *type;
> @@ -951,6 +961,11 @@
> {
>struct prod_token_parm_item* stg_class;
>stg_class = STORAGE_CLASS_TOKEN (prod);
> + if(stg_class==NULL_TREE)
> + {
> +STORAGE_CLASS (prod) = EXTERNAL_DEFINITION_STORAGE;
> +return;
> + }
>switch (stg_class->type)
> {
> case STATIC:
>
--
Thanks,
Jim
http://www.csclub.uwaterloo.ca/~ja2morri/
http://phython.blogspot.com
http://open.nit.ca/wiki/?page=jim
Re: Toolchain relocation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dave Murphy wrote: > > I've been having some odd problems with relocation of 4.x toolchains - > i.e. when a toolchain is configured, built and installed with one prefix > but later moved to another location. The binaries appear to be checking > something in the old location before reading from the new path. I might be mistaken, but I think this is intentional behaviour. FWIW, I have faced a different toolchain relocation problem in the GCC 4.1.0 release on MinGW. I configured and built GCC using "--prefix=/mingw" on one machine where "/mingw" maps to "D:\MiscAppz\MinGW" (I used MSYS as the build environment). The compiler built, installed and ran fine on this machine. However, when I moved the binaries to another machine where MinGW was installed in "D:\MinGW", the compiler was not able to find the C runtime headers, even though the folder structure was exactly the same. It was however able to find executables from binutils like as, ld, etc. I worked around this problem temporarily by just specifying the system include path explicitly in the CFLAGS of my programme's build script. There was another curious problem with this GCC, even on the original machine where it was built: when run from within the MSYS environment, everything was hunky-dory but when run from the Windows command prompt, it used to give a "_spawnvp: No such file or directory" error when one tried to compile something. Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA. Web: http://rmathew.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEPzXHYb1hx2wRS48RAgR1AJ4lR9FmGojMA27egIqWwkn6EK/UVwCdFJcj q/oVB2PgULlWz0DEHUZgrQ8= =iUfR -END PGP SIGNATURE-
