On Mon, Mar 12, 2007 at 05:27:21PM +0100, Richard Guenther wrote:
> Most of the problems are fixed, dealII remains with:
>
> /gcc/spec/sb-balakirew-head-64-2006/x86_64/install-hack/bin/g++ -c -o
> quadrature.o -DSPEC_CPU -DNDEBUG -Iinclude -DBOOST_DISABLE_THREADS
> -Ddeal_II_dimension=3 -O2 -D
On 3/3/07, Grigory Zagorodnev <[EMAIL PROTECTED]> wrote:
Hi,
Trunk GCC shows massive (2 compile-time and 6 run-time) failures on SPEC
CPU2000 and CPU2006 at i386 and x86_64 on -O2 optimization level.
Regression introduced somewhere between revision 122487 and 122478.
There are three checkins, ca
Ian Lance Taylor wrote on 03/06/07 09:49:
> "Vladimir Sysoev" <[EMAIL PROTECTED]> writes:
>
>> Bug has been already reported
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31037
>
> I don't think this one could have anything to do with my VRP changes,
> but I'll try to take a look later today.
>
"Vladimir Sysoev" <[EMAIL PROTECTED]> writes:
> Bug has been already reported
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31037
I don't think this one could have anything to do with my VRP changes,
but I'll try to take a look later today.
Ian
FYI
Bug has been already reported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31037
-Vladimir
Ian Lance Taylor wrote:
"Vladimir Sysoev" <[EMAIL PROTECTED]> writes:
There is minimal reproducer for cpu2006/h264ref is attached
I just committed a patch for PR 31034 which may fix this.
Ian
Hi Ian,
patch for PR31034 fixes cpu2006/464.h264ref ICE only. Others are still
failing - the root cau
"Vladimir Sysoev" <[EMAIL PROTECTED]> writes:
> There is minimal reproducer for cpu2006/h264ref is attached
> use
> gcc -O2 -c ./image.c
>
> Compiler from trunk produces:
> image.c: In function 'UnifiedOneForthPix':
> image.c:35: internal compiler error: in set_value_range, at tree-vrp.c:267
I j
Hi, All
Sorry for my previous post. It was into wrong place.
There is minimal reproducer for cpu2006/h264ref is attached
use
gcc -O2 -c ./image.c
Compiler from trunk produces:
image.c: In function 'UnifiedOneForthPix':
image.c:35: internal compiler error: in set_value_range, at tree-vrp.c:267
Hi, All
Try minimal reproducer for internal compiler error attached.
See go file for command line and report.log for issue reported by
trunk compiler/
-Vladimir
On 3/5/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> I observe a massive compilation time regression for bootstrap on x86-64
> here,
> I observe a massive compilation time regression for bootstrap on x86-64
> here, in particular libjava now appears to take *ages* to build:
I cannot reproduce today at the same revision:
real275m23.314s
user242m28.724s
sys 12m18.249s
Something went awry with kpowersave yesterday...
Andrew Pinski wrote:
For one, the 176.gcc in SPEC 2k has an aliasing violation in it so
that failing is known. You might want to try adding
-fno-strict-aliasing.
In this case we would need to add -fno-strict-aliasing to CFLAGS for the
whole 'int' test set, since we follow 'baseline' rules. That
Grigory Zagorodnev wrote:
Trunk GCC shows massive (2 compile-time and 6 run-time) failures on SPEC
CPU2000 and CPU2006 at i386 and x86_64 on -O2 optimization level.
Regression introduced somewhere between revision 122487 and 122478.
http://gcc.gnu.org/viewcvs?view=rev&revision=122487
Almo
> Trunk GCC shows massive (2 compile-time and 6 run-time) failures on SPEC
> CPU2000 and CPU2006 at i386 and x86_64 on -O2 optimization level.
> Regression introduced somewhere between revision 122487 and 122478.
I observe a massive compilation time regression for bootstrap on x86-64 here,
in par
On Sat, Mar 03, 2007 at 02:00:30PM -0800, Andrew Pinski wrote:
> On 3/3/07, H. J. Lu <[EMAIL PROTECTED]> wrote:
> >> [1] 176.gcc and 253.perlbmk usually miscompare for me. Not sure why.
>
> >176.gcc=default=default=default:
> >CPORTABILITY = -Dalloca=_alloca
> >EXTRA_LDFLAGS =
> >srcalt=64bitgcc
On 3/3/07, H. J. Lu <[EMAIL PROTECTED]> wrote:
> [1] 176.gcc and 253.perlbmk usually miscompare for me. Not sure why.
176.gcc=default=default=default:
CPORTABILITY = -Dalloca=_alloca
EXTRA_LDFLAGS =
srcalt=64bitgcc40
For one, the 176.gcc in SPEC 2k has an aliasing violation in it so
that f
On Sat, Mar 03, 2007 at 11:01:40AM -0500, Diego Novillo wrote:
> Grigory Zagorodnev wrote on 03/03/07 02:27:
>
> > There are three checkins, candidates for the root of regression:
> > http://gcc.gnu.org/viewcvs?view=rev&revision=122487
> > http://gcc.gnu.org/viewcvs?view=rev&revision=12248
On 03 Mar 2007 11:00:11 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
Grigory Zagorodnev <[EMAIL PROTECTED]> writes:
> Trunk GCC shows massive (2 compile-time and 6 run-time) failures on
> SPEC CPU2000 and CPU2006 at i386 and x86_64 on -O2 optimization
> level. Regression introduced somewhe
Grigory Zagorodnev <[EMAIL PROTECTED]> writes:
> Trunk GCC shows massive (2 compile-time and 6 run-time) failures on
> SPEC CPU2000 and CPU2006 at i386 and x86_64 on -O2 optimization
> level. Regression introduced somewhere between revision 122487 and
> 122478.
>
> There are three checkins, candi
> Grigory Zagorodnev wrote on 03/03/07 02:27:
>
> > There are three checkins, candidates for the root of regression:
> > http://gcc.gnu.org/viewcvs?view=rev&revision=122487
> > http://gcc.gnu.org/viewcvs?view=rev&revision=122484
> > http://gcc.gnu.org/viewcvs?view=rev&revision=122479
>
Grigory Zagorodnev wrote on 03/03/07 02:27:
> There are three checkins, candidates for the root of regression:
> http://gcc.gnu.org/viewcvs?view=rev&revision=122487
> http://gcc.gnu.org/viewcvs?view=rev&revision=122484
> http://gcc.gnu.org/viewcvs?view=rev&revision=122479
>
SPEC
20 matches
Mail list logo
