libgomp forces -Werror even when top level configure --disable-werror

2009-02-19 Thread Laurent GUERBY
Hi, Trunk bootstrap on powerpc64-linux (debian etch) fails on a warning during libgomp build: << if /bin/sh ./libtool --tag=CC --mode=compile /home/guerby/build-144268/./gcc/xgcc -B/home/guerby/build-144268/./gcc/ -B/n/41/guerby/install-trunk-144268/powerpc64-unknown-linux-gnu/bin/ -B/n/41/gue

[lto] Pass ordering and the different lto1 personalities

2009-02-19 Thread Diego Novillo
We were chatting on IRC about the problem Simon found with IPCP getting confused because during -fwhopr builds, the inliner always runs first, so when LTRANS starts up, we run all the IPA passes before applying inlining decisions. This confuses IPCP. For lto1 we have 3 different modes of operatio

Build report for AIX 5.3

2009-02-19 Thread Mario Linke
Hi, i just built GCC 4.3.3 on AIX 5.3 using the following commands: setenv LDR_CNTRL MAXDATA=0x4000 ../gcc-4.3.3/configure --disable-multilib --with-gmp=/usr/local make bootstrap-lean make install $ config.guess powerpc-ibm-aix5.3.0.0 $ gcc -v Using built-i

Re: [lto] Pass ordering and the different lto1 personalities

2009-02-19 Thread Rafael Espindola
> The problem here is that LTRANS will run the standard pipeline > over a callgraph that hasn't been "settled" (i.e., no inlining > decisions have been applied yet). Perhaps the first thing LTRANS > should do is just call execute_all_ipa_transforms() and then > proceed with the regular pipeline.

Re: [lto] Pass ordering and the different lto1 personalities

2009-02-19 Thread Diego Novillo
On Thu, Feb 19, 2009 at 11:13, Rafael Espindola wrote: > To make this extra clean, we can just create a execute_wpa_decisions > pass that only runs in ltrans and is the first one. Probably. However, we should be able to reorder passes in the pipeline arbitrarily. This is something that should

Re: [lto] Pass ordering and the different lto1 personalities

2009-02-19 Thread Jan Hubicka
> > The problem here is that LTRANS will run the standard pipeline > > over a callgraph that hasn't been "settled" (i.e., no inlining > > decisions have been applied yet). Perhaps the first thing LTRANS > > should do is just call execute_all_ipa_transforms() and then > > proceed with the regular p

IPA-CP as IPA_PASS in Whopr

2009-02-19 Thread Jan Hubicka
> > > The problem here is that LTRANS will run the standard pipeline > > > over a callgraph that hasn't been "settled" (i.e., no inlining > > > decisions have been applied yet). Perhaps the first thing LTRANS > > > should do is just call execute_all_ipa_transforms() and then > > > proceed with the

CPP and column numbers

2009-02-19 Thread Aldy Hernandez
Hi Tom. Hi folks. Imagine: enum e { E5 = INTMAX + 1, ^ column 15. }; This addition will trigger an overflow warning in the C FE. However, the location of the '+' will not be column 15 as expected, but the pre-processed column number (19): E5 = 2147483647 + 1,

gcc-4.3-20090219 is now available

2009-02-19 Thread gccadmin
Snapshot gcc-4.3-20090219 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20090219/ 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

Can you use gprof on shared libraries?

2009-02-19 Thread Scott Simpson
I have a single threaded application that uses shared libraries. I compile the app and the shared libraries with -pg. This gives me a gmon.out when I run, however, gprof doesn't seem to print any of the information from the shared libraries. Is there any way to get this information in shared librar

Re: CPP and column numbers

2009-02-19 Thread Tom Tromey
> "Aldy" == Aldy Hernandez writes: Aldy> enum e { Aldy> E5 = INTMAX + 1, Aldy> ^ column 15. Aldy> }; I updated from your branch and tried this. My error message had column 3... but I assume that is due to something missing or due to over-eager folding (and thus probably fixe

Question about RTL expander?

2009-02-19 Thread JCX
Hello, After I vectorize the following file by GCC for testing, it gets the right "129t.final_cleanup" file. However, it expands to the wrong vector type when stores the "short int" into memory. I have checked many times, but I still don't know why. Can anyone help me? The source file is: short i