facing problem with the g++ testing
Hi
I am not able to test g++ with gcc3.2 test suit in dejagnu
[EMAIL PROTECTED] testsuite]# ~/dejagnu/runtest --tool g++
WARNING: Couldn't find the global config file.
Test Run By prabhu on Tue Nov 13 18:23:24 2007
Native configuration is couldn't execute "/home/prabhu/dejagnu/config.guess":
permission denied
=== g++ tests ===
Schedule of variations:
unix
Running target unix
Using /home/prabhu/dejagnu/baseboards/unix.exp as board description file for
target.
Using /home/prabhu/dejagnu/config/unix.exp as generic interface file for
target.
Using ./config/default.exp as tool-and-target-specific interface file.
Running ./g++.dg/debug/debug.exp ...
can't read "rootme": no such variable
while executing
"append ld_library_path ":${rootme}""
(procedure "g++_link_flags" line 34)
invoked from within
"g++_link_flags [get_multilibs] "
invoked from within
"if [info exists TOOL_OPTIONS] {
lappend ALWAYS_CXXFLAGS "additional_flags=[g++_include_flags
[get_multilibs ${TOOL_OPTIONS}] ]";
lappend ALW..."
invoked from within
"if ![is_remote host] {
if [info exists TOOL_OPTIONS] {
lappend ALWAYS_CXXFLAGS "additional_flags=[g++_include_flags
[get_multilibs ${TOOL_OPTION..."
(procedure "g++_init" line 58)
invoked from within
"${tool}_init $test_file_name"
invoked from within
"if [info exists tool] {
if { [info procs "${tool}_init"] != "" } {
${tool}_init $test_file_name
}
}"
invoked from within
"if [file exists $test_file_name] {
set timestart [timestamp]
if [info exists tool] {
if { [info procs "${tool}_init"] != "" } {
${tool}_init..."
(procedure "runtest" line 14)
invoked from within
"runtest $test_name"
("foreach" body line 42)
invoked from within
"foreach test_name [lsort [find ${dir} *.exp]] {
if { ${test_name} == "" } {
continue
}
# Ignore this one if asked to.
if { ${ignore..."
("foreach" body line 54)
invoked from within
"foreach dir "${test_top_dirs}" {
if { ${dir} != ${srcdir} } {
# Ignore this directory if is a directory to be
# ignored.
if {[info..."
("foreach" body line 121)
invoked from within
"foreach pass $multipass {
# multipass_name is set for `record_test' to use (see framework.exp).
if { [lindex $pass 0] != "" } {
set multipass_..."
("foreach" body line 51)
invoked from within
"foreach current_target $target_list {
verbose "target is $current_target"
set current_target_name $current_target
set tlist [split $curren..."
(file "/home/prabhu/dejagnu/runtest.exp" line 1625)
[EMAIL PROTECTED] testsuite]#
I am getting this type of message when I am trying to test
Can any body tell me what is happening
Regards
DISCLAIMER:
This message (including attachment if any) is confidential and may be
privileged. If you have received this message by mistake please notify the
sender by return e-mail and delete this message from your system. Any
unauthorized use or dissemination of this message in whole or in part is
strictly prohibited.
E-mail may contain viruses. Before opening attachments please check them for
viruses and defects. While MindTree Consulting Limited (MindTree) has put in
place checks to minimize the risks, MindTree will not be responsible for any
viruses or defects or any forwarded attachments emanating either from within
MindTree or outside.
Please note that e-mails are susceptible to change and MindTree shall not be
liable for any improper, untimely or incomplete transmission.
MindTree reserves the right to monitor and review the content of all messages
sent to or from MindTree e-mail address. Messages sent to or from this e-mail
address may be stored on the MindTree e-mail system or else where.
Re: Using crlibm as the default math library in GCC sources
On 2007-11-12 21:29:44 -0500, Geert Bosch wrote:
> On Nov 12, 2007, at 12:37, Michael Matz wrote:
>> * only double is implemented, hence long double and float are missing at
>> least, at least the long double would need some implementation work,
>> as you can't simply enlarge the mantissa and hope all your results are
>> still correct
> Initially, float could simply use double and cast the result.
> For double->float the results will remain correctly rounded.
Yes, very probably, but this needs to be proven for each supported
function, due to the double rounding problem (this may take some time
for functions like pow).
> Proving correct rounding involves a lot of testing of problematic
> intervals. I'm not sure the work has been done for long double,
> or even whether it is feasible to do with the current state of
> the art.
If by "long double", you mean the x86 extended format, then this is
feasible in some domains for unary functions.
Now, it is always possible to implement Ziv's strategy up to a
sufficiently large precision; in practice, this would probably
be correct rounding (without being proven). You'll get good
performance in average. Of course, the functions may be slow on
the "worst cases", but such worst cases are rare (in practice,
I think this can be a problem only with real-time applications,
where you need to bound the worst case).
>> * many C99 functions are missing: a{sin,cos}h, frexp, ldexp, modf, error
>> and gamma, remainder functions, I stoped looking somewhen
>> many only partially or slowly implemented: pow, exp2
> Most of these can be easily implemented based on the other primitives.
> True, the property of correctly rounded results will be lost, but
> that does not throw away the usefulness of having the other functions
> be correctly rounded.
Worse than losing correct rounding, the accuracy may be quite bad in
some domains.
>> * relies on a IEEE-754 compatible processor, so it a) needs to have
>> floating point at all and b) even has to use correct precision, e.g. a
>> problem for x86. That means that either crlibm doesn't work correctly
>> when the processor's precision is reset by the user program (e.g. to use
>> extended precision), or it has to save/set/restore the state on
>> entry/exit of all it's routines
> For x86, the use of -mfpmath=sse addresses most, if not all, issues
> related to excess precision for float and double.
But not all x86 processors support SSE2. However, I suppose you can
have crlibm support for some architectures only.
> Even if GCC has its own math library, users should still be able to
> specify linking with the systems native math library. As -frounding
Yes.
> In case of the correctly rounded functions, it is incredibly useful
> to know that all answers are both deterministic and as accurate as
> possible.
and consistent. For instance, sin(x)*sin(x) + cos(x)*cos(x) will
always be very close to 1, as mathematically expected.
>> * slow: it's much faster than other correctly rounded libraries, but
>> nevertheless also much slower then more mundane implementations of libm
> Do you have any numbers or approximations of how slow?
AFAIK, they are fast in average (Florent has some benchmarks).
> I think that in practice you'd probably have a number of
> implementations for the more popular functions, especially
> sin/cos, atan, log/exp. For reasonably good accuracy
> of the trigonometric functions (relative error less than
> 2 epsilon over entire domain), high-precision argument
> reduction is necessary. However, for many applications this
> is not an issue, and much more simplistic argument reduction
> can be used.
Yes, there can be a compile-time option and/or a pragma for that.
[...]
> It would be great for GCC to at least offer a mode in which the user
> can know that the math library gives the most accurate results possible.
I completely agree.
--
Vincent Lefèvre <[EMAIL PROTECTED]> - Web:
RE: facing problem with the g++ testing
On 14 November 2007 10:27, Prabhu Kalyan Rout wrote: > Hi > I am not able to test g++ with gcc3.2 test suit in dejagnu > I am getting this type of message when I am trying to test > Can any body tell me what is happening > DISCLAIMER: > This message (including attachment if any) is confidential and may be > privileged. Please do not send e-mail messages with this sort of disclaimer to [EMAIL PROTECTED] These disclaimers are prohibited by list policy, which can be found at http://gcc.gnu.org/lists.html. If you are unable to disable the disclaimer from your account, I recommend using a free web-based e-mail account. Thanks. cheers, DaveK -- Can't think of a witty .sigline today
Re: Using crlibm as the default math library in GCC sources
On Wed, 14 Nov 2007, Vincent Lefevre wrote: > On 2007-11-12 21:29:44 -0500, Geert Bosch wrote: > > On Nov 12, 2007, at 12:37, Michael Matz wrote: > >> * only double is implemented, hence long double and float are missing at > >> least, at least the long double would need some implementation work, > >> as you can't simply enlarge the mantissa and hope all your results are > >> still correct > > Initially, float could simply use double and cast the result. > > For double->float the results will remain correctly rounded. > > Yes, very probably, but this needs to be proven for each supported > function, due to the double rounding problem (this may take some time > for functions like pow). As I understand the mention of moving towards automatically generating functions, crlibm might eventually be able to provide functions for float that do most computations in double but use double double for the hard cases (like functions for double presently use double double for most cases and triple double for hard cases), through automatic generation given the type used for function inputs/outputs (float in this case) and the types available for intermediate computations (double in this case) as well as information on worst cases for rounding? > > For x86, the use of -mfpmath=sse addresses most, if not all, issues > > related to excess precision for float and double. > > But not all x86 processors support SSE2. However, I suppose you can > have crlibm support for some architectures only. It also seems to me that automatic generation might help address the x86 issues as well, by providing both SSE2 versions (IEEE double as intermediate type) and x87 versions (using long double in all intermediate computations to avoid excess precision issues). > and consistent. For instance, sin(x)*sin(x) + cos(x)*cos(x) will > always be very close to 1, as mathematically expected. FWIW, Nick Maclaren once told me that many applications don't care about accurate argument reduction for large arguments to sin and cos (for many purposes the answer just need be within a few ulp of the correct answer for an argument within a few ulp of the given argument - which would allow any answer between -1 and 1 for sin and cos of large values), but may still expect that sin^2 + cos^2 is very close to 1. -- Joseph S. Myers [EMAIL PROTECTED]
Re: How to describe function units allocation
> Hi, > For the backend TI DSP TMS320C6x, There are four types of functional > units which are .L unit, .M unit, .S unit and .D unit, and each type > consists of two units named .X1 and .X2 respectively. Namely, there are > total 8 units. Except the .M units surve only for multiply, other units > share many functions. For example, they both enable 32 bits arithmetical > operation. And in the assembly, which functional unit is used to perform > operation must be explicitly indicated. For example, ADD .S1 A0, A1, A2; > ADD .L1 A0, A1, A2; ADD .D1 A0, A1, A2 achieve the same goal by using > different units. Surely, when producing assembly, a functional unit > allocation somewhat like register allocation is needed. I wonder how can > I describe the relationship in the machine description file, and whether > I need write a functional unit allocation algorithm or it is done by a > general purpose allocation algorithm embedded in GCC, like register > allocation, I only need give some architecture descriptions? Thanks in > advance for your kind assistance. IMHO. the functional units that accompany the assembly instruction are optional. However, for c6x-gcc the reason cc1 doesnt allocate functional units is that the assembler ( as part of the c6x binutils ) does the functional unit allocation on its own. There are some notes about how the assembler does this in Extending the GNU Assembler for Texas Instruments TMS320C6x-DSP.pdf HTH, Pranav > > Regards, > Li Wang >
Re: alias and pointers analysis
deepak poola wrote: and i need to change the pointer assignments so that i can increment the assignmnets for reference counting can anybody suggest me or guide me regarding this You want to instrument every pointer assignment? You probably want to write a GIMPLE pass that looks for pointer assignments. There is information on how to write passes in the getting started section of the wiki. http://gcc.gnu.org/wiki/GettingStarted
Re: How to describe function units allocation
Hi, Thanks. As you know, I am trying to retarget GCC to a somewhat different VLIW backend by beginning from understanding the TMS320C6x port codes. Now I know that I could achieve the functional units allocation in assembler. However, I am still interesting in that if possible to do this by just modifying cc1. Not involve the assembler gas. If possible to achieve that by only coding the .md, .h and .c files? Regards, Li Wang Hi, For the backend TI DSP TMS320C6x, There are four types of functional units which are .L unit, .M unit, .S unit and .D unit, and each type consists of two units named .X1 and .X2 respectively. Namely, there are total 8 units. Except the .M units surve only for multiply, other units share many functions. For example, they both enable 32 bits arithmetical operation. And in the assembly, which functional unit is used to perform operation must be explicitly indicated. For example, ADD .S1 A0, A1, A2; ADD .L1 A0, A1, A2; ADD .D1 A0, A1, A2 achieve the same goal by using different units. Surely, when producing assembly, a functional unit allocation somewhat like register allocation is needed. I wonder how can I describe the relationship in the machine description file, and whether I need write a functional unit allocation algorithm or it is done by a general purpose allocation algorithm embedded in GCC, like register allocation, I only need give some architecture descriptions? Thanks in advance for your kind assistance. IMHO. the functional units that accompany the assembly instruction are optional. However, for c6x-gcc the reason cc1 doesnt allocate functional units is that the assembler ( as part of the c6x binutils ) does the functional unit allocation on its own. There are some notes about how the assembler does this in Extending the GNU Assembler for Texas Instruments TMS320C6x-DSP.pdf HTH, Pranav Regards, Li Wang
Re: alias and pointers analysis
Fran Baena wrote: The issue i dont understand is why alias analysis is done before the SSA pass It isn't. You are reading very stale documentation. That was the status when we were only doing type-based alias analysis. You should read the current implementation and documents. See http://gcc.gnu.org/wiki/GettingStarted. Diego.
Re: [RFC][modulo-sched] Fix scheduling order within a cycle
> > When scheduling insn 58, we calculate a window of possible cycles according > to already scheduled predecessors and successors. This window looks like a > parallelogram in general rather than a rectangle: in the first cycle there > may be predecessors (already scheduled in the first cycle, or a multiple of > II cycles away) which must_preceed insn 58 (having tight dependence with > insn 58 if it is placed in the first cycle). So insn 58 can be placed in > 'rightmost' slots of the first cycle only. Similarly, in the last cycle, > insn 58 might be placed in 'leftmost' slots only, due to successors which > must_follow insn 58. Inside internal cycles (strictly between first and > last cycles), insn 58 can be placed in any vacant slot. > > Now if (as in the above case) an already scheduled insn 61 is both a > successor and a predecessor of insn 58, it may be that (not it the above > case) insn 61 must_precede insn 58 (when looking for available slots for > insn 58 in the first cycle) and must_follow insn 58 (when looking for > available slots in the last cycle). > > Currently we apply the must_precede and must_follow restrictions to all > cycles of the window. This is overly conservative (i.e., should not produce > above wrong code!). One way to improve this is to split the window into > first cycle (with must_precede), internal part (with neither must_precede > nor must_follow), and last cycle (with must_follow). And, of-course, if > first cycle == last cycle, apply both must_precede and must_follow for it. > > > Finally, note that in the above case we traverse the window backwards with > step -1, so 'start' is the last cycle 4, and 'end' is one past the first > cycle 0 (i.e. -1). Thanks for the explanation! Is it reasonable to conclude that for the must_follow/must_precede calculation we should not relay on start/end rows (as they are influenced from the direction of the window); but use win_boundary_close_to_preds row and win_boundary_close_to_succs row, calculated from start and ends rows depending on the direction of the window (if step is 1 than in_boundery_close_to_preds = start; if step is -1 than in_boundary_close_to_preds = end, etc). win_boundary_close_to_preds will be used only for must_precede calculation and win_boundary_close_to_succs row will be used only for must_follow as you described above. Thanks, Revital
Re: alias and pointers analysis
2007/11/13, Diego Novillo <[EMAIL PROTECTED]>: > On Nov 13, 2007 1:38 PM, Fran Baena <[EMAIL PROTECTED]> wrote: > > >1. Convert the function into GIMPLE form. Implemented in gimplify.c > > and c-simplify.c. > >2. Find variable references in the code. Implemented in tree-dfa.c. > >3. Build a control-flow graph (CFG). Implemented in tree-cfg.c. > > This implementation uses the same basic_block structure used by the > > RTL optimizers. This allows us to share most of the existing CFG code. > >4. Rewrite the tree in SSA form. Implemented in tree-ssa.c. > > [] > > > > But i still doubt about the process, in some ways: > > > > * Is the step #2 related to the alias analysis? > > Yes, though this documentation is fairly old. Finding referenced > variables is needed to determine what symbols are of interest. > > > That is hold with the > > def-use chains, and SMT / NMT structures. And, make any sense doing > > these step before the SSA variable versioning? If positive answer, > > why? > > Sorry, I don't understand this question. I mean that, if that structures (def-use chains, SMT, NMT, etc) are constructed before the SSA step where the program variables are versioned, after the variable versioning we will get that these structures are not congruent with the new variables generated in the mentioned step. The issue i dont understand is why alias analysis is done before the SSA pass, and, if all the structures created within these analysis are used in next optimization passes (dead code elimination, constant propagation.) Thanks for all Fran
Re: Problem when build glibc on IA64
Ô¬Á¢Íþ wrote:
I'm a guy working on IA64 and I need to compile glibc with gcc4.2.
I tried gcc version 4.2.2 to build glibc 2.5, 2.6 and 2.7, all failed with:
internal compiler error: RTL flag check: INSN_DELETED_P used with
unexpected rtx code 'plus' in output_constant_pool_1, at varasm.c:
3393
This is lacking some info about how to reproduce. You didn't mention
which file in glibc fails to compile. You didn't how anything was
configured. Etc.
Googling for an error isn't always useful, as there are many different
ways to trigger some failures. Unfortunately, since you didn't mention
which web page you were looking at, I can't comment on that further. I
have no idea what you were looking at.
One thing I did notice, however, is that you got an internal consistency
checking failure for a release, which is odd, as releases default to
--enable-checking=release which disables most of the internal
consistency checks. So I tried building a release with
--enable-checking=yes and was able to reproduce the problem.
The failure happens with top of tree on the gcc-4.2 branch. The failure
occurs with the file iconvdata/iso-2022-cn-ext.c. I used top of tree
glibc for the test build. I can not reproduce the failure with mainline
gcc with this testcase, but the bug still appears to be there.
The problem is in output_constant_pool_1 in varasm.c. There is code
that tries to handle a LABEL_REF and also (CONST (PLUS (LABEL_REF)
...)). It does this
tmp = x;
switch (GET_CODE (x))
{
case CONST:
...
tmp = XEXP (XEXP (x, 0), 0);
/* FALLTHRU */
case LABEL_REF:
tmp = XEXP (x, 0);
which obviously doesn't work for the CONST case. We end up with a PLUS
instead of a CODE_LABEL after falling through. The fix here is to
replace every use of "x" with "tmp" inside this switch statement.
The bug is still present in gcc mainline (4.3), but I don't have a
testcase that reproduces it there.
--
Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: Can CODE_FOR_$(div$V$I$a3$) ever match?
Kai Henningsen wrote: This is genopinit.c:92 (sdivv_optab) (in revision 127595). I read this as "the next mode must be a full integer mode; add a v if it is a float mode". Which is doubly strange as this is the only place where $V is used. Am I missing something here, or is this a bug? It looks like a bug to me. The sdivv_optab rule should look like the addv/subv/smulv optab rules. Probably an oversight because this code is not immediately next to the rest of the code, and there is no target using this optab, so it went unnoticed. I also can't help but notice that none of the named patterns here are documented. There is no mention of addv, subv, smulv, sdivv, negv, or absv in doc/md.texi. One more thing, there is no divvsi3/divvdi3 in libgcc, nor in doc/libgcc.texi. This implies that if we fix the genopinit.c bug we may end up exposing a latent bug in libgcc. Hmm, maybe there is no need for sdivv as many targets already trap on divide overflow, or to say it differently, most users accept the fact that integer divide might trap, even without -ftrapv, and hence a target doesn't have to use sdivv for a trapping integer divide. In fact, looking at optabs.c, I see that there is no use of sdivv here, where as the others listed above are clearly used with -ftrapv. I think we can just delete all sdivv optab support from optabs.c, optabs.h, and genopinit.c, plus the $V operator from genopinit.c. The code was added here http://gcc.gnu.org/ml/gcc-patches/2000-10/msg00607.html Another interesting point, the ChangeLog entry doesn't mention the addition of $V. You want to try writing a patch, or maybe just file a formal bug report? -- Jim Wilson, GNU Tools Support, http://www.specifix.com
gcc-4.2-20071114 is now available
Snapshot gcc-4.2-20071114 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20071114/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch revision 130187 You'll find: gcc-4.2-20071114.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20071114.tar.bz2 C front end and core compiler gcc-ada-4.2-20071114.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20071114.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20071114.tar.bz2 C++ front end and runtime gcc-java-4.2-20071114.tar.bz2 Java front end and runtime gcc-objc-4.2-20071114.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20071114.tar.bz2The GCC testsuite Diffs from 4.2-20071107 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 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: Attributes on structs
Mark Mitchell wrote: > We had a discussion about this a while back: > > http://gcc.gnu.org/ml/gcc/2006-10/msg00318.html Ah right, I forgot about that. Thanks. Joseph S. Myers wrote: There's an additional issue to deal with now: proposals to include some form of attributes in C++0x and C1x and any semantics those may define. None of the proposals I've seen seem to do much about addressing the type system issues. Nope, none of them seem to include type attributes other than at class definition time. Looking over the status quo, the current attributes which are meaningful on a type are: packed unused aligned deprecated transparent_union visibility may_alias plus target-specific attributes. The first 4 don't create a separate TYPE_MAIN_VARIANT, so they don't cause the kind of problems we've been seeing. packed and aligned are semantic attributes, but this isn't a problem because they really only have semantics at declaration time, not for later code generation. transparent_union creates a separate TYPE_MAIN_VARIANT using build_duplicate_type, which copies the fields as well as the type node itself. I imagine that this also avoids some of the problems. visibility can only be applied at class definition time, so it isn't an issue. may_alias and target attributes are the problematic case. Most of these just get added to the TYPE_ATTRIBUTES list, and build_type_attribute_qual_variant creates a new TYPE_MAIN_VARIANT without copying the fields, which is why things break. A simple solution might be to just have build_type_attribute_qual_variant refuse to make a variant of record/enum types. This will reject the may_alias cases that break, but leave existing use of aligned/packed/unused/deprecated alone. Jason
Re: internal compiler error when build toolchains using gcc 4.1.2
马骅 wrote: > hi, > I try to build toolchains using buildroot. but when compile the > busybox, an internel compiler error show. > If you have questions about the advice gcc gave you, gcc-help mail list is the place.
Re: internal compiler error when build toolchains using gcc 4.1.2
I thought it may be a bug for gcc 4.1.2. On Nov 15, 2007 11:11 AM, Tim Prince <[EMAIL PROTECTED]> wrote: > 马骅 wrote: > > hi, > > I try to build toolchains using buildroot. but when compile the > > busybox, an internel compiler error show. > > > If you have questions about the advice gcc gave you, gcc-help mail list > is the place. >
internal compiler error when build toolchains using gcc 4.1.2
hi, I try to build toolchains using buildroot. but when compile the busybox, an internel compiler error show. The target host is arm, the host is cygwin 1.5.24. The gcc version is 4.1.2. The busybox version is 1.1.3 Could any one give a help? Thanks. Below is the log for make. make[1]: Leaving directory `/home/mahua/opt/arm/build_arm/busybox-1.1.3' touch /home/mahua/opt/arm/build_arm/busybox-1.1.3/.configured make -j1 CC=/opt/passave26_v1/bin/arm-linux-uclibc-gcc CROSS_COMPILE="/opt/passave26_v1/bin/arm-linux-uclibc-" \ CROSS="/opt/passave26_v1/bin/arm-linux-uclibc-" PREFIX="/home/mahua/opt/arm/build_arm/root" \ ARCH= \ EXTRA_CFLAGS="-Os -pipe " -C /home/mahua/opt/arm/build_arm/busybox-1.1.3 make[1]: Entering directory `/home/mahua/opt/arm/build_arm/busybox-1.1.3' GEN .depend LINK busybox_unstripped /home/mahua/opt/arm/build_arm/busybox-1.1.3/networking/telnetd.c: In function 'telnetd_main': /home/mahua/opt/arm/build_arm/busybox-1.1.3/networking/telnetd.c:541: warning: pointer targets in passing argument 3 of 'accept' differ in signedness /home/mahua/opt/arm/build_arm/busybox-1.1.3/util-linux/nfsmount.c: In function 'xdr_mountres3_ok': /home/mahua/opt/arm/build_arm/busybox-1.1.3/util-linux/nfsmount.c:1003: warning: dereferencing type-punned pointer will break strict-aliasing rules /home/mahua/opt/arm/build_arm/busybox-1.1.3/libbb/run_parts.c: In function 'valid_name': /home/mahua/opt/arm/build_arm/busybox-1.1.3/libbb/run_parts.c:35: warning: initialization discards qualifiers from pointer target type /home/mahua/opt/arm/build_arm/busybox-1.1.3/editors/vi.c: In function 'do_cmd': /home/mahua/opt/arm/build_arm/busybox-1.1.3/editors/vi.c:2989: internal compiler error: in set_iv, at tree-ssa-loop-ivopts.c:936 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[2]: *** [busybox_unstripped] Error 1 make[1]: *** [_all] Error 2 make[1]: Leaving directory `/home/mahua/opt/arm/build_arm/busybox-1.1.3' make: *** [/home/mahua/opt/arm/build_arm/busybox-1.1.3/busybox] Error 2
