Jan Hubicka <[EMAIL PROTECTED]> writes:
>>
>> else if (rld[r].out_reg == 0
>>&& rld[r].in != 0
>>&& ((REG_P (rld[r].in)
>> && REGNO (rld[r].in) >= FIRST_PSEUDO_REGISTER
>> && !REGNO_REG_SET_P (®_has_output_reload,
>>
On Fri, 25 Aug 2006, Paolo Bonzini wrote:
> After I'm done with the base_reg_class changes, I will try
> modifying address_operand to be something along the lines of your U
> constraint:
Yeah, that does sound like the real bug; nothing should be using
non-strict checking after reload as address_op
Hello,
I would like to ask if it would be possible to write a gcc backend for the
Xilinx PicoBlaze soft processor.
If you never heard about it, please look here:
http://www.xilinx.com/ipcenter/processor_central/picoblaze/picoblaze_user_resources.htm
As I have never programmed anything like a c
> > From: [EMAIL PROTECTED] (Jack Howarth)
> > MIME-Version: 1.0
> >
> > make -k check RUNTESTFLAGS='--target_board "unix{,-m64}"'
> >
> > I run the same command from the toplevel of the darwin_objdir
> > directory, the make check bails out with...
>
> It works for me on RHEL 4 U4:
>
> http://g
"Armin Vogl" <[EMAIL PROTECTED]> writes:
> I would like to ask if it would be possible to write a gcc backend for the
> Xilinx PicoBlaze soft processor.
Porting gcc to an 8-bit microcontroller is not completely impossible,
but it is not easy. gcc was written to generate code for 32-bit
processor
Steve,
The problem is entirely due to the absence of an equal sign between
--target_board and 'unix{-m32,}'. I looked through the gcc documentation
for any mentions of --target_board and every example I found used an
equals sign after --target_board. However, I don't think this is
explicitly me
If an instruction has latency 3 and throughput 1, should I write it as
(define_insn_reservation "simple" 3
(eq_attr "memory" "none")
"p0")
or
(define_insn_reservation "simple" 3
(eq_attr "memory" "none")
"p0,nothing*2")
Are they equivalent? What happens when there are fewer reservation
Thanks for answering. I already feared that it wouldn't be trivial after
reading through the documentation ... I think a PicoBlaze backend
would be very intersting for the soft processor community.
Armin
There is no place to request a backend port, other than the e-mail you
sent. Most such req
fma3d in SPEC CPU 2K failed with revision 116385 on x86 and x86-64.
revision 116362 is OK. Has anyone else seen it?
H.J.
On Fri, Aug 25, 2006 at 06:06:47PM +0200, Armin Vogl wrote:
> Hello,
>
> I would like to ask if it would be possible to write a gcc backend for the
> Xilinx PicoBlaze soft processor.
I'll make a few comments about it.
1. 8-bit wide registers (and ALU).
GCC can generate disappointingly poo
f the 'test for excess errors' type. Sure
enough if you examine them you these are identical to those in the
-m64 libgfortran build...
Executing on host:
/sw/src/fink.build/gcc4-4.1.999-20060825/darwin_objdir/./gcc/g++ -shared-libgcc
-B/sw/src/fink.build/gcc4-4.1.999-20060825/darwin_ob
Jack Howarth wrote:
Geoff,
It appears that this issue with the ld64 link issuing warnings of
"can't find atom for N_GSYM stabs" is not specific to gfortran. I finally
figured out the correct syntax to run a complete make check so that the
libraries as well as gcc are checked. FYI, the trick is
On Aug 25, 2006, at 2:59 PM, Rask Ingemann Lambertsen wrote:
`indirect_jump'
An instruction to jump to an address which is operand zero. This
pattern name is mandatory on all machines.
I don't see how it can be supported. But most programs don't need it.
Well, the usu
Snapshot gcc-4.1-20060825 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20060825/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
I suggest that before you do anything else, you figure out how to pass
arguments to functions and figure out an instruction sequence which
performs
signed comparison.
Thaks for your comments. I start to think it is actally more complicated
that
I had first thought. I must admit that I curre
On Fri, Aug 25, 2006 at 01:51:26PM -0700, H. J. Lu wrote:
> fma3d in SPEC CPU 2K failed with revision 116385 on x86 and x86-64.
> revision 116362 is OK. Has anyone else seen it?
>
Never mind. I have an old library.
H.J.
H. J. Lu wrote:
If an instruction has latency 3 and throughput 1, should I write it as
(define_insn_reservation "simple" 3
(eq_attr "memory" "none")
"p0")
or
(define_insn_reservation "simple" 3
(eq_attr "memory" "none")
"p0,nothing*2")
Are they equivalent?
Yes.
What happens when ther
Rask Ingemann Lambertsen <[EMAIL PROTECTED]> writes:
> 4. Stack and argument passing.
>
>PicoBlaze has an internal call/return stack which can't be used for
> passing arguments. How will the STACK_POINTER_REGNUM macro and the
> "push" instruction pattern be specified?
For STACK_POINTER_REGNU
Eric,
So far the smallest test case I can come up with reproduces the
"can't find atom for N_GSYM stabs" ld64 linker warning in Darwin is...
#include
#include
// uneq_allocator as a non-empty allocator.
void
test01()
{
bool test __attribute__((unused)) = true;
using namespace std;
typ
I recently discovered an apparent latent bug in float to integer conversion
which is exposed on Darwin PPC by addition of Geoff Keating's proposed TImode
support patch...
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00581.html
With this patch in place, the 64-bit testsuite results show that t
So the problem on Darwin seems to be with conversion of the float results to
integer results.
Geoff has said he has done all he intends to with TImode for now so perhaps
someone else more
interested might take a look at this bug (which may well be independent of, but
exposed by the
TImode sup
Eric,
Does that imply that the TImode patch is a must have
for Darwin x86_64 in the gcc 4.2 release? If so you might try
to convince Geoff that it really should go into gcc trunk
before the branch occurs. Frankly I was aghast to discover
yesterday that the folks doing the Irix port managed to ge
Jack Howarth wrote:
Eric,
Does that imply that the TImode patch is a must have
for Darwin x86_64 in the gcc 4.2 release? If so you might try
to convince Geoff that it really should go into gcc trunk
before the branch occurs. Frankly I was aghast to discover
yesterday that the folks doing the I
Eric,
It would be rather unfortunate if Darwin x86_64 support didn't go
in (as long as it doesn't destabilize the Darwin ppc port). Currently
we in the fink project are already living with bastardized
gcc 4.2 prereleases in order to have any Macintel support.
I had hoped we could latch onto the
24 matches
Mail list logo
