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
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
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
> 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.
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
> > 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
> > > 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
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,
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
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
> "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
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
12 matches
Mail list logo