patch: don't issue -Wreorder warnings when order doesn't matter

2011-07-29 Thread Daniel Marjamäki
Hello! In my humble opinion the -Wreorder has noise. When the order doesn't matter I would prefer that warnings are not issued. In this email I include a patch that I would like to get comments about. The patch will suppress warnings if all members are initialized with constant values. I am not v

Re: RFC: PATCH: Require and use int64 for x86 options

2011-07-29 Thread Paolo Bonzini
On 07/27/2011 06:42 PM, H.J. Lu wrote: + if (max == 64) + var_mask_1[var] = "1LL" This must be ((HOST_WIDE_INT)1). Paolo

Re: patch: don't issue -Wreorder warnings when order doesn't matter

2011-07-29 Thread Richard Guenther
2011/7/29 Daniel Marjamäki : > Hello! > > In my humble opinion the -Wreorder has noise. When the order doesn't > matter I would prefer that warnings are not issued. > > In this email I include a patch that I would like to get comments > about. The patch will suppress warnings if all members are ini

Re: patch: don't issue -Wreorder warnings when order doesn't matter

2011-07-29 Thread Jakub Jelinek
On Fri, Jul 29, 2011 at 11:53:08AM +0200, Richard Guenther wrote: > 2011/7/29 Daniel Marjamäki : > Why doesn't it matter in this case but it matters when the initializer > are non-constant? Plus the documentation of -Wreorder even uses constants: `-Wreorder (C++ and Objective-C++ only)' Warn

Defining constraint for registers tuple

2011-07-29 Thread Kirill Yukhin
Hi guys, I'm working on implementation of `mulx` (which is part of BMI2). One of improvements compared generic `mul` is that it allows to specify destination registers. For `mul` we have `A` constraint, which stands for AX:DX pair. So, is there a possibility to relax such cinstraint and allow any p

Re: Re: patch: don't issue -Wreorder warnings when order doesn't matter

2011-07-29 Thread Daniel Marjamäki
Hello! > Why doesn't it matter in this case but it matters when the initializer > are non-constant? It doesn't matter because the program will behave the same no matter if the initializations are reordered or not. Logically it will behave just as the user expects no matter if he expects reorderin

Re: Re: patch: don't issue -Wreorder warnings when order doesn't matter

2011-07-29 Thread Richard Guenther
2011/7/29 Daniel Marjamäki : > Hello! > >> Why doesn't it matter in this case but it matters when the initializer >> are non-constant? > > It doesn't matter because the program will behave the same no matter > if the initializations are reordered or not. Logically it will behave > just as the user

Re: Defining constraint for registers tuple

2011-07-29 Thread Ian Lance Taylor
Kirill Yukhin writes: > I'm working on implementation of `mulx` (which is part of BMI2). One > of improvements compared generic `mul` is that it allows to specify > destination registers. > For `mul` we have `A` constraint, which stands for AX:DX pair. > So, is there a possibility to relax such c

Re: Re: patch: don't issue -Wreorder warnings when order doesn't matter

2011-07-29 Thread Daniel Marjamäki
2011/7/29 Richard Guenther : > 2011/7/29 Daniel Marjamäki : >> Hello! >> >>> Why doesn't it matter in this case but it matters when the initializer >>> are non-constant? >> >> It doesn't matter because the program will behave the same no matter >> if the initializations are reordered or not. Logica

Re: Performance degradation on g++ 4.6

2011-07-29 Thread Xinliang David Li
My guess is inlining differences. Try more aggressive inline parameters to see if helps. Also try FDO to see there is any performance difference between two versions. You will probably need to do first level triage and file bug reports. David On Fri, Jul 29, 2011 at 10:56 AM, Oleg Smolsky wrote

Re: IRA vs CANNOT_CHANGE_MODE_CLASS, + 4.7 IRA regressions?

2011-07-29 Thread Vladimir Makarov
On 07/27/2011 05:59 PM, Sandra Loosemore wrote: Consider this bit of code: extern double a[20]; double test1 (int n) { double accum = 0.0; int i; for (i=0; imipsisa32r2-sde-elf-gcc -O3 -fno-inline -fno-unroll-loops -march=74kf1_1 -S abstest.c With a GCC 4.6 compiler, this produces: ..

Re: Performance degradation on g++ 4.6

2011-07-29 Thread Oleg Smolsky
Hey David, here are a couple of answers and notes: - I built the test suite with -O3 and cannot see anything else related to inlining that isn't already ON (except for -finline-limit=n which I do not how to use) http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html - FTO looks lik

Re: Performance degradation on g++ 4.6

2011-07-29 Thread Xinliang David Li
On Fri, Jul 29, 2011 at 11:57 AM, Oleg Smolsky wrote: > Hey David, here are a couple of answers and notes: >    - I built the test suite with -O3 and cannot see anything else related to > inlining that isn't already ON (except for -finline-limit=n which I do not > how to use) size estimation, inl

Re: X32 project status update

2011-07-29 Thread H.J. Lu
Hi, This is the x32 project status update: https://sites.google.com/site/x32abi/ We have settled down on a preliminary system call number scheme: 1. In kernel, x86-64 and x32 share the same system call slot if they are the same. 2. First 512 system call slots are reserved for common and x86-64

gcc-4.6-20110729 is now available

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