On Tue, Mar 22, 2011 at 11:12 AM, Jakub Jelinek wrote:
> A second GCC 4.6.0 release candidate is available at:
>
> ftp://gcc.gnu.org/pub/gcc/snapshots/4.6.0-RC-20110321/
>
> Please test the tarballs and report any problems to Bugzilla.
> CC me on the bugs if you believe they are regressions from
>
On Sat, Mar 26, 2011 at 4:16 AM, Ramana Radhakrishnan
wrote:
> Hi Michael,
>
> Thanks for running these. I spent some time this morning looking
> through the results, they largely look ok though I don't have much
> perspective on the
> the objc/ obj-c++ failures.
>
> These failures here
>
> For v7
On Tue, Jun 21, 2011 at 1:01 AM, Jakub Jelinek wrote:
> The first release candidate for GCC 4.6.1 is available from
>
> ftp://gcc.gnu.org/pub/gcc/snapshots/4.6.1-RC-20110620
>
> and shortly its mirrors. It has been generated from SVN revision 175201.
>
> I have so far bootstrapped and tested the
On Mon, Aug 29, 2011 at 8:57 AM, Mikael Pettersson wrote:
> I'm seeing what appears to be a recent massive performance regression
> with trunk's gengtype, as compiled and run in stage 2, on ARM V5TE.
>
> Right now 4.7-20110827's stage2 gengtype has been running for almost
> 10 hours on my ARM buil
On Thu, Sep 8, 2011 at 8:31 PM, Richard Guenther
wrote:
> On Wed, Sep 7, 2011 at 5:28 PM, Diego Novillo wrote:
>> One of the most vexing aspects of GCC development is dealing with
>> failures in the various testsuites. In general, we are unable to
>> keep failures down to zero. We tolerate some
On Thu, Jan 19, 2012 at 9:35 PM, Yang Yueming wrote:
> I want to do some optimizations for Cortex-A15,Is anyone doing this too or is
> there any work has been done?
>
> Yang Yueming
Hi there. Cortex-A15 boards aren't readily available so most of the
work is being done by the PDSW group inside A
Hi there. The port that I'm working on has pointer registers backed
by a cache. It's unusual as the cache changes immediately when the
pointer register is modified instead of later when it is deferenced.
This means that it is cheaper to copy a base address into the pointer
register, then add the
Hi there. This is in follow up to my email on the 24 th of May.
The short version is: how can I track down why GCC is picking between
two alternatives for implementing a function? In a memcpy() where
Pmode == SImode, I get a near ideal implementation. If Pmode ==
PSImode (due to limitations of
Hi Harshal. I'm no expert, but GCC can be built by another C
compiler. If you have a look at how GCC builds you'll see that it
goes through a few stages - the first is where the local C compiler
builds a first version of GCC, and then this new version of GCC is
used to build itself. The same tec
Hi there. The architecture I'm working on porting gcc to has indirect
addressing but no constant offset or register offset versions. Code
like this:
void fill(int* p)
{
p[0] = 0;
p[1] = 0;
p[2] = 0;
p[3] = 0;
Turns into:
X = p
*X = 0
X = X + 4
*X = 0
X = p
X = X + 8
*X = 0
X = p
Hi Sergio. My port has similar addressing modes - all memory must be
accessed by one of two registers and can only be accessed indirectly,
indirect with pre increment, and indirect with post increment. The
key is GO_IF_LEGITIMATE_ADDRESS and the legitimate address helper
function. Mine looks lik
handles this just fine by splitting up any other type that fails
legitimate_address into smaller components.
-- Michael
On 10 February 2010 09:02, Sergio Ruocco wrote:
>
> Michael Hope wrote:
>> Hi Sergio. Any luck so far?
>
> Micheal, thanks for your inquiry. I made some progress, in
Hi Radu. I found the MMIX backend to be quite useful. It's
reasonably small and acceptably up to date. Keep in mind that the
MMIX is a 64 bit machine though.
The Picochip and ARM are good as well. The ARM port is very
complicated due to the number of targets that it supports but fairly
clean o
Hi there. I'm looking at porting GCC to a new architecture which has
a quite small instruction set and I'm afraid I can't figure out how to
represent unintended side effects on instructions.
My current problem is accessing memory. Reading an aligned 32 bit
word is simple using LOADACC, (X). Hal
28 [ ])) 6 {movsi} (nil))
(insn 22 16 0 2 move2.c:58 (use (reg/i:SI 5 R10)) -1 (nil))
---
Instruction 3 copies incoming argument in R10 is copied into pseudo
30. Pseudo 30 is then used at instruction 7 then instruction 9
without either being reloaded or corrected for the post increment.
--
No luck on that. I've re-baselined off GCC 4.4.0 to get the
add_reg_note function() but the register is still re-used wihtout
being reloaded.
The test case is:
--
uint32_t load_q(volatile uint8_t* p)
{
return *p + *p;
}
--
The appropriate section of the md file is:
---
(define_expand "movqi"
Thanks. I'm going to work around it for now by post correcting X -
it's a hack but I'm in the early stages of the port so I can get back
to it later.
-- Michael
2009/4/28 Ian Lance Taylor :
> Michael Hope writes:
>
>> My last RTL dump was wrong due to it hittin
HI there. I'm working on porting gcc to a new architecture which only
does indirect addressing - there is no indirect with displacement.
The problem is with spill locations in GCC 4.4.0. The elimination
code correctly elimates the frame and args pointer and replaces it
with register X. The prob
x27;t appear to need a strict
form according to the documentation but the bfin port has a strict and
non-strict version. Most of the ports have a REG_OK_FOR_BASE_P macro
with strict and non-strict versions macro but it's not documented,
isn't used, and might have been removed around gcc 4.0.
Any
ADDR_REGS, GET_MODE(x), VOIDmode, 0, 0, opnum, reload_type);
return true;
}
does that.
I tried TARGET_SECONDARY_RELOAD as well. Similar code to above would
correclty generate the code on an 'in' reload but for some reason the
code for the 'out' reload would neve
Hi there. I'm having trouble figuring out how to represent a
destructive comparison on the port I'm attempting. The ISA is very
simple and accumulator based, so to generate a compare of two
registers you would do:
; Compare R10 and R11, destroying R11 and setting C
LOADACC, R10
XOR, R11
Note t
is two operand but
I needed to supply a third pretend operand using:
emit_insn (gen_cmpcc_(cc_reg, x, y, gen_reg_rtx(SImode)));
Using a match_dup instead of operand 3 above, or supplying 'x' twice,
lead to the compiler not noticing the change.
-- Michael
2009/5/18 Jim Wilson :
>
Yip, picked that up after I sent it. Thanks.
2009/5/19 Jim Wilson :
> On Mon, 2009-05-18 at 19:58 +1200, Michael Hope wrote:
>> (set (match_operand:SI 3 "register_operand" "=1")
>> (not:SI (xor:SI (match_dup 1) (match_dup 2]
>
> not xor is
Hi there. The machine I'm working is part accumulator based, part
register based. I'm having trouble figuring out how best to tell the
compiler how ACC is affected and when.
For example, the add instruction is two operand with the destination
being a general register:
ADD, R11 is equivalent to
Hi there. I'm working on a port to an architecture where the pointer
registers X and Y are directly backed by small 128 byte caches.
Changing one of these registers to a different memory row causes a
cache load cycle, so using them for memory access is fine but using
them as general purpose regist
Hi there. The architecture I'm working is a 32 bit, word based
machine with a 16x16 -> 32 unsigned multiply. For some reason the
combine stage is converting the umulhisi3 into a mulsi3 and I'm not
sure how to track this down.
The test code is part of an alpha blend:
void blend(uint8_t* sb, uint
I've found the MMIX port to be a good place to start. It's a bit old
but the archtecture is nice and simple and the implementation nice and
brief. Watch out though as it is a pure 64 bit machine - you'll need
to think SI every time you see DI.
The trick past there is to compare the significant f
Hi there. Sorry for the noise, but I thought it would be nice to hear
from a new porter who has gotten past the first few hurdles.
The architecture I'm working on is a 32 bit accumulator based machine
with a very small instruction set. Binutils and GAS were straight
forward and after some help I
On Sat, Mar 3, 2012 at 2:44 AM, Richard Guenther wrote:
>
> GCC 4.7.0 Release Candidate available from gcc.gnu.org
>
> The first release candidate for GCC 4.7.0 is available from
>
> ftp://gcc.gnu.org/pub/gcc/snapshots/4.7.0-RC-20120302
>
> and shortly its mirrors. It has been generated from SVN
On 3 June 2012 17:06, i-love-spam wrote:
> I'm writing some optimized functions for gcc-arm in a library that obuses
> shorts. So the problem I have is that in extremely many places resutls of my
> optimized functions are needlessly sign or zero extended. That is, gcc adds
> UXTH or SXTH opcode
On 6 June 2012 22:14, Richard Guenther wrote:
>
> The first release candidate for GCC 4.7.1 is available from
>
> ftp://gcc.gnu.org/pub/gcc/snapshots/4.7.1-RC-20120606
>
> and shortly its mirrors. It has been generated from SVN revision 188257.
>
> I have so far bootstrapped and tested the relea
On 26 June 2012 00:48, Nathanaël Prémillieu wrote:
> Hi all,
>
> I am using the gcc ARM cross-compiler (gcc version 4.6.3 (Ubuntu/Linaro
> 4.6.3-1ubuntu5)). Compiling the test.c code (in attachement) with:
>
> 'arm-linux-gnueabi-gcc -S test.c'
>
> I obtain the test.s assembly code (in attachement)
On 11 October 2012 17:58, Grant wrote:
>>> Hello, I'm working with the BeagleBone and gcc-4.5.4 on Gentoo. If I
>>> try to compile the 3.6 kernel with CONFIG_THUMB2_KERNEL, I get:
>>>
>>> arch/arm/boot/compressed/head.S:127: Error: selected processor does
>>> not support requested special purpose
33 matches
Mail list logo
