On Mon, 24 Jul 2006 19:08:41 +0100, Richard Sandiford <[EMAIL PROTECTED]> wrote:
> You can set up DejaGNU's unix.exp to use rsh and rcp. It's usually
> a case of creating a board file "foo.exp" like this:
...
> and then running with "make -k check RUNTESTFLAGS='--target_board foo'".
>
> FWIW, I ca
Thanks for tackling this.
Atsushi Nemoto <[EMAIL PROTECTED]> writes:
> On 22 Jul 2006 20:58:16 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>> OK, patch is approved, with a ChangeLog entry, and assuming it passes
>> the testsuite.
>
> Thanks, here is a patch with a ChangeLog entry.
>
> I can
Atsushi Nemoto <[EMAIL PROTECTED]> writes:
> Index: gcc/config/mips/mips.md
> ===
> --- gcc/config/mips/mips.md (revision 115370)
> +++ gcc/config/mips/mips.md (working copy)
> @@ -5450,6 +5450,9 @@
> ; MIPS 32r2 specification, b
On 22 Jul 2006 20:58:16 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> OK, patch is approved, with a ChangeLog entry, and assuming it passes
> the testsuite.
Thanks, here is a patch with a ChangeLog entry.
I can cross-build gcc and glibc successfully, but unfortunately I can
not build and r
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
> On Sat, Jul 22, 2006 at 09:52:44AM -0700, Ian Lance Taylor wrote:
> > This may be right, but I'm not sure that it is. If it is OK to
> > unconditionally execute rdhwr, then it should be OK to put it in a
> > delay slot. Unless that will break somet
On Sat, Jul 22, 2006 at 09:52:44AM -0700, Ian Lance Taylor wrote:
> This may be right, but I'm not sure that it is. If it is OK to
> unconditionally execute rdhwr, then it should be OK to put it in a
> delay slot. Unless that will break something when rdhwr is emulated.
> Or will the emulation co
Atsushi Nemoto <[EMAIL PROTECTED]> writes:
> On 21 Jul 2006 10:06:34 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> > I also don't see why revision 108713 would affect this.
> >
> > But I do note that this version is still bad. The rdhwr instruction
> > is in the branch delay slot, and is
On 21 Jul 2006 10:06:34 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> I also don't see why revision 108713 would affect this.
>
> But I do note that this version is still bad. The rdhwr instruction
> is in the branch delay slot, and is therefore always executed.
Yes, and I think rdhwr sho
Atsushi Nemoto <[EMAIL PROTECTED]> writes:
> And with r108713 I got:
>
> foo:
> .frame $sp,0,$31 # vars= 0, regs= 0/0, args= 0, gp= 0
> .mask 0x,0
> .fmask 0x,0
> .setnoreorder
> .cpload $25
> .setnomacro
>
>
On 19 Jun 2006 16:45:43 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> I'm not sure, because I'm not sure what is hoisting the instruction.
>
> I tried recreating this, but I couldn't. I get this:
>
> foo:
> .frame $sp,0,$31 # vars= 0, regs= 0/0, args= 0, gp= 0
>
On 20 Jun 2006 09:10:43 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> > Should I file a bug report?
>
> Yes, please. Thanks.
Done. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28126
---
Atsushi Nemoto
Atsushi Nemoto <[EMAIL PROTECTED]> writes:
> On 19 Jun 2006 16:45:43 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> > I tried recreating this, but I couldn't. I get this:
> ...
> > This of course is not ideal, since it unconditionally executes the
> > rdhwr instruction. But it is not the s
On 19 Jun 2006 16:45:43 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> I tried recreating this, but I couldn't. I get this:
...
> This of course is not ideal, since it unconditionally executes the
> rdhwr instruction. But it is not the same as what the OP reported.
I used stock gcc 4.1.1 t
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
> On Fri, Jun 16, 2006 at 02:12:29PM -0700, Ian Lance Taylor wrote:
> > The computation of the address of x was moved outside the
> > conditional--that is, both the rdhwr and the addu moved. You'll have
> > to figure out why. gcc shouldn't move instr
On Fri, Jun 16, 2006 at 02:12:29PM -0700, Ian Lance Taylor wrote:
> The computation of the address of x was moved outside the
> conditional--that is, both the rdhwr and the addu moved. You'll have
> to figure out why. gcc shouldn't move instructions outside of a
> conditional unless they are chea
On 16 Jun 2006 14:12:29 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> > The RDHWR is executed _before_ evaluating the "arg" value. For arg ==
> > 0 case, the RDHWR has no point but just a overhead. Without -O2, the
> > RDHWR is executed _after_ the evaluation, so gcc's optimizer reorder
>
Atsushi Nemoto <[EMAIL PROTECTED]> writes:
> If I compile this code with gcc 4.1.1 (-O2),
>
> extern __thread int x;
> int foo(int arg)
> {
> if (arg)
> return x;
> return 0;
> }
>
> I got this output.
>
> foo:
> .frame $sp,0,$31 # vars= 0, regs= 0
The RDHWR instruction is used to support TLS on Linux/MIPS. For now
it is always emulated by kernel (on Reserved Instruction exception
handler), the instruction will be quite expensive.
If I compile this code with gcc 4.1.1 (-O2),
extern __thread int x;
int foo(int arg)
{
if (arg)
18 matches
Mail list logo
