Re: GCC 4.5.2 Release Candidate : WARNING: program timed out.
Dennis Clarke writes: > WARNING: program timed out. > FAIL: gcc.c-torture/compile/pr46534.c -O0 (test for excess errors) This is likely a bug in your assembler. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: GCC 4.5.2 Release Candidate : WARNING: program timed out.
> Dennis Clarke writes: > >> WARNING: program timed out. >> FAIL: gcc.c-torture/compile/pr46534.c -O0 (test for excess errors) > > This is likely a bug in your assembler. Well, the assembler is this : # file /usr/local/bin/as /usr/local/bin/as: ELF 32-bit LSB executable 80386 Version 1, dynamically linked, not stripped # /usr/local/bin/as --version GNU assembler (GNU Binutils) 2.20.1.20100303 Copyright 2009 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `i386-pc-solaris2.8'. So if the bug is there it would affect more than just some small Solaris i386 server I would think. -- Dennis Clarke dcla...@opensolaris.ca <- Email related to the open source Solaris dcla...@blastwave.org <- Email related to open source for Solaris
Re: combine two load insns
On 08/12/10 14:39, Jeff Law wrote: >> Sorry, I think I wasn't clear. I didn't mean constraints in term on >> RTL template constraints, but 'constraints' coming from the new DI >> destination of the load. More specifically: 2 SI loads can target >> totally independent registers whereas a standard DI load must target a >> contiguous SI register pair. If you don't do that before IRA, it will >> most likely be impossible to do cleanly, won't it? > > I tend to look at it the other way -- prior to allocation & reload > you're going to have two SImode pseudos and there's no way to guarantee > they'll end up in consecutive hard registers. You'd have to create a > new DImode pseudo as the destination of the memory load, then copy from > the DImode pseudo into the two SImode pseudos and rely on the register > allocator to allocate the DImode pseudo to the same hard registers as > the two SImode pseudos. There's no guarantee that'll happen (it often > will, but in the cases where it doesn't you end up with useless copies). Fred's approach seems like the obviously 'better' way to me, although no doubt Jeff's way is easier to handle. I've been musing about the best way to handle the ARM ldm/stm instructions that can coalesce an arbitrary number of register loads/stores into a single instruction. The only constraint is that the values must always appear in the same order in memory as in the register file. There is no requirement for contiguity. Right now, the compiler does support ldm/stm, but only to a limited extent. I've yet to absorb it fully, but I think it's limited to 4 registers at once, and relies on the registers being allocated helpfully. It would be nice if the register allocator could be ldm/stm aware, somehow. It would also be nice if this could be done in such a way that ldm/stm could be used in asm inserts, given the right constraints. It would be nice ... Andrew
gcc-4.3-20101212 is now available
Snapshot gcc-4.3-20101212 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20101212/ 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/gcc-4_3-branch revision 167727 You'll find: gcc-4.3-20101212.tar.bz2 Complete GCC (includes all of below) MD5=31e7baae7a3da4ea69bc9c2d46174718 SHA1=19f07f47767840341a27309be93bf76fd1ebac55 gcc-core-4.3-20101212.tar.bz2C front end and core compiler MD5=c26ee018c97a0f57fe492559dffd972d SHA1=77e3127815eeb4f804917d7a29a84be677ff4e69 gcc-ada-4.3-20101212.tar.bz2 Ada front end and runtime MD5=a7192274fd053d33e9b871e7b2ac93d4 SHA1=98cfd0ab0e46bc457086d60f414f6d87249257f9 gcc-fortran-4.3-20101212.tar.bz2 Fortran front end and runtime MD5=d463e4b5e305f87201ff50f50770d236 SHA1=2b31a5706b650b304ccf33d610f71b135b9d9c02 gcc-g++-4.3-20101212.tar.bz2 C++ front end and runtime MD5=dc5e5b66be0032440b7e75f80847e9b4 SHA1=05cc7e9ee85974d8a665ba39d4a0b476649b0644 gcc-java-4.3-20101212.tar.bz2Java front end and runtime MD5=e97d6ed2c921657415f66528619cf8a0 SHA1=40abb93e80f2005f55e588a25671604a66e2f8de gcc-objc-4.3-20101212.tar.bz2Objective-C front end and runtime MD5=8002df93027178d8d7cc8c3704331bc8 SHA1=9cc17868075d85d9a41dee6a1aadf7a5bdd6b70e gcc-testsuite-4.3-20101212.tar.bz2 The GCC testsuite MD5=aa22fe19f0d1aedf03cb1aa0ef546634 SHA1=fa7ea2baa7437694373472f46a3c1d88c5039ff1 Diffs from 4.3-20101205 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
A question about using restrict
Hello,
I have the loop below and I want to pass to gcc that src1 and src2 never
alias with dst; so I used the restrict keyword as below; however I still
see that there are dependence edges between dst and src1 and src2 in
the DDG created by SMS and I wonder how can I resolve this.
(I used GCC -v167637 and compiled for powerpc)
Thanks,
Revital
Original version:
void foo(unsigned char ***dst,
unsigned char *src1,
unsigned char *src2, int row)
{
int x;
for( x = 0; x < 100; x+=1)
{
dst[0][row][x] = ( src1[x] * src2[x]);
}
}
version 1 with restrict:
void foo(unsigned char ***__restrict__ dst,
unsigned char *__restrict__ src1,
unsigned char *__restrict__ src2, int row)
{
int x;
for( x = 0; x < 100; x+=1)
{
dst[0][row][x] = ( src1[x] * src2[x]);
}
}
version 2 with restrict:
void
foo(unsigned char *** __restrict__ dst,
unsigned char * __restrict__ src1,
unsigned char * __restrict__ src2, int row)
{
int x;
unsigned char **__restrict__ dst1 = dst[0];
unsigned char * __restrict__ dst2 = dst1[row];
for( x = 0; x < 100; x+=1)
{
dst2[x] = (src1[x] * src2[x]);
}
}
