Hi,
I am working on porting GCC to a new RISC architecture. The ISA does not
have a "Jump and Link Register" instruction. So I am simulating one by
replacing
jal [reg]
by
load ra, Lret
jr reg
Lret:
in RTL.
But my return label is getting optimized away. Could you ple
On Thursday 17 April 2008 05:26, Brian Dessent wrote:
> Denys Vlasenko wrote:
>
> > Only in my case, $prefix contain neither as nor ld. gcc lives in
>
> Okay, so prepend /usr/app/binutils-2.18-x86_64-linux-uclibc/bin to PATH
> and gcc will find and use x86_64-linux-uclibc-{as,ld} without any of
>
Status
==
The GCC 4.3 branch is open for commits under normal release branch
rules.
GCC 4.3.1 is due around 2008-05-05. As soon as the P1 bugs are
fixed and we have -mcld workaround for the x86 direction flag
issue, we'll release 4.3.1-rc1. One of the 4 P1s has approved
patch and one has be
On Tue, Apr 15, 2008 at 11:40 PM, Diego Novillo <[EMAIL PROTECTED]> wrote:
>
> On 4/15/08 1:34 PM, Zdenek Dvorak wrote:
>
> > Hi,
> >
> >
> > >
> > > > > To clarify what Richard means, your assertion that "you have
> updated
> > > > > SSA information" is false.
> > > > > If you had updated the S
On Tue, Apr 15, 2008 at 3:00 PM, Richard Guenther
<[EMAIL PROTECTED]> wrote:
>
> On Tue, Apr 15, 2008 at 7:49 AM, Sandeep Maram <[EMAIL PROTECTED]> wrote:
> > On Tue, Apr 15, 2008 at 10:34 AM, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> > > To clarify what Richard means, your assertion that "you
On Thu, Apr 17, 2008 at 1:35 PM, Sandeep Maram <[EMAIL PROTECTED]> wrote:
>
> On Tue, Apr 15, 2008 at 3:00 PM, Richard Guenther
> <[EMAIL PROTECTED]> wrote:
> >
> > On Tue, Apr 15, 2008 at 7:49 AM, Sandeep Maram <[EMAIL PROTECTED]> wrote:
> > > On Tue, Apr 15, 2008 at 10:34 AM, Daniel Berlin <
On Thu, Apr 17, 2008 at 5:20 PM, Richard Guenther
<[EMAIL PROTECTED]> wrote:
>
> On Thu, Apr 17, 2008 at 1:35 PM, Sandeep Maram <[EMAIL PROTECTED]> wrote:
> >
> > On Tue, Apr 15, 2008 at 3:00 PM, Richard Guenther
> > <[EMAIL PROTECTED]> wrote:
> > >
> > > On Tue, Apr 15, 2008 at 7:49 AM, Sa
Hello,
I noticed in some cases GCC 4.3.0 produces unnecessary long long data
type in tree ssa form. It results in inefficient 64-bit arithmetic in
our porting.
Original C code
void main(int *a, int *b, int *c, int j){
int i;
for(i = 0; i <= 4; i++){
int tx = j + i;
a[i] = b[tx] + c[
Tim Josling <[EMAIL PROTECTED]> writes:
> 2. Most-Gimplified front-end: Allied to Q1, which front ends have been
> most thoroughly converted to GIMPLE?
They've all been converted to generate GENERIC, or they wouldn't work.
> 3. LANG_HOOKS: There has been some discussion about LANG_HOOKS being
>
Kunal Parmar <[EMAIL PROTECTED]> writes:
> I am working on porting GCC to a new RISC architecture. The ISA does
> not have a "Jump and Link Register" instruction. So I am simulating
> one by replacing
> jal [reg]
> by
> load ra, Lret
> jr reg
> Lret:
>
> in RTL.
> But my
"Bingfeng Mei" <[EMAIL PROTECTED]> writes:
> I noticed in some cases GCC 4.3.0 produces unnecessary long long data
> type in tree ssa form. It results in inefficient 64-bit arithmetic in
> our porting.
You neglected to mention the target. I assume that pointers are
64-bits. Otherwise this beha
> "Tim" == Tim Josling <[EMAIL PROTECTED]> writes:
Tim> 1. Sample front-end: Given treelang no longer exists and "is not a good
Tim> example anyway" what would be the best front end to use as a model and
Tim> to plagiarize code?
Tim> What I don't know is how up-to-date the various front ends
I hit something in GLIBCXX_DEBUG mode the other day and I
want to ask about it.
Do list iterators remain valid after splice and merge operations?
The code is below. Is this a valid program? If not, what assumptions
am I violating?
-Dave
#include
#include
Snapshot gcc-4.3-20080417 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20080417/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Hi,
>> I am working on porting GCC to a new RISC architecture. The ISA does
>> not have a "Jump and Link Register" instruction. So I am simulating
>> one by replacing
>> jal [reg]
>> by
>> load ra, Lret
>> jr reg
>> Lret:
>>
>> in RTL.
>> But my return label is getting
Hi Joseph
> > .. the embedded C proposal as of 2008-01-18 is at stage 90.92. This
> > suggests that it's very close to being incorporated into the standard.
> > Have I understood that correctly?
>
> No. All it means is that TR 18037 is being revised, not anything to do
> with the standard. Th
Please notice that the wiki page for tuples has new rules for patches.
From now on, every patch needs to have been tested with a C-only bootstrap.
Thanks. Diego.
The tuples branch was scheduled to merge last during stage 1 (21/Apr).
At this point, it will be impossible for the branch to be ready for that
date. The current status is (http://gcc.gnu.org/wiki/tuples):
- The C front end is bootstrapping. The failure rate in the testsuites
is in the 2-4%
> - The C front end is bootstrapping. The failure rate in the
testsuites is in the 2-4% range.
I've been trying to do a C-only bootstrap of the tuples branch for a
couple of days on "Linux tim-gcc 2.6.20-15-generic #2 SMP Sun Apr 15
06:17:24 UTC 2007 x86_64 GNU/Linux" and I get
/../libdecnumber
On Wed, Apr 16, 2008 at 10:44 AM, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> Huh??? Spu support is in gcc 4.3.0.
>
Ok, GCC4.3 can compile for Cell, but what is the status of libGOMP on
Cell? Is there an efficient port of libGOMP for Cell? I assume that
the linux port could be used for Cell, bu
On Thu, Apr 17, 2008 at 8:25 PM, Sebastian Pop <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 16, 2008 at 10:44 AM, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> > Huh??? Spu support is in gcc 4.3.0.
> >
>
> Ok, GCC4.3 can compile for Cell, but what is the status of libGOMP on
> Cell? Is there an eff
On Thu, Apr 17, 2008 at 10:36 PM, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> Correct. I was just trying to correct the idea that spu support was
> not committed to the FSF GCC. Considering I am a maintainer of it
> too, I don't want people to get the wrong thought there.
>
Ok, I got an email
Kunal Parmar <[EMAIL PROTECTED]> writes:
> Is this correct :
>ret_label = gen_label_rtx ();
>emit_move_insn (gen_rtx_REG (HImode, 7),
>gen_rtx_LABEL_REF (VOIDmode,
> ret_label));
>emit_call_insn (gen_brc_call_simulate (addr, args_size));
On Thu, Apr 17, 2008 at 8:47 PM, Sebastian Pop <[EMAIL PROTECTED]> wrote:
> Ogier proposed to dump the outlined gimple to a file (i.e. LTO could
> do that) and then read this back in the SPU compiler. Does this
> approach sound right?
Yes, this was my idea also which is why I was waiting for L
24 matches
Mail list logo
