If anyone would like to obtain MPC from a pre-built package, there is a page
on the MPC website listing known providers for various OSes.
http://www.multiprecision.org/index.php?prog=mpc&page=packages
It's still missing several of our important platforms, including solaris,
aix and hpux. If you
Hi,
We just got a similar problem on Blackfin GCC recently. Let me take the
test code from the bug as an example:
typedef unsigned short u16;
typedef unsigned int u32;
u32 a(volatile u16* off) {
return *off;
}
u32 b(u16* off) {
return *off;
}
compiled with
mingw32-gcc-4.3.0.
2009/12/22 Richard Earnshaw :
>
> On Mon, 2009-12-21 at 18:44 +, Paul Brook wrote:
>> > > > I am doing a port in GCC 4.4.0 for a 32 bit target. As a part of
>> > > > scheduling framework i have to write the move patterns with more
>> > > > clarity, so that i could control the scheduling with th
Snapshot gcc-4.4-20091222 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20091222/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On 12/22/09, Daniel Jacobowitz wrote:
> Interesting, I knew you had a lot of Cirrus patches but I didn't
> realize the state of the checked-in code was so bad.
>
> Is what's there useful or actively harmful?
Neither useful nor harmful except in that it adds noise to the arm backend.
It's useful
On 12/22/09 11:16, Andrew Hutchinson wrote:
I came across this RTL on AVR in combine dump (part of va-arg-9.c test)
(set (reg:QI 25 r25 [+1 ])
(subreg:QI (sign_extend:HI (reg:QI 49)) 1))
The sign extension is completely redundant - the upper part of
register is not used elsewhere
- but th
I came across this RTL on AVR in combine dump (part of va-arg-9.c test)
(set (reg:QI 25 r25 [+1 ])
(subreg:QI (sign_extend:HI (reg:QI 49)) 1))
The sign extension is completely redundant - the upper part of register
is not used elsewhere
- but the RTL remains unchanged through all the optim
Hi,
I want to for every pointer in a program append another pointer
associated with it.
Eg. If the program has,
char *p;
I want this to be transformed into,
char *pa;
char *p
such that, (&p)-4 is same as &(pa).
I am only aware I can insert temporary variables in the gcc gimple
pass. But the or
On Tue, Dec 22, 2009 at 04:24:01PM +, Martin Guy wrote:
> I wouldn't bother implementaing that if the VFP/Cirrus conflict is the
> only thing that needs that.
> GCC's has never been able to generate working code for Cirrus
> MaverickCrunch for over a dozen separate reasons, from incorrect use
>
On 12/22/09, Daniel Jacobowitz wrote:
> in a patch I'm working on for ARM cmpdi patterns, I ended up needing
> "cmpdi_lhs_operand" and "cmpdi_rhs_operand" predicates because Cirrus
> and VFP targets accept different constants. Automatically generating
> that would be a bit excessive though.
Dave Korn wrote:
> For the declaration
>
>> int xxx(void) __asm__("_" "xxx");
>
> DECL_ASSEMBLER_NAME returns "*_xxx".
>
> I see that other parts of LTO are aware of this problem:
>
>> /* FIXME lto: this is from assemble_name_raw in varasm.c. For some
>> architectures we might
Russell King - ARM Linux wrote:
> [ ... ] this thread should probably die until some problem has actually
> been identified.
>
> If it ain't broke, don't fix.
Couldn't agree more. Happy Christmas!
cheers,
DaveK
On Tue, Dec 22, 2009 at 02:12:48PM +, Richard Earnshaw wrote:
> There is. Look at attribute "enabled".
>
> I've not worked out how to use that properly yet, but it is used in the
> m68k back-end.
Interesting. This seems to replace needing either (A) a bunch of
similar patterns with differen
On Tue, 2009-12-22 at 09:10 -0500, Daniel Jacobowitz wrote:
> On Tue, Dec 22, 2009 at 12:09:55PM +, Paul Brook wrote:
> > i.e. the following will work as expected:
> >
> > (define_insn "*my_movsi"
> > (set (match_operand:SI "..." "=a,b")
> > (match_operand:SI "..." "ab,ab")))
> >
>
On Tue, Dec 22, 2009 at 02:09:02PM +, Dave Korn wrote:
> Russell King - ARM Linux wrote:
> > On Mon, Dec 21, 2009 at 11:30:43AM -0800, Richard Henderson wrote:
> >> On 12/17/2009 10:17 AM, Russell King - ARM Linux wrote:
> >>> How is "size-optimal trap" defined?
> >> E.g. Sparc and MIPS have "t
On Tue, Dec 22, 2009 at 12:09:55PM +, Paul Brook wrote:
> i.e. the following will work as expected:
>
> (define_insn "*my_movsi"
> (set (match_operand:SI "..." "=a,b")
> (match_operand:SI "..." "ab,ab")))
>
> However the following will not. Once gcc has picked a particular insn
> (
Russell King - ARM Linux wrote:
> On Mon, Dec 21, 2009 at 11:30:43AM -0800, Richard Henderson wrote:
>> On 12/17/2009 10:17 AM, Russell King - ARM Linux wrote:
>>> How is "size-optimal trap" defined?
>> E.g. Sparc and MIPS have "tcc" instructions that trap based on the
>> condition codes, and so we
> > > Or use the more modern iterators approach.
> >
> > Aren't iterators for generating multiple insns (e.g. movsi and movdi)
> > from the same pattern, whereas in this case we have a single insn that
> > needs to accept many different operand combinartions?
>
> Yes, but that is often better, I
On 12/17/2009 06:17 PM, Richard Guenther wrote:
It shouldn't as *(int *)0 = 0; might trap. But if you want to be sure
use
__builtin_trap ();
instead for the whole sequence (the unreachable is implied then).
GCC choses a size-optimal trap representation for your target then.
Agree that it s
On Mon, 2009-12-21 at 18:44 +, Paul Brook wrote:
> > > > I am doing a port in GCC 4.4.0 for a 32 bit target. As a part of
> > > > scheduling framework i have to write the move patterns with more
> > > > clarity, so that i could control the scheduling with the help of
> > > > attributes. Re-wri
20 matches
Mail list logo
