VTA guality assessment: better than -O0 ;-)

2009-06-13 Thread Alexandre Oliva
So, after I tested and installed this patch http://gcc.gnu.org/ml/gcc-patches/2009-06/msg00903.html I started looking closely at the guality (debug info quality) test results. So far, I have only added two very simple tests to the guality testsuite, but they already show very promising results. G

Re: VTA guality assessment: better than -O0 ;-)

2009-06-13 Thread Richard Guenther
On Sat, Jun 13, 2009 at 9:29 AM, Alexandre Oliva wrote: > So, after I tested and installed this patch > http://gcc.gnu.org/ml/gcc-patches/2009-06/msg00903.html I started > looking closely at the guality (debug info quality) test results. > > So far, I have only added two very simple tests to the gu

Re: VTA guality assessment: better than -O0 ;-)

2009-06-13 Thread Eric Botcazou
> Yes, I don't like -O0 producing worse debug info - what does > the -O0 -fvar-tracking-assignments results look like? I'd do the opposite: totally disable VTA at -O0 like we do for -fvar-tracking. We once tried to enable -fvar-tracking with -O0 at AdaCore and ended up with bloated and inferior d

Re: VTA guality assessment: better than -O0 ;-)

2009-06-13 Thread Richard Guenther
On Sat, Jun 13, 2009 at 8:00 PM, Eric Botcazou wrote: >> Yes, I don't like -O0 producing worse debug info - what does >> the -O0 -fvar-tracking-assignments results look like? > > I'd do the opposite: totally disable VTA at -O0 like we do for -fvar-tracking. > We once tried to enable -fvar-tracking

Re: VTA guality assessment: better than -O0 ;-)

2009-06-13 Thread Eric Botcazou
> Well, I see FAILs for -O0 compared to -O1 with VTA - that doesn't look > "right". How we fix this is not relevant - but we should try to do so. It would be better not to artificially introduce them in the first place. -- Eric Botcazou

Re: VTA guality assessment: better than -O0 ;-)

2009-06-13 Thread Alexandre Oliva
On Jun 13, 2009, Richard Guenther wrote: > Yes, I don't like -O0 producing worse debug info - what does > the -O0 -fvar-tracking-assignments results look like? No difference, -fvar-tracking is disabled at -O0, so either -fvar-tracking-assignments gets disabled as well with a warning (as in the v

Re: VTA guality assessment: better than -O0 ;-)

2009-06-13 Thread Jakub Jelinek
On Sat, Jun 13, 2009 at 08:00:35PM +0200, Eric Botcazou wrote: > > Yes, I don't like -O0 producing worse debug info - what does > > the -O0 -fvar-tracking-assignments results look like? > > I'd do the opposite: totally disable VTA at -O0 like we do for -fvar-tracking. > We once tried to enable -fv

Speed regression (m68k)

2009-06-13 Thread ami_stuff
Hi, I notice about 20% speed regression with GCC 4.4.0 PNGCrush build compared to GCC 3.4.0 build (Amiga 68...@50mhz). CFLAGS = -I. -DNO_FSEEKO -O2 -fomit-frame-pointer -Wall -m68060 -s Here are the results: GCC 3.4.0: CPU time used = 267.340 seconds (decoding 16.940, encoding 247.800, other

Regressions with dwarf debugging

2009-06-13 Thread Steve Kargl
Someone has broken gfortran on FreeBSD with dwarf debugging. This is a regression. Please fix! Testing debug/trivial.f, -gdwarf-21 Executing on host: /usr/home/kargl/gcc/obj4x/gcc/testsuite/gfortran/../../gfortr an -B/usr/home/kargl/gcc/obj4x/gcc/testsuite/gfortran/../../ /usr/home/kargl/gcc /gcc

mainline breakage (r148442)

2009-06-13 Thread Oliver Kellogg
Anybody else seeing this? /usr/src/packages/BUILD/build-gcc-orig/./prev-gcc/xgcc -B/usr/src/packages/BUILD/build-gcc-orig/./prev-gcc/ -B/opt/gnat/fsf/i686-pc-linux-gnu/bin/ -B/opt/gnat/fsf/i686-pc-linux-gnu/bin/ -B/opt/gnat/fsf/i686-pc-linux-gnu/lib/ -isystem /opt/gnat/fsf/i686-pc-linux-gnu/includ