On 10/14/07, Darryl L. Miles <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> On SPARC there is an ABI that is V8+ which allows the linking (and
> mixing) of V8 ABI but makes uses of features of 64bit UltraSparc CPUs
> (that were not available in the older 32bit only CPUs). Admittedly
> looking at the wa
From: "Seongbae Park (박성배, 朴成培)" <[EMAIL PROTECTED]>
Date: Tue, 16 Oct 2007 22:56:49 -0700
> We need to add DEF as well as USE:
>
> diff -r fd0f94fbe89d gcc/df-scan.c
> --- a/gcc/df-scan.c Wed Oct 10 03:32:43 2007 +
> +++ b/gcc/df-scan.c Tue Oct 16 22:52:44 2007 -0700
> @@ -3109,8 +31
It should also make it much easier for broadband suppliers to negotiate a.
The UK has come in for criticism for its slow rollout of broadband and for
setting.
On 10/16/07, David Miller <[EMAIL PROTECTED]> wrote:
> From: "Seongbae Park (박성배, 朴成培)" <[EMAIL PROTECTED]>
> Date: Tue, 16 Oct 2007 21:53:37 -0700
>
> Annyoung haseyo, Park-sanseng-nim,
:)
> > loop-invariant.cc uses ud-chain.
> > So if there's something wrong with the chain,
> > it could go nuts
From: "Seongbae Park (박성배, 朴成培)" <[EMAIL PROTECTED]>
Date: Tue, 16 Oct 2007 21:53:37 -0700
Annyoung haseyo, Park-sanseng-nim,
> loop-invariant.cc uses ud-chain.
> So if there's something wrong with the chain,
> it could go nuts.
> Can you send me the rtl dump of loop2_invariant pass ?
I have fou
On 10/16/07, David Miller <[EMAIL PROTECTED]> wrote:
> From: David Miller <[EMAIL PROTECTED]>
> Date: Tue, 16 Oct 2007 03:12:23 -0700 (PDT)
>
> > I have a bug I'm trying to investigate where, starting in gcc-4.2.x,
> > the loop invariant pass considers a computation involving a global
> > register
From: David Miller <[EMAIL PROTECTED]>
Date: Tue, 16 Oct 2007 03:12:23 -0700 (PDT)
> I have a bug I'm trying to investigate where, starting in gcc-4.2.x,
> the loop invariant pass considers a computation involving a global
> register variable as invariant across a call. The basic structure
> of t
On Wed, 2007-10-17 at 12:58 +0930, Alan Modra wrote:
> On Tue, Oct 16, 2007 at 08:21:55PM +0200, Jakub Jelinek wrote:
> > On Tue, Oct 16, 2007 at 06:02:13PM +0100, Andrew Haley wrote:
> > > The reason is that the unwinder data for CR in the vDSO is wrong. The
> > > line that affects the CR is her
On Tue, Oct 16, 2007 at 08:21:55PM +0200, Jakub Jelinek wrote:
> On Tue, Oct 16, 2007 at 06:02:13PM +0100, Andrew Haley wrote:
> > The reason is that the unwinder data for CR in the vDSO is wrong. The
> > line that affects the CR is here in
My fault.
> According to __builtin_init_dwarf_reg_size_
On 15 October 2007 23:53, Andi Kleen wrote:
> int main(void)
> {
> double x;
> printf("%d\n", __alignof__(x));
> return 0;
> }
> ~> gcc -m32 -o t t.c
> t.c: In function ‘main’:
> t.c:5: warning: incompatible implicit declaration of built-in function
> ‘printf’
I find a
Denis Tkachov wrote:
Hi all
I am having problem starting my application that is successfully built. I am
using boost to serialize/deserialize data. I have link boost library and my
project is built successfully, but I cannot run it.
Running the project (build&go in xcode) I receive this error:
Gordon Prieur wrote:
We have 2 different Macs, both running 10.4 OS but different builds
of the
same versions of gcc/g++/gdb. With the older set of tools we see gdb
failures
debugging some C++ applications (faulty line table information). Debugging
the same program on with the later builds,
Hi,
We have 2 different Macs, both running 10.4 OS but different builds
of the
same versions of gcc/g++/gdb. With the older set of tools we see gdb
failures
debugging some C++ applications (faulty line table information). Debugging
the same program on with the later builds, works fine. We'v
Jakub Jelinek writes:
> On Tue, Oct 16, 2007 at 07:22:31PM +0100, Andrew Haley wrote:
> > > and similarly linux-unwind.h should do:
> > >
> > > fs->regs.reg[R_CR2].loc.offset = (long) ®s->ccr - new_cfa;
> > > /* CR? regs are just 32-bit and PPC is big-endian. */
> > > fs->r
On Tue, Oct 16, 2007 at 07:22:31PM +0100, Andrew Haley wrote:
> > and similarly linux-unwind.h should do:
> >
> > fs->regs.reg[R_CR2].loc.offset = (long) ®s->ccr - new_cfa;
> > /* CR? regs are just 32-bit and PPC is big-endian. */
> > fs->regs.reg[R_CR2].loc.offset += sizeof (lon
On Tue, 2007-10-16 07:47:51 -0700, Denis Tkachov <[EMAIL PROTECTED]> wrote:
> I am having problem starting my application that is successfully built. I am
> using boost to serialize/deserialize data. I have link boost library and my
> project is built successfully, but I cannot run it.
This is mo
Jakub Jelinek writes:
> On Tue, Oct 16, 2007 at 06:02:13PM +0100, Andrew Haley wrote:
> > The reason is that the unwinder data for CR in the vDSO is wrong. The
> > line that affects the CR is here in
>
> According to __builtin_init_dwarf_reg_size_table on ppc64-linux
> r0..r31, fp0..fp31, m
On Tue, Oct 16, 2007 at 06:02:13PM +0100, Andrew Haley wrote:
> The reason is that the unwinder data for CR in the vDSO is wrong. The
> line that affects the CR is here in
According to __builtin_init_dwarf_reg_size_table on ppc64-linux
r0..r31, fp0..fp31, mq, lr, ctr, ap, vrsave, vscr, spe_acc, s
On Tue, Oct 16, 2007 at 12:53:13AM +0200, Andi Kleen wrote:
> > Actually no. In 32-bit mode, double is aligned on a 4 byte boundary, not
> > an 8
> > byte boundary, unless you use -malign-double, which breaks the ABI. This
> > has
> > been a 'feature' of the original AT&T 386 System V ABI that
> Yes, the gimplifier often makes several passes over the same trees to get
> them completely lowered. cp_gimplify_expr is a subroutine of the
> gimplifier.
Good, I just wanted to make sure I wasn't off my rocker or anything.
> Sure. Another alternative would be to leave the calls to gimplify
The symptom is that if you segfault and then throw an exception in the
segfault handler call-saved fields in the Condition Register are
corrupted.
The reason is that the unwinder data for CR in the vDSO is wrong. The
line that affects the CR is here in
arch/powerpc/kernel/vdso64/sigtramp.S:
rs
Aldy Hernandez wrote:
I'm in the process of converting the C++ FE to tuples. In doing so I
have noticed that the C++ FE will frequently gimplify bits of a tree,
and then expect gimplify_expr() to gimplify the rest. This seems
redundant, as gimplify_expr() more often than not will gimplify the
e
Hi Jason. Hi folks.
I'm in the process of converting the C++ FE to tuples. In doing so I
have noticed that the C++ FE will frequently gimplify bits of a tree,
and then expect gimplify_expr() to gimplify the rest. This seems
redundant, as gimplify_expr() more often than not will gimplify the
ent
Hi all
I am having problem starting my application that is successfully built. I am
using boost to serialize/deserialize data. I have link boost library and my
project is built successfully, but I cannot run it.
Running the project (build&go in xcode) I receive this error:
dyld: Library not loa
Thanks. Do you mean the TARGET_RTX_COSTS hook? Actually, I already have
made the long int more expensive in TARGET_RTX_COSTS function. It does
have effect for other optimizations (e.g., combine pass), but doesn't
work in the example mentioned in previous example.
if (INTVAL(x) >= 0 && IN
"Bingfeng Mei" <[EMAIL PROTECTED]> writes:
> Of couse, for processors without long/short instructions, this copy
> propagation is benefiical for performance by reducing unnecessary
> dependency. Therefore, whether to apply this copy propagation is machine
> dependent to some degree.
>
> What I
Hi,
In the attached testcase due to an ivopts modification, while
rewriting the uses the compiler crashes in tree-ssa-operands.c because
the number of virtual operands of the modified stmt is much greater
than the thresholds controlled by OP_SIZE_{1,2,3} in
tree-ssa-operands.c.
I went through
http
Hello,
I am working on GCC4.2.1 porting to our VLIW processor. Our No. 1
priority is code size. I noticed the following code generation:
Source code:
if (a == 0x1ff )
c = a + b;
return c;
After tree copy propagation:
foo (a, b, c)
{
:
if (a_2 == 511) goto ; else goto ;
:;
c_5 = b
md.texi of mainline as of now states at line 4451ff:
@cindex @[EMAIL PROTECTED] instruction pattern
@item @[EMAIL PROTECTED]
Similar to @[EMAIL PROTECTED] but for conditional addition. Conditionally
move operand 2 or (operands 2 + operand 3) into operand 0 according to the
comparison in operand 1
I have a bug I'm trying to investigate where, starting in gcc-4.2.x,
the loop invariant pass considers a computation involving a global
register variable as invariant across a call. The basic structure
of the code is:
register unsigned long regvar asm ("foo");
func(arg)
{
for (...) {
30 matches
Mail list logo
