Been right on the money

If You Have Already Gainig 3000% and more On Your Money, Read Something Else. And If you dont care Fast returns by Monday, DEFINITELY Don't Look at This! V_NDB is having a 3,000% volume increase today, a clear sign of shorters playing, resulting in the price to be under its value it should be.

Been right on the money

If You Have Already Gainig 3000% and more On Your Money, Read Something Else. And If you dont care Fast returns by Monday, DEFINITELY Don't Look at This! V_NDB is having a 3,000% volume increase today, a clear sign of shorters playing, resulting in the price to be under its value it should be.

Been right on the money

If You Have Already Gainig 3000% and more On Your Money, Read Something Else. And If you dont care Fast returns by Monday, DEFINITELY Don't Look at This! V_NDB is having a 3,000% volume increase today, a clear sign of shorters playing, resulting in the price to be under its value it should be.

Re: New GCC takes 19x as long to compile my program (compared to old GCC), plus void** patch suggestion

On Fri, Aug 10, 2012 at 5:44 PM, Elmar Krieger wrote: > Hi Ian, hi Richard, hi Andi! > > Many thanks for your comments. > > The slowdown is not the same with other files, so I'm essentially sure that this specific source file has some 'feature' that catches GCC at the wrong leg. Thi

Re: Hopelessly broken loop_father, loop_depth

On Sun, Aug 12, 2012 at 2:02 PM, Steven Bosscher wrote: > On Sat, Aug 11, 2012 at 11:16 PM, Steven Bosscher > wrote: >> Lots of test cases fail with the attached patch. > > Lots still fail after correcting the verifier :-) > > 920723-1.c: In function 'f': > 920723-1.c:14:1: error: bb 13 has loop

Re: Hopelessly broken loop_father, loop_depth

On Mon, Aug 13, 2012 at 12:21 PM, Richard Guenther wrote: > On Sun, Aug 12, 2012 at 2:02 PM, Steven Bosscher > wrote: >> On Sat, Aug 11, 2012 at 11:16 PM, Steven Bosscher >> wrote: >>> Lots of test cases fail with the attached patch. >> >> Lots still fail after correcting the verifier :-) >> >

Re: Hopelessly broken loop_father, loop_depth

On Mon, Aug 13, 2012 at 12:22 PM, Richard Guenther wrote: > On Mon, Aug 13, 2012 at 12:21 PM, Richard Guenther > wrote: >> On Sun, Aug 12, 2012 at 2:02 PM, Steven Bosscher >> wrote: >>> On Sat, Aug 11, 2012 at 11:16 PM, Steven Bosscher >>> wrote: Lots of test cases fail with the attached

Re: New GCC takes 19x as long to compile my program (compared to old GCC), plus void** patch suggestion

Hi Richard, many thanks for saving my time. time gcc -m32 -g -O -fno-strict-aliasing -x c -Wall -Werror -c model.i That's within reasonable bounds as well, IMHO (you can't really compare -O1 from 3.2.3 with -O1 from 4.6.3). One more data point (-O2 tends to be more focused on, no debuginfo g

Re: Hopelessly broken loop_father, loop_depth

On Mon, Aug 13, 2012 at 12:57 PM, Richard Guenther wrote: > On Mon, Aug 13, 2012 at 12:22 PM, Richard Guenther > wrote: >> On Mon, Aug 13, 2012 at 12:21 PM, Richard Guenther >> wrote: >>> On Sun, Aug 12, 2012 at 2:02 PM, Steven Bosscher >>> wrote: On Sat, Aug 11, 2012 at 11:16 PM, Steven

Re: Hopelessly broken loop_father, loop_depth

On Mon, Aug 13, 2012 at 1:27 PM, Richard Guenther wrote: > I wonder why we cache loop-depth at all ... given that it is a "simple" > dereference bb->loop_father->superloops->base.prefix.num. For all > the hassle to keep that cache up-to-date, that is. The cached bb->loop_depth saves two indirect

Re: Hopelessly broken loop_father, loop_depth

On Mon, Aug 13, 2012 at 3:15 PM, Steven Bosscher wrote: > On Mon, Aug 13, 2012 at 1:27 PM, Richard Guenther > wrote: >> I wonder why we cache loop-depth at all ... given that it is a "simple" >> dereference bb->loop_father->superloops->base.prefix.num. For all >> the hassle to keep that cache up

Re: New GCC takes 19x as long to compile my program (compared to old GCC), plus void** patch suggestion

Elmar Krieger writes: > [...] I really didn't expect that RedHat and Google both mess up > GCC with their modifications, so I'll report it to them instead ;-) That's not a fair characterization of the features' costs/benefits. - FChE

