Known regression ? gcc-4.0.0-20050312 FPE's on C++
Hi. I'm just asking if this is a known bug. If not I'll prepare a bug report, with bzipped preprocessed source. I'm seeing this: hpm05fuvec0.cpp:5538: internal compiler error: Floating point exception Please submit a full bug report, quite often when compiling large chunks of machine-generated C++. gcc-3.4.3 works fine on the same testcases. The compiler is: $ gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../../sources/gcc-4.0-20050312/configure --enable-languages=c,c++ --enable-__cxa_atexit --disable-checking --disable-nls --prefix=/usr/local/gcc/gcc-4.0-20050312 Thread model: posix gcc version 4.0.0 20050312 (prerelease) The compiler was bootstrapped with gcc-3.4.3 I can have another go without the "--disable-checking" if that's likely to help. Anything else you'd like in the bug report ? gcc-4 is a lot faster at compiling templatey C++ than 3.4.3, but the compiled code performance is sometimes better, sometimes worse. It's a bit hard to tell, since our big testcases currently ICE with FPE's on gcc-4.0. Regards, John.
help regarding ld
hi, i am using the arm-elf-gcc compiler to generate the assembly code arm-elf-gcc -mthumb -S new.c after this i use the arm-elf-as for genrating machine code arm-elf-as new.s it produces one a.out file.. arm-elf-ld a.out produces error like arm-elf-ld: warning: cannot find entry symbol _start; not setting start address how do i type the correct command line option for this thanks in advance -- __ Check out the latest SMS services @ http://www.linuxmail.org This allows you to send and receive SMS through your mailbox. Powered by Outblaze
Re: Known regression ? gcc-4.0.0-20050312 FPE's on C++
John Vickers <[EMAIL PROTECTED]> wrote: > I can have another go without the "--disable-checking" if that's > likely to help. Anything else you'd like in the bug report ? Please submit the smallest preprocessed source you can machine-generate which shows the bug. Thanks! Giovanni Bajo
Re: help regarding ld
Hi Aram, i am using the arm-elf-gcc compiler to generate the assembly code arm-elf-gcc -mthumb -S new.c after this i use the arm-elf-as for genrating machine code arm-elf-as new.s Note - these two steps could be combined into one by using the -c switch instead of the -S switch: arm-elf-gcc -mthumb -c new.c it produces one a.out file.. Note: Despite its name this "a.out" file is not an executable program it is just an object file that still needs to be linked. Naming the file a.out is a "feature" of the assembler. arm-elf-ld a.out produces error like arm-elf-ld: warning: cannot find entry symbol _start; not setting start address how do i type the correct command line option for this Try using gcc to control the entire process from compilation to final link, like this: arm-elf-gcc new.c Cheers Nick
Re: Suggestion for a fix to Bug middle-end/20177
James E Wilson <[EMAIL PROTECTED]> wrote on 18/03/2005 07:43:55: > > You either have to keep all REG_NOTES up to date, or call code that will > recompute them. You can recompute REG_DEAD/REG_UNUSED notes by calling > back into flow. This is presumably what happens when you mark the block > dirty, so that would be a sufficient solution for REG_DEAD/REG_UNUSED. > Thanks for the information, what we were doing was to call update_life_info_in_dirty_blocks, but for some reason this wasn't sufficient to mark a register dead (REG_DEAD note) when the register was defined in a predecessor block and dies in the dirty block; we had to call update_life_info for all the blocks to mark that register as dead. Is there cases that we know about that such case could happen? is this means a bug in update_life_info ? Thanks, Mostafa.
Re: reload question
BTW, if anybody replies, could you keep me in the CC: header? I do read this list, but it won't be convenient in the next few days. Thanks, -Miles -- .Numeric stability is probably not all that important when you're guessing.
Re: Questions about trampolines
Robert Dewar wrote: Joern RENNECKE wrote: You need to be able to set the value of a parameter over a widely varying range, what makes you think you can pick two values that will cover all cases, or 4 or 6 for that matter. It will likely cover most, but not all cases. With 12 values, you can cover the range from 64 to 1073741824 pool entries, if you allow for up to four times more entries to be provided than actually desired. In order to allow to specify the exact size of the pool, you can provide the source of the library that implements it, and have the application programmer compile it with a -D flag which determines the desired size of the pool. This can also be driven by a specs file so that all the programmer does is supply one option with a numerical parameter during 'linking'.
Re: Questions about trampolines
Joern RENNECKE wrote: You need to be able to set the value of a parameter over a widely varying range, what makes you think you can pick two values that will cover all cases, or 4 or 6 for that matter. In order to allow to specify the exact size of the pool, you can provide the source of the library that implements it, and have the application programmer compile it with a -D flag which determines the desired size of the pool. This can also be driven by a specs file so that all the programmer does is supply one option with a numerical parameter during 'linking'. Right, but 12 separate libraries to accomodae 12 separate values is not a reasonable approach. Expecting people to recompile from sources is also not a reasonable approach in a production environment since such recompilation would require revalidation. For me, the whole approach is ugly anyway, and I would follow a quite different path, as I have indicated in prior messages.
Merge to tree-profiling
Hi, I did merge to tree profiling yesterday and committing to the tree didn't went correctly, so tree was messed up till today. So if something breaks for you, please just update and hopefully everything will be OK now. Honza
Strange build errors compiling SPEC with mainline
Starting around 2005-03-17, I haven't been able to compile several SPEC tests with mainline. Has there been any change in the pre-processor that might explain these errors? I'm pretty sure my installation is correct because this worked until 2005-03-15, the system header files are all there and I get no such errors from the runs with tree-cleanup-branch (merged 2005-02-23). Any ideas? Thanks. Diego. - /home/cygnus/dnovillo/perf/sbox/gcc/local.i686/inst.tobiano/bin/gcc -c -o bits.o-O3 -march=i686bits.c Error from make 'specmake build 2> make.err | tee make.out': In file included from gzip.h:37, from bits.c:55: /usr/include/stdio.h:34:21: error: stddef.h: No such file or directory In file included from /usr/include/_G_config.h:44, from /usr/include/libio.h:32, from /usr/include/stdio.h:72, from gzip.h:37, from bits.c:55: /usr/include/gconv.h:72: error: expected declaration specifiers or '...' before'size_t' /usr/include/gconv.h:88: error: expected declaration specifiers or '...' before'size_t' /usr/include/gconv.h:97: error: expected declaration specifiers or '...' before'size_t' /usr/include/gconv.h:174: error: expected specifier-qualifier-list before 'size_t' In file included from /usr/include/stdio.h:72, from gzip.h:37, from bits.c:55: /usr/include/libio.h:53:21: error: stdarg.h: No such file or directory In file included from /usr/include/stdio.h:72, from gzip.h:37, from bits.c:55: /usr/include/libio.h:354: error: expected declaration specifiers or '...' before 'size_t' /usr/include/libio.h:363: error: expected declaration specifiers or '...' before 'size_t' /usr/include/libio.h:475: error: expected declaration specifiers or '...' before '__gnuc_va_list' /usr/include/libio.h:477: error: expected declaration specifiers or '...' before '__gnuc_va_list' /usr/include/libio.h:479: error: expected '=', ',', ';', 'asm' or '__attribute__' before '_IO_sgetn' In file included from gzip.h:37, from bits.c:55: /usr/include/stdio.h:304: error: expected declaration specifiers or '...' before 'size_t' /usr/include/stdio.h:311: error: expected declaration specifiers or '...' before 'size_t' /usr/include/stdio.h:339: error: expected declaration specifiers or '...' before '__gnuc_va_list' -
Re: Strange build errors compiling SPEC with mainline
Hi, On Fri, 18 Mar 2005, Diego Novillo wrote: > Starting around 2005-03-17, I haven't been able to compile > several SPEC tests with mainline. Has there been any change in > the pre-processor that might explain these errors? > > I'm pretty sure my installation is correct because this worked > until 2005-03-15, the system header files are all there and I get > no such errors from the runs with tree-cleanup-branch (merged > 2005-02-23). > > Any ideas? > > Thanks. Diego. > > - > /home/cygnus/dnovillo/perf/sbox/gcc/local.i686/inst.tobiano/bin/gcc -c -o > bits.o-O3 -march=i686bits.c > Error from make 'specmake build 2> make.err | tee make.out': > In file included from gzip.h:37, > from bits.c:55: > /usr/include/stdio.h:34:21: error: stddef.h: No such file or directory stddef.h is a header installed by GCC into lib/gcc//4.1.0/include/stddef.h If it can't be found it means that it's not installed there, which might be due to Zacks changes. You should look if you have a 'const' directory instead of the 4.1.0 one. If yes, then this is the problem, and Zacks latest patches fixes it. Ciao, Michael.
CC0 to CCmode conversion
Hi All! I have converted the AVR port from CC0 to CCmode. But may be I have converted the port in wrong way. (It's because I was interested in *this* way.) I have used CCmode register and havn't added the '(clobber (reg:QI CC_REGNUM))' to any insn that really clobber the CC_REGNUM just because AVR is'n needed in scheduling. I think that sequence of compare + cond-jump will exists in any compiler pass. The port was successfully tested without new regressions. What do you (MAINTAINERS) think about this ? Denis.
FAIL: gcc.c-torture/compile/20011119-2.c -O1 for gcc 4.0.0 20050318 (prerelease) on sparc-linux
Aurora SPARC Linux release 2.0 (Kashmir FC3) UltraSparc IIi (Sabre) sun4u: binutils-2.15.94.0.2-1.sparc bison-1.875c-2.sparc dejagnu-1.4.4-2.noarch expect-5.42.1-1.sparc gcc-3.4.2-6.fc3.sparc gcc4-4.0.0-0.8sparc.sparc glibc-2.3.3-99.sparcv9 glibc-2.3.3-99.sparc64 glibc-devel-2.3.3-99.sparc64 glibc-devel-2.3.3-99.sparc glibc-headers-2.3.3-99.sparc64 glibc-headers-2.3.3-99.sparc glibc-kernheaders-2.6-20sparc.sparc kernel-2.6.11-1.1166sp1.sparc64 package kernel-devel is not installed package kernel-smp is not installed libgcc-3.4.2-6.fc3.sparc libgcc-3.4.2-6.fc3.sparc64 libstdc++-3.4.2-6.fc3.sparc libstdc++-3.4.2-6.fc3.sparc64 libstdc++-devel-3.4.2-6.fc3.sparc libstdc++-devel-3.4.2-6.fc3.sparc64 make-3.80-5.sparc nptl-devel-2.3.3-99.sparcv9 tcl-8.4.7-2.sparc LAST_UPDATED: Fri Mar 18 07:24:21 UTC 2005 configure flags: sparc-linux --enable-__cxa_atexit --disable-multilib --enable-shared --enable-languages=c,ada,c++ Native configuration is sparc-unknown-linux-gnu Executing on host: /usr/local/src/branch/objdir32/gcc/xgcc -B/usr/local/src/branch/objdir32/gcc/ -O1 -w -c -o 2009-2.o /usr/local/src/branch/gcc/gcc/testsuite/gcc.c-torture/compile/2009-2.c (timeout = 300) /usr/local/src/branch/gcc/gcc/testsuite/gcc.c-torture/compile/2009-2.c:4: internal compiler error: in cgraph_expand_function, at cgraphunit.c:837 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. compiler exited with status 1 output is: /usr/local/src/branch/gcc/gcc/testsuite/gcc.c-torture/compile/2009-2.c:4: internal compiler error: in cgraph_expand_function, at cgraphunit.c:837 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. FAIL: gcc.c-torture/compile/2009-2.c -O1 (test for excess errors) other optimisation levels work... -- Cheers, /ChJ
Re: FAIL: gcc.c-torture/compile/20011119-2.c -O1 for gcc 4.0.0 20050318 (prerelease) on sparc-linux
On Fri, 18 Mar 2005 17:10:21 +0100, Christian Joensson
<[EMAIL PROTECTED]> wrote:
> Aurora SPARC Linux release 2.0 (Kashmir FC3) UltraSparc IIi (Sabre) sun4u:
[EMAIL PROTECTED] branch]$ /usr/local/src/branch/objdir32/gcc/xgcc -v
-save-temps -B/usr/local/src/branch/objdir32/gcc/ -O1 -w -c -o
2009-2.o
/usr/local/src/branch/gcc/gcc/testsuite/gcc.c-torture/compile/2009-2.c
Reading specs from /usr/local/src/branch/objdir32/gcc/specs
Target: sparc-linux
Configured with: /usr/local/src/branch/gcc/configure sparc-linux
--enable-__cxa_atexit --disable-multilib --enable-shared
--enable-languages=c,ada,c++
Thread model: posix
gcc version 4.0.0 20050318 (prerelease)
/usr/local/src/branch/objdir32/gcc/cc1 -E -quiet -v -iprefix
/usr/local/src/branch/objdir32/gcc/../lib/gcc/sparc-linux/4.0.0/
-isystem /usr/local/src/branch/objdir32/gcc/include
/usr/local/src/branch/gcc/gcc/testsuite/gcc.c-torture/compile/2009-2.c
-mcpu=v7 -w -O1 -fpch-preprocess -o 2009-2.i
ignoring nonexistent directory
"/usr/local/src/branch/objdir32/gcc/../lib/gcc/sparc-linux/4.0.0/include"
ignoring nonexistent directory
"/usr/local/src/branch/objdir32/gcc/../lib/gcc/sparc-linux/4.0.0/../../../../sparc-linux/include"
ignoring nonexistent directory "NONE/include"
ignoring nonexistent directory "/usr/local/lib/gcc/sparc-linux/4.0.0/include"
ignoring nonexistent directory "/usr/local/lib/../sparc-linux/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/src/branch/objdir32/gcc/include
/usr/local/include
/usr/include
End of search list.
/usr/local/src/branch/objdir32/gcc/cc1 -fpreprocessed 2009-2.i
-quiet -dumpbase 2009-2.c -mcpu=v7 -auxbase-strip 2009-2.o -O1
-w -version -o 2009-2.s
GNU C version 4.0.0 20050318 (prerelease) (sparc-linux)
compiled by GNU C version 4.0.0 20050318 (prerelease).
GGC heuristics: --param ggc-min-expand=47 --param ggc-min-heapsize=31992
/usr/local/src/branch/gcc/gcc/testsuite/gcc.c-torture/compile/2009-2.c:4:
internal compiler error: in cgraph_expand_function, at
cgraphunit.c:837
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
[EMAIL PROTECTED] branch]$ cat 2009-2.s
.file "2009-2.c"
.section".text"
.align 4
.global bar
.type bar, #function
.proc 04
bar:
jmp %o7+8
mov23, %o0
.size bar, .-bar
.align 4
.global baz
.type baz, #function
.proc 04
baz:
save%sp, -104, %sp
callfoo, 0
nop
jmp %i7+8
restore %g0, %o0, %o0
.size baz, .-baz
[EMAIL PROTECTED] branch]$ cat 2009-2.i
# 1 "/usr/local/src/branch/gcc/gcc/testsuite/gcc.c-torture/compile/2009-2.c"
# 1 ""
# 1 ""
# 1 "/usr/local/src/branch/gcc/gcc/testsuite/gcc.c-torture/compile/2009-2.c"
extern inline int foo (void) { return 23; }
int bar (void) { return foo (); }
extern int foo (void) __attribute__ ((weak, alias ("xxx")));
int baz (void) { return foo (); }
int xxx(void) __asm__("xxx");
int xxx(void) { return 23; }
[EMAIL PROTECTED] branch]$
--
Cheers,
/ChJ
Weird behavior in ivopts code
I'm sitting here analyzing a regression with some pending jump threading
changes and I've stumbled upon this quirk in IV opts which, if nothing
else, makes it very difficult to evaluate the jump threading changes.
Specifically, the set of IVs selected for a loop changes when the
version #s of objects used within change -- even if there is no
difference in the actual code within the loop. For example, we will get
a different set of IVs for these two loops:
# BLOCK 1
# PRED: 3 [100.0%] (fallthru) 0 [100.0%] (fallthru,exec)
# ivtmp.4_4 = PHI ;
# TMT.2_2 = PHI ;
# i_1 = PHI ;
:;
# TMT.2_12 = V_MAY_DEF ;
this_8->data[i_1] = d_7;
i_9 = i_1 + 1;
ivtmp.4_3 = ivtmp.4_4 - 1;
if (ivtmp.4_3 != 0) goto ; else goto ;
# SUCC: 3 [87.5%] (dfs_back,true,exec) 2 [12.5%]
(loop_exit,false,exec)
# BLOCK 3
# PRED: 1 [87.5%] (dfs_back,true,exec)
:;
goto ();
# SUCC: 1 [100.0%] (fallthru)
# BLOCK 2
# PRED: 1 [12.5%] (loop_exit,false,exec)
:;
return;
# SUCC: EXIT [100.0%]
# BLOCK 1
# PRED: 3 [100.0%] (fallthru) 0 [100.0%] (fallthru,exec)
# ivtmp.4_16 = PHI ;
# TMT.2_18 = PHI ;
# i_19 = PHI ;
:;
# TMT.2_12 = V_MAY_DEF ;
this_8->data[i_19] = d_7;
i_9 = i_19 + 1;
ivtmp.4_15 = ivtmp.4_16 - 1;
if (ivtmp.4_15 != 0) goto ; else goto ;
# SUCC: 3 [87.5%] (dfs_back,true,exec) 2 [12.5%]
(loop_exit,false,exec)
# BLOCK 3
# PRED: 1 [87.5%] (dfs_back,true,exec)
:;
goto ();
# SUCC: 1 [100.0%] (fallthru)
# BLOCK 2
# PRED: 1 [12.5%] (loop_exit,false,exec)
:;
return;
# SUCC: EXIT [100.0%]
If you look closely, you'll find that these two loops are functionally
equivalent -- all that has happened is that we have different SSA_NAMEs
in use.
After IVops the first loop looks like:
# BLOCK 1
# PRED: 3 [100.0%] (fallthru) 0 [100.0%] (fallthru,exec)
# ivtmp.12_10 = PHI ;
# TMT.2_2 = PHI ;
# i_1 = PHI ;
:;
D.1616_14 = (float *) ivtmp.12_10;
this_15 = D.1616_14;
# TMT.2_12 = V_MAY_DEF ;
*this_15 = d_7;
i_9 = i_1 + 1;
ivtmp.12_13 = ivtmp.12_10 + 4B;
if (i_9 != 8) goto ; else goto ;
# SUCC: 3 [87.5%] (dfs_back,true,exec) 2 [12.5%]
(loop_exit,false,exec)
# BLOCK 3
# PRED: 1 [87.5%] (dfs_back,true,exec)
:;
goto ();
# SUCC: 1 [100.0%] (fallthru)
# BLOCK 2
# PRED: 1 [12.5%] (loop_exit,false,exec)
:;
return;
# SUCC: EXIT [100.0%]
Whereas the second loop gets turned into:
# BLOCK 1
# PRED: 3 [100.0%] (fallthru) 0 [100.0%] (fallthru,exec)
# ivtmp.12_23 = PHI ;
# ivtmp.4_16 = PHI ;
# TMT.2_18 = PHI ;
:;
D.1615_6 = (float *) ivtmp.12_23;
this_2 = D.1615_6;
# TMT.2_12 = V_MAY_DEF ;
*this_2 = d_7;
ivtmp.4_15 = ivtmp.4_16 - 1;
ivtmp.12_22 = ivtmp.12_23 + 4B;
if (ivtmp.4_15 != 0) goto ; else goto ;
# SUCC: 3 [87.5%] (dfs_back,true,exec) 2 [12.5%]
(loop_exit,false,exec)
# BLOCK 3
# PRED: 1 [87.5%] (dfs_back,true,exec)
:;
goto ();
# SUCC: 1 [100.0%] (fallthru)
# BLOCK 2
# PRED: 1 [12.5%] (loop_exit,false,exec)
:;
return;
# SUCC: EXIT [100.0%]
Note carefully how the induction variables for the loop control
counter differ.
What's particularly interesting is the first loop results in the
following assembly code:
.LFB3:
pushl %ebp
.LCFI0:
xorl%edx, %edx
movl%esp, %ebp
.LCFI1:
movl8(%ebp), %eax
movl12(%ebp), %ecx
.p2align 4,,15
.L2:
incl%edx
movl%ecx, (%eax)
addl$4, %eax
cmpl$8, %edx
jne .L2
popl%ebp
ret
Which actually runs faster than the code for the second loop (which is
odd since the second loop looks to my eye to be more efficient than
the first loop).
.LFB3:
pushl %ebp
.LCFI0:
movl$8, %edx
movl%esp, %ebp
.LCFI1:
movl8(%ebp), %eax
movl12(%ebp), %ecx
.p2align 4,,15
.L2:
movl%ecx, (%eax)
addl$4, %eax
decl%edx
jne .L2
popl%ebp
ret
The problem appears to be related to how we add IV candidates:
/* Adds candidates based on the old induction variables. */
static void
add_old_ivs_candidates (struct ivopts_data *data)
{
unsigned i;
struct iv *iv;
bitmap_iterator bi;
EXECUTE_IF_SET_IN_BITMAP (data->relevant, 0, i, bi)
{
iv = ver_info (data, i)->iv;
if (iv && iv->biv_p && !zero_p (iv->step))
add_old_iv_candidates (data, iv);
}
}
Which, if I read it correctly, will add candidates to the IV array
in the same order as their SSA_NAME_VERSION.
Then we have this code:
/* Try extending the set of induction variables by one. */
for (i = 0; i < n_iv_cands (data); i++)
{
cand = iv_cand (data, i);
if (iv_ca_cand_used_p (ivs, cand))
continue;
acost = iv_ca_extend (data, ivs, cand, &act_delta, &n_ivs);
if (!act_delta)
continue;
/* If we successfully added the candidate and the set is small
enough,
Re: AVR: CC0 to CCmode conversion
> Denis wrote: > I have converted the AVR port from CC0 to CCmode. > But may be I have converted the port in wrong way. > (It's because I was interested in *this* way.) > > I have used CCmode register and havn't added the > '(clobber (reg:QI CC_REGNUM))' to any insn that really clobber the > CC_REGNUM just because AVR is'n needed in scheduling. > I think that sequence of compare + cond-jump will exists in any > compiler pass. > The port was successfully tested without new regressions. > What do you (MAINTAINERS) think about this ? Interesting: - might you be able to post the resulting port files for review? - are you proposing that all conditional branches then required to be explicitly paired with a corresponding immediately previous compare instruction? (if so, how is this a good thing observing that it's fairly typical for most conditional branches to be naturally based on comparisons against 0 resulting from the immediately preceding operation, which would have otherwise not required an explicit compare?) thanks
Re: Weird behavior in ivopts code
Hello, > Which appears to walk down the array and try and choose better IV sets. > Since it walks down the IV array, which is in SSA_NAME_VERSION order. > Thus two loops which are equivalent in all ways except that they use > different SSA_NAME_VERSIONs can get different IV sets. > > Anyway, the instability of the IV opts code when presented with loops > that differ only in the version #s in the SSA_NAMEs they use is really > getting in the way of understanding the performance impact of the > new jump threading code. I would expect this instability to also make > it difficult to analyze the IVopts in general. there's not much to do about the matter. The choice of ivs in ivopts is just a heuristics (and this cannot be changed, due to compiler performance reasons), and as such it is prone to such instabilities. In fact, both choices of ivs make sense, and they have the same cost w.r. to the cost function used by ivopts. Anyway, in this particular case, the patch below should make ivopts to prefer the choice of preserving the variable 'i' (which is better from the point of preserving debugging information). Zdenek Index: tree-ssa-loop-ivopts.c === RCS file: /cvs/gcc/gcc/gcc/tree-ssa-loop-ivopts.c,v retrieving revision 2.21 diff -c -3 -p -r2.21 tree-ssa-loop-ivopts.c *** tree-ssa-loop-ivopts.c 27 Oct 2004 20:27:20 - 2.21 --- tree-ssa-loop-ivopts.c 27 Oct 2004 20:30:19 - *** determine_iv_cost (struct ivopts_data *d *** 3326, cand->cost = cost_step + cost_base / AVG_LOOP_NITER (current_loop); ! /* Prefer the original iv unless we may gain something by replacing it. */ ! if (cand->pos == IP_ORIGINAL) cand->cost--; /* Prefer not to insert statements into latch unless there are some --- 3327,3337 cand->cost = cost_step + cost_base / AVG_LOOP_NITER (current_loop); ! /* Prefer the original iv unless we may gain something by replacing it; ! this is not really relevant for artificial ivs created by other ! passes. */ ! if (cand->pos == IP_ORIGINAL ! && !DECL_ARTIFICIAL (SSA_NAME_VAR (cand->var_before))) cand->cost--; /* Prefer not to insert statements into latch unless there are some
reload-branch created (was: What to do with new-ra for GCC 4.0)
Jeffrey A Law wrote: On Fri, 2005-01-21 at 17:50 +0100, Giovanni Bajo wrote: Why not putting it on a branch? If you are going to finish and submit it for 4.1, it might be easier to use CVS. It might also be easier for those of us who want to play with the code, without having to find a suitable sync point between the patch and mainline sources. I have created a new branch, "reload-branch", on which I'm going to check in these changes. Once I've done that, I'll commit the patch below to mention the branch in the documentation. Bernd Index: cvs.html === RCS file: /cvs/gcc/wwwdocs/htdocs/cvs.html,v retrieving revision 1.183 diff -c -p -r1.183 cvs.html *** cvs.html14 Mar 2005 22:35:59 - 1.183 --- cvs.html18 Mar 2005 17:20:13 - *** particular releases or snapshots or the *** 255,260 --- 255,265 routinely merged with mainline. Patches should be marked with the tag [dfp] in the subject line. + reload-branch + This branch contains a version of reload in which the tracking + of reload register lifetimes and the inheritance code has been + rewritten in an attempt to make it more maintainable. + Architecture-specific
Re: help with mudflap testsuite result analysis
On Thursday, March 17, 2005, at 11:37 AM, Mike Stump wrote: So, I've been working on mudflap for darwin8, and these are the results I get... I know what you're thinking, it's impossible to get it working because it doesn't have --wrap and friends.. well, I pulled some magic pixie dust out and sprinkled it around and it's starting to work... The question is, how decent are the results and can you spot any systematic wrongs that appear and/or can you identify any non-portableness to darwin of mudflap? I started from 89 passes... > :-) I fixed most all the obvious issues that appeared due to darwin from looking at the build result and looking at the libmudflap.log file. If someone would like to help track down the issues, I'd be interested in hearing from you. I did a wc -c to ensure that the file was there, and what its size was... and then I sent that proof onto the list... :-( Here is the real file: libmudflap.log.bz Description: Binary data
Re: Strange build errors compiling SPEC with mainline
On Fri, Mar 18, 2005 at 03:02:53PM +0100, Michael Matz wrote: > Hi, > > On Fri, 18 Mar 2005, Diego Novillo wrote: > > > Starting around 2005-03-17, I haven't been able to compile > > several SPEC tests with mainline. Has there been any change in > > the pre-processor that might explain these errors? > > > > I'm pretty sure my installation is correct because this worked > > until 2005-03-15, the system header files are all there and I get > > no such errors from the runs with tree-cleanup-branch (merged > > 2005-02-23). > > > > Any ideas? > > > > Thanks. Diego. > > > > - > > /home/cygnus/dnovillo/perf/sbox/gcc/local.i686/inst.tobiano/bin/gcc -c -o > > bits.o-O3 -march=i686bits.c > > Error from make 'specmake build 2> make.err | tee make.out': > > In file included from gzip.h:37, > > from bits.c:55: > > /usr/include/stdio.h:34:21: error: stddef.h: No such file or directory > > stddef.h is a header installed by GCC into > lib/gcc//4.1.0/include/stddef.h If it can't be found it means that > it's not installed there, which might be due to Zacks changes. You should > look if you have a 'const' directory instead of the 4.1.0 one. If yes, > then this is the problem, and Zacks latest patches fixes it. I haven't yet tried the patch but I get similar errors on powerpc64-linux compiling a hello world program with mainline for the last two days, and the directories are named 'const'. Janis
Re: Suggestion for a fix to Bug middle-end/20177
> Steven Bosscher wrote: >> Mostafa Hagog <[EMAIL PROTECTED]> wrote: >> This is interesting, so there could be cases were want to copy CC >> register when doing SMS. what happens if we want to move the set >> of a CC to another iteration of the loop ? or the use of the CC ? but >> usually this is couldn't happen in a simple loop, right? the use of CC >> is eventually used in a branch, or there is something that I am missing ? > > IIRC these notes are for CCO, and you have to move the CC setter > and user together. - unless it can be guaranteed that the particular setter's cc, will be preserved (i.e. not corrupted by successive operations) prior to it's ultimate use; or alternatively regenerating the setter's cc typically by comparing it's previously computed data result with 0 (to regenerate the cc side effect, not necessarily the operation), if the user is moved past potentially corrupting successive operations; it would seem? > Actually I think SMS for CC0 targets is Just Silly to do at all ;-) - with the exception that it should be useful to eliminate otherwise unnecessary explicit comparison operations if an otherwise required operation (with the the desired setter cc side effects) can be more optimally scheduled immediately prior to a user of it's cc side effect (as is often typically the case when a conditional branch is dependant on a previously computed result being compared against 0). (but agree that as cc0 targets tend to be lightly pipelined in-order issue and completion machines, they tend to not be highly sensitive to instruction ordering; with the exception of conditional branching code does typically benefit from ideally scheduled sequences which do not require the re-synthesis of a cc through the use of an explicit comparison (or likely worse, a saved cc register) operation; which a good schedule would tend to likely avoid if possible; I'd guess.)
Re: AVR: CC0 to CCmode conversion
Paul Schlie <[EMAIL PROTECTED]> writes: > > Denis wrote: > > I have converted the AVR port from CC0 to CCmode. > > But may be I have converted the port in wrong way. > > (It's because I was interested in *this* way.) > > > > I have used CCmode register and havn't added the > > '(clobber (reg:QI CC_REGNUM))' to any insn that really clobber the > > CC_REGNUM just because AVR is'n needed in scheduling. > > I think that sequence of compare + cond-jump will exists in any > > compiler pass. > > The port was successfully tested without new regressions. > > What do you (MAINTAINERS) think about this ? > > Interesting: > > - might you be able to post the resulting port files for review? patch against cvs: http://home.overta.ru/users/denisc/cc0-ccmode/cc0-ccmode.patch.gz new port: http://home.overta.ru/users/denisc/cc0-ccmode/avr.tgz > - are you proposing that all conditional branches then required to be > explicitly paired with a corresponding immediately previous compare > instruction? I founded that GCC isn't break cmp+jump sequences. (My port havn't scheduling.) > (if so, how is this a good thing observing that it's fairly typical > for most conditional branches to be naturally based on comparisons > against 0 resulting from the immediately preceding operation, which > would have otherwise not required an explicit compare?) I think that it's not good. Denis.
Re: help with mudflap testsuite result analysis
mrs wrote: > [...] The question is, how decent are the results and can you spot > any systematic wrongs that appear and/or can you identify any > non-portableness to darwin of mudflap? I started from 89 > passes... > :-) [...] Most of the FAILs are "output pattern test" failures, related to some mf-runtime.c problem locating "nearby" objects in mudflap error messages. Maybe this code has signedness problems on darwin. Maybe the malloc's from the test cases weren't being interposed at all. For dynamic linkage, this requires your dynamic linking system to resolve malloc-related calls to libmudflap, whence dlsym(RTLD_NEXT..) can find the system malloc. Try building one of the test cases by hand, and run it with env MUDFLAP_OPTIONS="-trace-calls". You should see the registration (corresponding to malloc), and a number of successful checks, and at an unsuccessful check. The heap-scalestress FAIL may relate to a mf-hooks* or mf-runtime.c portability problem, where an object registration is attempted that overlaps the startup-time registration of the stdin/out/err FILE objects. A trace would again help. Similar to Jim Wilson's findings, the stdio-related mf-hook* calls may need autoconf parametrization to do the right thing on your libc. This problem is triggered by a few other tests too. The hook-allocstuff FAIL may again relate to malloc/realloc interposition problems, as might pass11/12/16/... A "-trace-calls" run should again help identify the culprit. The pass-stratcliff FAIL may relate to the absence of a stpncpy/mempcpy declaration or implementation on darwin. The pass35 FAIL may be a darwin linker oddness. __mf_register() should be callable explicitly from C code. The pass55 FAILs may be a varasm problem. I'd look at the intermediate assembler code and work backward. The pass40 FAILs look to me like they shouldn't happen. This is the multithreaded test that prints out a few numbers to validate the run. Maybe there is a CR/LF problem in the test case or the dejagnu driver? Overall, it looks close, though the number of PASSes are inflated somewhat by crediting merely successful compilation. The probable malloc interception problem has to be solved, and should make most of the failures go away. That's what I would look at next. - FChE
Problem running optimized IA64 code that invokes hand-coded assembly language function
I have a function F written in IA64 assembly language function. This function is invoked from a C program P. If I compile P with gcc (version 3.2.3) under Linux, and with no optimization options, the resulting executable runs flawlessly. If I compile P with -O then the resulting executable fails. Interestingly, building P with the Intel compiler results in an executable that runs perfectly, with or without optimization. The way the executable obtained with gcc and -O fails is as follows: I have an if-then-else construct to determine what function to invoke: if (x == OPERATION_ONE) f1() ; else f2() ; Both f1 and f2 invoke F. This portion of code is executed many times inside a for loop. The value of x is set to OPERATION_ONE outside the loop (for my particular run,) which implies that we should always invoke f1. This is what happens the first two times this if block is executed. The third time, mysteriously, it is f2 that gets invoked. Even more puzzling, it happens so even if the value of x is set to OPERATION_ONE by hand with the debugger, just before the conditional is executed. Also, if immediately preceding the if block I insert the line x = OPERATION_ONE ; and recompile (with or without -O,) then everything works fine. At this point I do not know if it is the case that F is buggy, but happens to work without optimization for gcc, and in all cases for the Intel compiler, or whether there is a bug in the gcc optimizer that is tickled by F. It would be useful if somebody knowledgeable could tell me what IA64 registers does gcc expect to be preserved on return of function calls; I am familiar with the convention for IA64 assembly language and C, but I do not know what gcc assumes in this respect. Reply
Overriding optimization for individual portions of C code
Is it possible with gcc to specify that a portion of code should be compiled without any optimizations, overriding the -O option given in the command line? The solution consisting of isolating that portion of code, and placing it in a separate file is not what I am looking for.
Re: Overriding optimization for individual portions of C code
On Fri, Mar 18, 2005 at 02:46:30PM -0800, JCA wrote: >Is it possible with gcc to specify that a portion of code should be > compiled without any optimizations, overriding the -O option given in > the command line? The solution consisting of isolating that portion of > code, and placing it in a separate file is not what I am looking for. Sorry it's not what you're looking for, but using a separate file is currently the only option.
Re: Problem running optimized IA64 code that invokes hand-coded assembly language function
JCA <[EMAIL PROTECTED]> writes: > It would be useful if somebody knowledgeable could tell me what > IA64 registers does gcc expect to be preserved on return of function > calls; I am familiar with the convention for IA64 assembly language > and C, but I do not know what gcc assumes in this respect. GCC assumes exactly what is specified in the IA64 ABI. Everything else would be a bug. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: AVR: CC0 to CCmode conversion
> From: Denis Chertykov <[EMAIL PROTECTED]> >> Paul Schlie <[EMAIL PROTECTED]> writes: >>> Denis wrote: >>> I have converted the AVR port from CC0 to CCmode. >>> But may be I have converted the port in wrong way. >>> (It's because I was interested in *this* way.) >>> >>> I have used CCmode register and havn't added the >>> '(clobber (reg:QI CC_REGNUM))' to any insn that really clobber the >>> CC_REGNUM just because AVR is'n needed in scheduling. >>> I think that sequence of compare + cond-jump will exists in any >>> compiler pass. >>> The port was successfully tested without new regressions. >>> What do you (MAINTAINERS) think about this ? >> >> Interesting: >> >> - might you be able to post the resulting port files for review? > > patch against cvs: > http://home.overta.ru/users/denisc/cc0-ccmode/cc0-ccmode.patch.gz > new port: > http://home.overta.ru/users/denisc/cc0-ccmode/avr.tgz - Thank you, I've had the chance to review it to better understand. >> - are you proposing that all conditional branches then required to be >> explicitly paired with a corresponding immediately previous compare >> instruction? > > I founded that GCC isn't break cmp+jump sequences. > (My port havn't scheduling.) - Maybe presently, but there's nothing in the machine description which would seem to prohibit it either. (continued in following section) >> (if so, how is this a good thing observing that it's fairly typical >> for most conditional branches to be naturally based on comparisons >> against 0 resulting from the immediately preceding operation, which >> would have otherwise not required an explicit compare?) > > I think that it's not good. - although I agree that there's likely a cleaner more consistent way to accurately describe and track condition-code side-effects of AVR's ISA, it seems that this approach actually inhibits GCC helping to optimize the code, as too much information is being hidden from it? For example: It seems that by relying on peephole optimization to try to eliminate otherwise redundant explicit expensive comparison operations on wider than byte sized operands which were generated because multi-byte wide operations don't expose their cc-mode side-effects, may not be a good strategy? As it would seem that the initial hiding of this critical information only inhibits GCC from being able to optimally (not to mention safely) schedule basic block instruction sequences in an effort to eliminate the necessity of otherwise relatively expensive multi-byte comparisons to begin with. (Which would seem to be more optimal than relying on no scheduling, and likely only catching some of the potential opportunities to eliminate expensive compares after the fact?) (however acknowledge that may misunderstand GCC's instruction scheduling capabilities, and/or be missing something more significant?) Thanks, -paul-
Re: CC0 to CCmode conversion
Denis Chertykov wrote: I have converted the AVR port from CC0 to CCmode. That's indeed very good news. Incidentally, CC0 conversion of the AVR target was being discussed in an off-list thread with Andy Hutchinson. But may be I have converted the port in wrong way. (It's because I was interested in *this* way.) Uh? That's very bad news. I have used CCmode register and havn't added the '(clobber (reg:QI CC_REGNUM))' to any insn that really clobber the CC_REGNUM just because AVR is'n needed in scheduling. I think that sequence of compare + cond-jump will exists in any compiler pass. The port was successfully tested without new regressions. Did you notice any pessimization spots in the generated code? IIRC, the converted H8 backend required some massaging before it was back on par with the old version. -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/
gcc-3.4-20050318 is now available
Snapshot gcc-3.4-20050318 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20050318/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 3.4 CVS branch with the following options: -rgcc-ss-3_4-20050318 You'll find: gcc-3.4-20050318.tar.bz2 Complete GCC (includes all of below) gcc-core-3.4-20050318.tar.bz2 C front end and core compiler gcc-ada-3.4-20050318.tar.bz2 Ada front end and runtime gcc-g++-3.4-20050318.tar.bz2 C++ front end and runtime gcc-g77-3.4-20050318.tar.bz2 Fortran 77 front end and runtime gcc-java-3.4-20050318.tar.bz2 Java front end and runtime gcc-objc-3.4-20050318.tar.bz2 Objective-C front end and runtime gcc-testsuite-3.4-20050318.tar.bz2The GCC testsuite Diffs from 3.4-20050311 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-3.4 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.
Question on tree-ssa-loop-im.c:for_each_index
VIEW_CONVERT_EXPR is tcc_reference, but we can have a statement like: x = 22; What ends up happening here is that find_interesting_uses_stmt calls find_interesting_uses_address, which goes down the references and runs into the constant, which it doesn't know how to handle. I think the simplest fix is below. It's certainly safe in that it converts an ICE into not aborting and seems to do the right thing. The test case is in Ada and proprietary and it didn't seem worthwhile to make a small one for something this simple. Does the following look correct? *** tree-ssa-loop-im.c 11 Mar 2005 09:05:10 - 2.31 --- tree-ssa-loop-im.c 19 Mar 2005 00:12:02 - *** for_each_index (tree *addr_p, bool (*cbc *** 195,198 --- 195,199 case STRING_CST: case RESULT_DECL: + case INTEGER_CST: return true;
Re: reload-branch created
Bernd Schmidt wrote:
> I have created a new branch, "reload-branch", on which I'm going to
> check in these changes.
Thanks!
With three changes described below, I'm able to bootstrap and test the
reload-branch on s390-ibm-linux and s390x-ibm-linux without regressions
against head (except two additional ACATS failures on s390 which may
simply be caused by a slightly different Ada front end code base).
The changes are:
- As mentioned in http://gcc.gnu.org/ml/gcc/2005-01/msg00911.html
there is a code path in find_reloads that sets rld[].inc to a
nonzero value even for a platform that doesn't actually *have*
pre-/post-increment insns, leading to an ICE later on.
The patch below simply avoids setting .inc unless it was already
set to a nonzero value (by find_inc_amount).
- As mentioned in http://gcc.gnu.org/ml/gcc/2005-01/msg01112.html
there are problems with reload ordering when optional reloads
are disabled, leading to address reload insns being emitted after
the main insn.
The patch below is the same I suggested in that mail; it considers
such address reloads to feed into both the optional reload and
the main insn in scan_rtx.
- Finally, there is still a (new) problem in the latest version of
usable_for_inheritance: if an inherited register is chosen as
override-in because it is not suitable as reload register due
to HARD_REGNO_MODE_OK, it isn't even checked against the
*usable_regs array.
The patch below adds back that check (using inmode, not mode).
Bye,
Ulrich
Index: gcc/reload.c
===
RCS file: /cvs/gcc/gcc/gcc/reload.c,v
retrieving revision 1.268.6.1
diff -c -p -r1.268.6.1 reload.c
*** gcc/reload.c18 Mar 2005 18:40:32 - 1.268.6.1
--- gcc/reload.c18 Mar 2005 21:43:47 -
*** find_reloads (struct insn_chain *chain,
*** 3215,3222
MODE_BASE_REG_CLASS (VOIDmode),
GET_MODE (XEXP (recog_data.operand[i], 0)),
VOIDmode, 0, 0, i, RELOAD_FOR_NONE);
! rld[operand_reloadnum[i]].inc
! = GET_MODE_SIZE (GET_MODE (recog_data.operand[i]));
}
else if (goal_alternative_matched[i] == -1)
{
--- 3215,3224
MODE_BASE_REG_CLASS (VOIDmode),
GET_MODE (XEXP (recog_data.operand[i], 0)),
VOIDmode, 0, 0, i, RELOAD_FOR_NONE);
!
! if (rld[operand_reloadnum[i]].inc)
! rld[operand_reloadnum[i]].inc
! = GET_MODE_SIZE (GET_MODE (recog_data.operand[i]));
}
else if (goal_alternative_matched[i] == -1)
{
Index: gcc/reload1.c
===
RCS file: /cvs/gcc/gcc/gcc/reload1.c,v
retrieving revision 1.463.2.1
diff -c -p -r1.463.2.1 reload1.c
*** gcc/reload1.c 18 Mar 2005 18:40:33 - 1.463.2.1
--- gcc/reload1.c 18 Mar 2005 21:43:48 -
*** scan_rtx (struct insn_chain *chain, rtx
*** 1527,1533
if (! just_mark)
rl->scanned_input = 1;
if (rl->optional)
! scan_rtx (chain, &contents, 0, reload_in_insn, 0, 0, 1);
else
scan_rtx (chain, &rl->in, 0, reload_in_insn, 0, 0, 1);
}
--- 1527,1536
if (! just_mark)
rl->scanned_input = 1;
if (rl->optional)
! {
! scan_rtx (chain, &contents, 0, reload_in_insn, 0, 0, 1);
! scan_rtx (chain, &contents, 0, rli, 0, 0, 1);
! }
else
scan_rtx (chain, &rl->in, 0, reload_in_insn, 0, 0, 1);
}
*** scan_rtx (struct insn_chain *chain, rtx
*** 1540,1546
if (! just_mark)
rl->scanned_output = 1;
if (rl->optional)
! scan_rtx (chain, &contents, is_output, reload_out_insn, 0, 0, 1);
else
scan_rtx (chain, &rl->out, is_output, reload_out_insn, 0, 0, 1);
--- 1543,1552
if (! just_mark)
rl->scanned_output = 1;
if (rl->optional)
! {
! scan_rtx (chain, &contents, is_output, reload_out_insn, 0, 0, 1);
! scan_rtx (chain, &contents, is_output, rli, 0, 0, 1);
! }
else
scan_rtx (chain, &rl->out, is_output, reload_out_insn, 0, 0, 1);
*** usable_for_inheritance (rtx head_rtx, st
*** 3289,3295
it must be valid in MODE, not just INMODE. */
if (mode != inmode && ! HARD_REGNO_MODE_OK (offsetted_regno, mode))
! can_use_inheritance_reg = 0;
else
{
nregs = HARD_REGNO_NREGS (offsetted_regno, mode);
--- 3295,3309
it must be valid in MODE, not just INMODE. */
if (mode != inmode && ! HARD_REGNO_MODE_OK (offsetted_regno, mode))
! {
! nregs = HARD_REGNO_NREGS (offsetted_regno, inmod
Re: reload-branch created (was: What to do with new-ra for GCC 4.0)
Bernd Schmidt <[EMAIL PROTECTED]> wrote: >>> It might also be easier for those of us who want to play with the >>> code, without having to find a suitable sync point between the >>> patch and >>> mainline sources. >> >> I have created a new branch, "reload-branch", on which I'm going to >> check in these changes. Once I've done that, I'll commit the patch >> below to mention the branch in the documentation. Thanks! You should also mention in cvs.html that you are the maintainer of the branch (together with Ulrich, maybe?). What is your plan for this branch? Is there more code refactoring/rewriting planned, or are you just going to give it a wider testing and fix fallout bugs, in preparation for a merge? Giovanni Bajo
Re: reload-branch created
Giovanni Bajo wrote: What is your plan for this branch? Is there more code refactoring/rewriting planned, or are you just going to give it a wider testing and fix fallout bugs, in preparation for a merge? There's one known design flaw wrt. to enble_optional/disable_optional, and I think autoinc reloads also need some work. That's going to take a bit of thought and probably some more code to fix. Then, there's the matter of testing all sorts of targets (and adapting their LEGITIMIZE_RELOAD_ADDRESS macros). I'm away for a week or so, so I'm unlikely to check in anything in the near future. Bernd
gcc 3.4.3 bug C++/inlines/thumb
I'm running into a bug with gcc 3.4.3:
I've got syscall code for user-land to our kernel that trashes r14/lr.
The code is inlined, and works find in ARM mode. When compiling in thumb,
gcc does not preserve lr. With an older gcc 3.3.3, the code was not inlined,
but generated correctly.
L4_INLINE void * L4_KernelInterface (L4_Word_t *ApiVersion,
L4_Word_t *ApiFlags,
L4_Word_t *KernelId)
{
register L4_Word_t base_address asm ("r0");
register L4_Word_t _ApiVersion asm ("r1");
register L4_Word_t _ApiFlagsasm ("r2");
register L4_Word_t _KernelIdasm ("r3");
__asm__ __volatile__ (
"mov lr, pc\n"
"mov pc, %[trap_kip]\n"
: "=r" (base_address), "=r" (_ApiVersion), "=r" (_ApiFlags),
"=r" (_KernelId)
: [trap_kip] "r" (L4_TRAP_KIP)
: "lr", "memory" );
if (ApiVersion) *ApiVersion = _ApiVersion;
if (ApiFlags) *ApiFlags = _ApiFlags;
if (KernelId) *KernelId = _KernelId;
return (void *)base_address;
}
--- inline asm marked at '*'
00051bac <__L4_Init>:
51bac: 204cmov r0, #76
51bae: 4240neg r0, r0
* 51bb0: 46femov lr, pc
* 51bb2: 4687mov pc, r0
51bb4: 2298mov r2, #152
51bb6: 0052lsl r2, r2, #1
51bb8: 1883add r3, r0, r2
51bba: 681bldr r3, [r3, #0]
...
---
Reading specs from
/home/extra/opt/tools/3.4.3-elf/bin/../lib/gcc/arm-elf/3.4.3/specs
Configured with: ../gcc-3.4.3/configure --prefix=/opt/tools/3.4.3-elf
--target=arm-elf --with-float=soft --with-arch=armv5te
--enable-cxx-flags=-march=armv5te --enable-languages=c,c++ : (reconfigured)
../gcc-3.4.3/configure --prefix=/opt/tools/3.4.3-elf --target=arm-elf
--with-float=soft --enable-languages=c,c++
Thread model: single
gcc version 3.4.3
thanks,
Carl van Schaik
_
Get your e-mail, your way - get MSN Hotmail Plus!
http://join.msn.com/?pgmarket=en-xe&DI=1054&XAPID=1816
