Re: X32 project status update

2011-05-21 Thread H.J. Lu
On Sat, May 21, 2011 at 1:01 PM, Anvin, H Peter wrote: > I'll look at it but possibly not until the weekend. I checked it into hjl/x32/syscall branch at http://git.kernel.org/?p=linux/kernel/git/hjl/linux-2.6.38.y.git;a=summary H.J. --- > -Original Message- > From: H.J. Lu [hjl.to...@g

gcc-4.7-20110521 is now available

2011-05-21 Thread gccadmin
Snapshot gcc-4.7-20110521 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20110521/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk

RE: X32 project status update

2011-05-21 Thread Anvin, H Peter
I'll look at it but possibly not until the weekend. -Original Message- From: H.J. Lu [hjl.to...@gmail.com] Sent: Saturday, May 21, 2011 12:39 PM Pacific Standard Time To: Anvin, H Peter Cc: x32-...@googlegroups.com; Arnd Bergmann; GCC Development; GNU C Library;

Re: X32 project status update

2011-05-21 Thread H. Peter Anvin
On 05/21/2011 09:27 AM, H.J. Lu wrote: > On Sat, May 21, 2011 at 8:34 AM, H.J. Lu wrote: >> On Sat, May 21, 2011 at 8:27 AM, Arnd Bergmann wrote: >>> On Saturday 21 May 2011 17:01:33 H.J. Lu wrote: This is the x32 project status update: https://sites.google.com/site/x32abi/ >>

Re: X32 project status update

2011-05-21 Thread H.J. Lu
On Sat, May 21, 2011 at 8:34 AM, H.J. Lu wrote: > On Sat, May 21, 2011 at 8:27 AM, Arnd Bergmann wrote: >> On Saturday 21 May 2011 17:01:33 H.J. Lu wrote: >>> This is the x32 project status update: >>> >>> https://sites.google.com/site/x32abi/ >>> >> >> I've had another look at the kernel patch.

Re: X32 project status update

2011-05-21 Thread H.J. Lu
On Sat, May 21, 2011 at 8:27 AM, Arnd Bergmann wrote: > On Saturday 21 May 2011 17:01:33 H.J. Lu wrote: >> This is the x32 project status update: >> >> https://sites.google.com/site/x32abi/ >> > > I've had another look at the kernel patch. It basically > looks all good, but the system call table a

Re: X32 project status update

2011-05-21 Thread Arnd Bergmann
On Saturday 21 May 2011 17:01:33 H.J. Lu wrote: > This is the x32 project status update: > > https://sites.google.com/site/x32abi/ > I've had another look at the kernel patch. It basically looks all good, but the system call table appears to diverge from the x86_64 list for no (documented) reaso

X32 project status update

2011-05-21 Thread H.J. Lu
Hi, This is the x32 project status update: https://sites.google.com/site/x32abi/ With the latest x32 kernel semctl bug fix, C, C++ and Fortran test results on GCC x32 branch only show one serious bug: FAIL: gcc.c-torture/execute/builtins/strcspn.c execution, -O1 It is due to the combine issue

PING^2 [PATCH] Support for AMD64 targets running GNU/kFreeBSD

2011-05-21 Thread Robert Millan
Please can this patch be considered? It's several months old (sent in Jan 2011), and it is critical to use of GCC on GNU/kFreeBSD. 2011/1/26 Robert Millan : > Ping! > > 2011/1/18 Robert Millan : >> 2011/1/14 Robert Millan : >>> 2011/1/12 Robert Millan : > * The headers config/kfreebsd-gnu.h et

Re: missed optimization: transforming while(n>=1) into if(n>=1)

2011-05-21 Thread Paolo Bonzini
On 05/21/2011 08:07 AM, Matt Turner wrote: I suppose this is a missed optimization. Is this known, or should I make a new bug report? It's always better to do that. In this case, the bug is that when we compute a range from an ASSERT_EXPR, and the base variable has a known but symbolic range

Re: missed optimization: transforming while(n>=1) into if(n>=1)

2011-05-21 Thread Siarhei Siamashka
On Sat, May 21, 2011 at 9:07 AM, Matt Turner wrote: > Hi, > > While trying to optimize pixman, I noticed that gcc is unable to > recognize that 'while (n >= 1)' can often be simplified to 'if (n >= > 1)'. Consider the following example, where there are loops that > operate on larger amounts of dat

Re: mips-elf-gcc -fno-delayed-branch problem

2011-05-21 Thread Richard Sandiford
Toshi Morita writes: > Maybe GAS could recognize -fno-delayed-branch to selectively disable > branch slot filling? I'd agree if it was -mno-delayed-branch. I think -f* options are generally compiler options, while -m* options are target options that could in principle be passed down to either th