Re: Massive SPEC failures on trunk

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

Re: Massive SPEC failures on trunk

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

Re: Massive SPEC failures on trunk

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=12

Massive SPEC failures on trunk

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, candidates for the root of regression: http://gcc

Re: 40% performance regression SPEC2006/leslie3d on gcc-4_2-branch

Mark Mitchell wrote: Excellent question; I should have asked for that as well. If 4.2 has gained on 4.1 in other respects, the 4.7% drop might represent a smaller regression relative to 4.1. There is the 4.2 (r120817) vs. 4.1.2 release FP performance comparison numbers. SPECfp_base2006 of gcc

Re: 40% performance regression SPEC2006/leslie3d on gcc-4_2-branch

Mark Mitchell wrote: FP performance regressions of the recent GCC 4.2 (revision 120817) compiler against September GCC 4.2 (revision 116799) What does that translate to in terms of overall score? Hi, This is 4.7% drop of SPECfp_base2006 ratio (geomean of individual FP ratios). Here is the f

Re: GCC 4.3 ia64 bootstrap failure

Lee Millward wrote: I think this is down to the CALL_EXPR changes. Can you try changing and see if that fixes it? I'm not able to test this change myself at the moment but I think the above should do it. Just noticed I got the line number wrong in my message above. It should be 9194 as reported

Re: GCC 4.3 ia64 bootstrap failure

Grigory Zagorodnev wrote: Hi! /gcc-43/src/libgcc/../gcc/unwind.inc:287: internal compiler error: tree check: expected class 'expression', have 'constant' (integer_cst) in ia64_expand_builtin, at config/ia64/ia64.c:9194 xgcc(cc1) fails at expand of __builtin_ia64_b

GCC 4.3 ia64 bootstrap failure

Hi! There is a bootstrap failure of 4.3 compiler at ia64. Source revision is 122087, last revision known to be good is 121993. I'm working on a reproducer and revision search. /gcc-43/bld/./gcc/xgcc -B/gcc-43/bld/./gcc/ -B/gcc-43/usr/ia64-r edhat-linux/bin/ -B/gcc-43/usr/ia64-redhat-linux/lib/

Re: build failure? (libgfortran)

Dorit Nuzman wrote: I'm seeing this bootstrap failure on i686-pc-linux-gnu (revision 121579) - something I'm doing wrong, or is anyone else seeing this? Yes. I see the same at x86_64-redhat-linux. - Grigory

Trunk GCC fails to compile cpu2k6/dealII at -O2

Hi! GCC 4.3 compiler revision 121206 gets ICE while compiling cpu2006/447.dealII source file data_out_base.cc at -O2 optimization level on x86_64-redhat-linux. Similar to previously reported cpu2k6/perlbench failure, this regression is caused by "Rewrite of portions of points-to solver" patch

Re: Trunk GCC hangs while compiling cpu2k6/perlbench at -O2

Grigory Zagorodnev wrote: GCC 4.3 compiler revision 121206 goes into infinitive loop while compiling cpu2k6/perlbench source file regcomp.c at -O2 optimization level on x86_64-redhat-linux. This regression is caused by "Rewrite of portions of points-to solver" patch http://gcc.gnu.

Trunk GCC hangs while compiling cpu2k6/perlbench at -O2

GCC 4.3 compiler revision 121206 goes into infinitive loop while compiling cpu2k6/perlbench source file regcomp.c at -O2 optimization level on x86_64-redhat-linux. GDB attached to cc1 process, gives the hang point: 0x00711bd8 in solve_graph (graph=0xd37150) at /home/testbot/bootstra

Re: 27% regression of gcc 4.3 performance on cpu2k6/calculix

H. J. Lu wrote: Is that possible to extract a smaller testcase? I'm working on the small reproducer. That would take some time because of benchmark complexity. - Grigory

Re: 27% regression of gcc 4.3 performance on cpu2k6/calculix

Toon Moene wrote: Calculix is a combined C/Fortran program. Did you try to compile the Fortran parts with --param max-aliased-vops=default 50> ? Right, calculix is a combined program. Gprof says the regression is in e_c3d routine which is 1k lines of Fortran code. Various max-aliased-vops giv

Re: GCC trunk failed to compile cpu2k6/dealII at x86_64

Grigory Zagorodnev wrote: GCC 4.3 revision 120799 fails to compile SPEC cpu2006/447.dealII benchmark at x86_64-redhat-linux on -O2 optimization level. Last revision know to be good is 120775. It appears that revision 120767 causes the failure http://gcc.gnu.org/viewcvs?view=rev&revi

GCC trunk failed to compile cpu2k6/dealII at x86_64

Hi! GCC 4.3 revision 120799 fails to compile SPEC cpu2006/447.dealII benchmark at x86_64-redhat-linux on -O2 optimization level. Last revision know to be good is 120775. data_out_base.cc: In static member function 'static void DataOutBase::write_vtk(const std::vectordim>, std::allocator > >&,