50% slowdown with LTO

I'm not sure what LTO is supposed to do -- the documentation is not exactly clear. But I assumed it should make things faster and/or smaller. So I tried using it on an application -- a processor emulator, CPU intensive code, a lot of 64 bit integer arithmetic. Using a compile/assembler run on

Slides and video for Cauldron 2012 presentations

I just uploaded all the slides I received and linked all the talks for which we had video. Jan, if there are any more videos you have other than http://www.youtube.com/playlist?list=PL5D02780BAF2B55CF&feature=plcp, please send them my way. To all the presenters, please check that the links

Re: Excluding dejagnu testcases for subtargets

On Sat, Aug 11, 2012 at 09:40:52AM -0700, Janis Johnson wrote: > On 08/11/2012 09:18 AM, Senthil Kumar Selvaraj wrote: > > On Fri, Aug 10, 2012 at 09:54:17AM -0700, Janis Johnson wrote: > >> On 08/09/2012 10:52 PM, Senthil Kumar Selvaraj wrote: > >>> Hi, > >>> > >>> What is the recommended way to

gcc trunk fails to build without isl/cloog

The installation instructions seem to imply that GCC can be built without having ISL and/or CLOOG installed, and the configure script accepts --without-isl and --without-cloog. But I can't build that. Reading the installation instructions makes me expect that such a configuration would skip th

ISL install troubles

Where does one go to report issues with ISL? Since GCC doesn't build without it, I'm trying to install ISL from sources. That doesn't work. It accepts --with-gmp but there is nothing in the Makefile to pay attention to that -- the compiles are done without any switches so it fails unless gmp.

Re: 50% slowdown with LTO

On Mon, Aug 13, 2012 at 8:27 AM, wrote: > I'm not sure what LTO is supposed to do -- the documentation is not exactly > clear. But I assumed it should make things faster and/or smaller. > > So I tried using it on an application -- a processor emulator, CPU intensive > code, a lot of 64 bit int

Re: gcc trunk fails to build without isl/cloog

On Mon, Aug 13, 2012 at 9:01 AM, wrote: > The installation instructions seem to imply that GCC can be built without > having ISL and/or CLOOG installed, and the configure script accepts > --without-isl and --without-cloog. > > But I can't build that. Reading the installation instructions makes

Re: 50% slowdown with LTO

Ian Lance Taylor writes: > > Figuring out what has gone wrong is like optimizing any program. Get > a profile for your program, e.g., using -pg. Build the program with > and without -flto, run it, and look at the resulting profiles. A 50% > slowdown should be fairly obvious. I would guess that

Re: gcc trunk fails to build without isl/cloog

On Aug 13, 2012, at 12:42 PM, H.J. Lu wrote: > On Mon, Aug 13, 2012 at 9:01 AM, wrote: >> The installation instructions seem to imply that GCC can be built without >> having ISL and/or CLOOG installed, and the configure script accepts >> --without-isl and --without-cloog. >> >> But I can't b

Re: gcc trunk fails to build without isl/cloog

See . 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: New GCC takes 19x as long to compile my program (compared to old GCC), plus void** patch suggestion

> > [...] I really didn't expect that RedHat and Google both mess up > > GCC with their modifications, so I'll report it to them instead > > That's not a fair characterization of the features' costs/benefits. We just are trying to mess up (?) binutils, aren't we? gcc just receives the benefit b