Cross compiler
Hi, all: I need a gcc cross compiler under Cygwin. Is there any step-by-step document on how to make the cross compiler? Any help would be appriciated very much! Thanks and regards Eric
Re: Cross compiler
Eric Liu wrote: > > I need a gcc cross compiler under Cygwin. Is there any step-by-step document > on how to make the cross compiler? Any help would be appriciated very much! See: http://billgatliff.com/~bgat/twiki/bin/view/Crossgcc http://gcc.gnu.org/wiki/Cross%20Compiler http://gcc.gnu.org/wiki/Building%20Cross%20Toolchains%20with%20gcc HTH, Ranjit. -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/
RE: Cross compiler
Original Message >From: Ranjit Mathew >Sent: 24 June 2005 11:09 > Eric Liu wrote: >> >> I need a gcc cross compiler under Cygwin. Is there any step-by-step >> document on how to make the cross compiler? Any help would be >> appriciated very much! > > See: > > http://billgatliff.com/~bgat/twiki/bin/view/Crossgcc > http://gcc.gnu.org/wiki/Cross%20Compiler > http://gcc.gnu.org/wiki/Building%20Cross%20Toolchains%20with%20gcc > > HTH, > Ranjit. And don't forget http://www.kegel.com/crosstool/ cheers, DaveK -- Can't think of a witty .sigline today
Suggestion for simple feature - "beep" on finish.
Hi all. So much compiling is done in the wee hours of the morning and it is nice to just shut your eyes for a while when the messages are scrolling past. Trouble is, you have to take a peek every now and then to see if it is finished. A very simple feature I think would be good is when compiling is finished the pc speaker could give a beep, prompting you to come back to "userland" ;-) Regards, Graham Pratt.
removing src/{expect,dejagnu}
For the second year in a row, about 30 people discussed removing the replicated copies of the DejaGnu and Expect sources from the src repository at the GCC Summit testing BOF. The version of Expect in the tree is now 9 years old. The version of DejaGnu in the tree is now two releases behind. Modern systems provide up-to-date versions of these packages and are easy to install. Unless there are any violent objections, I intend to remove these directories in a couple of days' time. Cheers, Ben pgpj16D8KZKvQ.pgp Description: PGP signature
Re: Suggestion for simple feature - "beep" on finish.
Graham Pratt <[EMAIL PROTECTED]> writes: > So much compiling is done in the wee hours of the morning and it is nice to > just shut your eyes for a while when the messages are scrolling past. Trouble > is, you have to take a peek every now and then to see if it is finished. A > very simple feature I think would be good is when compiling is finished the > pc speaker could give a beep, prompting you to come back to "userland" ;-) PROMPT_COMMAND=$'echo -ne \'\\a\'' 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: Suggestion for simple feature - "beep" on finish.
Andreas Schwab wrote: Graham Pratt <[EMAIL PROTECTED]> writes: So much compiling is done in the wee hours of the morning and it is nice to just shut your eyes for a while when the messages are scrolling past. Trouble is, you have to take a peek every now and then to see if it is finished. A very simple feature I think would be good is when compiling is finished the pc speaker could give a beep, prompting you to come back to "userland" ;-) PROMPT_COMMAND=$'echo -ne \'\\a\'' Andreas. That's something you can trivially program using an appropriate command file, so I don't see that it is something you would put into gcc itself.
Re: How to replace -O1 with corresponding -f's?
Andrew Pinski <[EMAIL PROTECTED]> writes:
> On Jun 20, 2005, at 11:28 AM, Sergei Organov wrote:
>
> > Andrew Pinski <[EMAIL PROTECTED]> writes:
> >
> >> On Jun 20, 2005, at 10:54 AM, Sergei Organov wrote:
> >>
> >>> so SYMBOL_FLAG_SMALL (flags 0x6 vs 0x2) is somehow being missed when -O1
>
> >>
> >>> is turned on. Seems to be something at tree-to-RTX conversion time.
> >>> Constant folding?
> >>
> >> No, it would mean that the target says that this is not a small data.
> >> Also try it with the following code and you will see there is no
> >> difference:
>
> >>
> >> double osvf() { return 314314314; }
> >
> > There is no difference in the sense that here both -O0 and -O1 behave
> > roughly the same. So the problem is with detecting "smallness" for true
> > constants by the target, right?
>
> I think the bug is in rs6000_elf_in_small_data_p but since I have not
> debuged it yet I don't know for sure.
No, the bug is not there as the function is never called for this
constant. The constant is generated in RTL and thus can't be passed
to this routine expecting tree.
The debugging shows that the constant in question first appears within
small_data_operand(op, mode) in the form:
op = (symbol_ref/u:SI (".LC0") [flags 0x2])
mode = DFmode
without the SYMBOL_FLAG_SMALL set resulting in returning 0 by the
routine.
We can naively try to add code at this point that checks
GET_MODE_SIZE(mode) and return 1 if the size is less than or equal to
the limit for sdata2 (=g_switch_value). However this attempt is not
satisfactory as later this same constant appears at the same place
as:
op = (symbol_ref/u:SI (".LC0") [flags 0x2])
mode = SImode(!)
Now, provided g_switch_value is set to 4 (it's default value is 8), we
would return 0 in the first case and 1 in the second case for the same
constant! The resulting assembly is weird.
The latter appearance of the constant with mode=SImode is due to call to
memory_address(DFMode, op) that calls force_reg(Pmode(=SImode), op)
#0 small_data_operand (op=0x401e2730, mode=SImode)
at ../../../gcc/gcc/config/rs6000/rs6000.c:2358
#1 0x08704fb0 in rs6000_emit_move (dest=0x401e2740, source=0x401e2730,
mode=SImode) at ../../../gcc/gcc/config/rs6000/rs6000.c:3720
#2 0x0852cfb8 in gen_movsi (operand0=0x401e2740, operand1=0x401e2730)
at ../../../gcc/gcc/config/rs6000/rs6000.md:7410
#3 0x08430c3c in emit_move_insn_1 (x=0x401e2740, y=0x401e2730)
at ../../../gcc/gcc/expr.c:3086
#4 0x08431020 in emit_move_insn (x=0x401e2740, y=0x401e2730)
at ../../../gcc/gcc/expr.c:3164
#5 0x08410891 in force_reg (mode=SImode, x=0x401e2730)
at ../../../gcc/gcc/explow.c:607
#6 0x0841029b in memory_address (mode=DFmode, x=0x401e2730)
at ../../../gcc/gcc/explow.c:409
At this stage I gave up trying to solve this puzzle. Any ideas how to
fix that?
--
Sergei.
Re: removing src/{expect,dejagnu}
From: Ben Elliston <[EMAIL PROTECTED]> Date: Fri, 24 Jun 2005 23:50:58 +1000 For the second year in a row, about 30 people discussed removing the replicated copies of the DejaGnu and Expect sources from the src repository at the GCC Summit testing BOF. The version of Expect in the tree is now 9 years old. The version of DejaGnu in the tree is now two releases behind. Modern systems provide up-to-date versions of these packages and are easy to install. Unless there are any violent objections, I intend to remove these directories in a couple of days' time. Yes, please!
[RFH] - Less than optimal code compiling 252.eon -O2 for x86
A source file mrSurfaceList.cc of 252.eon produces less efficient
code initializing instance objects to 0 at -O2 than at -O1. Behavior
is random and it does not happen on all x86 platforms and making the
test smaller makes the problem go away. But here is what I found out
is the cause.
When source is compiled with -O1 -march=pentium4, 'cse' phase sees
the following pattern initializing a 'double' with 0.
(insn 18 13 19 0 (set (reg:SF 109)
(mem/u/i:SF (symbol_ref/u:SI ("*LC11") [flags 0x2]) [0 S4
A32])) -1 (nil)
(nil))
(insn 19 18 20 0 (set (mem/s/j:DF (plus:SI (reg/f:SI 20 frame)
(const_int -32 [0xffe0])) [0
objectBox.pmin.e+16 S8 A128])
(float_extend:DF (reg:SF 109))) 86 {*extendsfdf2_sse} (nil)
(nil))
Then fold_rtx routine converts it into its reduced form, resulting
in optimum code:
(insn 19 13 21 0 (set (mem/s/j:DF (plus:SI (reg/f:SI 20 frame)
(const_int -32 [0xffe0])) [0
objectBox.pmin.e+16 S8 A128])
(const_double:DF 0.0 [0x0.0p+0])) 64 {*movdf_nointeger} (nil)
(nil))
But when the same source is compiled with -O2 march=pentium4, 'cse'
phase sees a slightly different pattern (note that float_extend:DF
has moved)
(insn 18 13 19 0 (set (reg:DF 109)
(float_extend:DF (mem/u/i:SF (symbol_ref/u:SI ("*LC13")
[flags 0x2]) [0 S4 A32]))) -1 (nil)
(nil))
(insn 19 18 20 0 (set (mem/s/j:DF (plus:SI (reg/f:SI 20 frame)
(const_int -32 [0xffe0])) [0
objectBox.pmin.e+16 S8 A128])
(reg:DF 109)) 64 {*movdf_nointeger} (nil)
(nil))
This cannot be simplified by fold_rtx, resulting in less efficient code.
Change in pattern is most likely because of additional tree
optimization phases running at -O2. If so, then should the cse be
taught to simplify the new rtl pattern. Or, the tree optimizer phase
responsible for the less than optimal tree need be twiked to generate
the same tree as with -O1?
Thanks, fariborz
Re: [RFH] - Less than optimal code compiling 252.eon -O2 for x86
On Jun 24, 2005, at 6:07 PM, Fariborz Jahanian wrote:
A source file mrSurfaceList.cc of 252.eon produces less efficient code
initializing instance objects to 0 at -O2 than at -O1. Behavior is
random and it does not happen on all x86 platforms and making the
test smaller makes the problem go away. But here is what I found out
is the cause.
This cannot be simplified by fold_rtx, resulting in less efficient
code.
I wonder why combine can do the simplification though which is why still
produce good code for the simple testcase:
void f1(double *d,float *f2)
{
*f2 = 0.0;
*d = 0.0;
}
Thanks,
Andrew Pinski
Re: toplevel bootstrap (stage 2 project)
On Wed, 22 Jun 2005, Giovanni Bajo wrote: > It would help also if you add to the wiki explanation of what exactly all > these options do. Especially bubblestrap vs quickstrap vs restrap. Why to the WIki?? This should be part of the regular documentation, and if anything is to improve, the improvements should be made there instead of having that on the Wiki (or, even worse, causing duplication). Gerald
Re: [RFH] - Less than optimal code compiling 252.eon -O2 for x86
On Jun 24, 2005, at 3:16 PM, Andrew Pinski wrote:
I wonder why combine can do the simplification though which is why
still
produce good code for the simple testcase:
void f1(double *d,float *f2)
{
*f2 = 0.0;
*d = 0.0;
}
It is hard to reproduce the simple test case, exhibiting the same
problem (-O1 producing better code than -O2). Yes, small test cases
move the desired simplification to other phases.
- fariborz
Thanks,
Andrew Pinski
Re: [RFH] - Less than optimal code compiling 252.eon -O2 for x86
On Saturday 25 June 2005 01:48, fjahanian wrote:
> On Jun 24, 2005, at 3:16 PM, Andrew Pinski wrote:
> > I wonder why combine can do the simplification though which is why
> > still
> > produce good code for the simple testcase:
> > void f1(double *d,float *f2)
> > {
> > *f2 = 0.0;
> > *d = 0.0;
> > }
>
> It is hard to reproduce the simple test case, exhibiting the same
> problem (-O1 producing better code than -O2). Yes, small test cases
> move the desired simplification to other phases.
It often helps if you know what function your poorer code is in. You
could e.g. try to make the .optimized dump of that function compilable
and see if the problem shows up there again. Then work your way down
to something small.
Gr.
Steven
RSS feed for webpage?
Would it be possible for the GCC webpage to have a RSS feed for the news? Samuel Lauber -- ___ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com