27% regression of gcc 4.3 performance on cpu2k6/calculix

Hi! There is a huge regression of gcc 4.3 performance detected on cpu2006/454.calculix benchmark at -O2 optimization level on x86_64-redhat-linux. Regression is caused by mem-ssa merge 12/12/2006 (revision 119760). http://gcc.gnu.org/viewcvs?view=rev&revision=119760 PS: I'm trying to get a sm

GCC trunk revision 120704 failed to build spec cpu2k/gcc

Hi! GCC trunk revision 120704 failed to build SPEC cpu2000/gcc on -O1 and higher optimization level at x86_64-redhat-linux. reload1.c: In function 'reload': reload1.c:449: error: address taken, but ADDRESSABLE bit not set bad_spill_regs reload1.c:449: error: address taken, but ADDRESSABLE bit

Re: Serious SPEC CPU 2006 FP performance regressions on IA32

Menezes, Evandro wrote: Though not as pronounced, definitely significant. Using binary search I've detected that 30% performance regression of cpu2006/437.leslie3d benchmark is caused by revision 117891. http://gcc.gnu.org/viewcvs?view=rev&revision=117891 I assume same commit causes regres

Re: Serious SPEC CPU 2006 FP performance regressions on IA32

Meissner, Michael wrote: 437.leslie3d-26% it was felt that the PPRE patches that were added on November 13th were the cause of the slowdown: http://gcc.gnu.org/ml/gcc/2006-12/msg00023.html Has anybody tried doing a run with just ppre disabled? Right. PPRE appears to be the reason of slow

Bootstrap of GCC trunk (rev. 116941) failed at i386-redhat-linux

Hi! Trunk failed to bootstrap with revision 116941. Does anybody see the same? /home/bootstrap/src/libjava/posix-threads.cc: In function 'int _Jv_CondWait(_Jv_ConditionVariable_t*, _Jv_Mutex_t*, jlong, jint)': /home/bootstrap/src/libjava/posix-threads.cc:106: error: 'gettimeofday' was not decla

GCC trunk build failed on ia64: ICE in __gcov_init

Hi! Build of mainline GCC on ia64-redhat-linux failed since Thu Jun 8 16:23:09 UTC 2006 (revision 114488). Last successfully built revision is 114468. I wonder if somebody sees the same. make[4]: Entering directory `/home/user/gcc-42/bld/gcc' /home/user/gcc-42/bld/./gcc/xgcc -B/home/user/gcc

Re: fatal error: internal consistency failure on Linux/ia64

Jan-Benedict Glaw wrote: On Mon, 2006-05-22 21:42:07 -0700, Andrew Pinski <[EMAIL PROTECTED]> wrote: On May 22, 2006, at 9:36 PM, H. J. Lu wrote: on Linux/ia64. The last working revision is 113936. Linux/x86 and Linux/x86-64 pass the same spot. Has anyone else seen it? Yes for hppa-linux-gnu,

Re: GCC 4.1.0 RC1

Mark Mitchell wrote: GCC 4.1.0 RC1 is here: ftp://gcc.gnu.org/pub/gcc/prerelease-4.1.0-20060219 Please download, build, and test. Please use these tarballs, rather than the current SVN branch, so that we test packaging, and other similar issues. If you find problems, please do not send me ema

Re: RFC: Message-ID to mailing list URL match

Olly Betts wrote: On 2006-02-17, Marcel Cox <[EMAIL PROTECTED]> wrote: You could create a news URL pointing to Gmane and using the messageid. http://mid.gmane.org/[EMAIL PROTECTED] Definitely, this is the feature that I'd appreciate much at gcc.gnu.org - having http://gcc.gnu.org/[EMAIL PROT

RFC: Message-ID to mailing list URL match

Hi! This is gcc.gnu.org question not gcc itself, but I found this list as most appropriate to ask. It seems to be a good practice, when composing a message, to refer other ones using URL like http://gcc.gnu.org/ml/gcc/2006-02/msg00295.html. Thus I wonder if there is a shorter way to match e-m

Re: Massive FORTRAN test failures

H. J. Lu wrote: I have got massive FORFRAN test failures on Linux/ia64 and Linux/x86-64: It looks like the patch for fortran/25045 http://gcc.gnu.org/ml/fortran/2006-02/msg00111.html has affected stability of 178.galgel, 187.facerec and 189.lucas benchmarks of cpu2000 suite and caused these

GCC 4.1 ICE during CPU2000/177.mesa build

GCC 4.1 is getting ICE in ' refers_to_regno_for_reload_p' while compiling CPU2000/177.mesa on ia32 Linux. Is that a known issue? This is what I got: triangle.c: In function 'simple_z_textured_triangle': triangle.c:461: internal compiler error: in refers_to_regno_for_reload_p, at reload.c: 628