[dataflow]: Status for spu-elf
Hi, I ran part of the testsuite on the dataflow branch for spu-elf. I only ran compile.exp as I don't have access to hardware (at home) and I have not figured out how to use the "free" simulator from IBM yet. There is one regression: gcc.c-torture/compile/930513-2.c ICEs in find_reg_note when compiled with -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions. SPU has libcalls for double compares. The backtrace is: #1 0x08499f85 in find_reg_note (insn=0x0, kind=REG_LIBCALL, datum=0x0) at ../../gcc/rtlanal.c:1593 #2 0x082fa876 in emit_copy_of_insn_after (insn=0xb7c4e4b0, after=0xb7c4b210) at ../../gcc/emit-rtl.c:5326 #3 0x0826a3da in duplicate_insn_chain (from=0xb7c433a8, to=0xb7c4b18c) at ../../gcc/cfglayout.c:971 #4 0x0826a4d6 in cfg_layout_duplicate_bb (bb=0xb7c44168) at ../../gcc/cfglayout.c:1038 #5 0x0852535a in duplicate_block (bb=0xb7c44168, e=0x0, after=0xb7c44480) at ../../gcc/cfghooks.c:804 #6 0x0826a914 in copy_bbs (bbs=0xa600cc8, n=2, new_bbs=0xa5e6b58, edges=0xbfd5283c, num_edges=2, new_edges=0xbfd52834, base=0xa60aa30, after=0xb7c44480) at ../../gcc/cfglayout.c:1221 #7 0x0827152d in duplicate_loop_to_header_edge (loop=0xa60aa30, e=0xb7c4e780, loops=0xa5e6358, ndupl=7, wont_exit=0xa5e5038, orig=0x0, to_remove=0x0, n_to_remove=0x0, flags=3) at ../../gcc/cfgloopmanip.c:990 #8 0x08277508 in unroll_loop_stupid (loops=0xa5e6358, loop=0xa60aa30) at ../../gcc/loop-unroll.c:1452 #9 0x08274839 in unroll_and_peel_loops (loops=0xa5e6358, flags=6) at ../../gcc/loop-unroll.c:190 Also there is a progressions in that gcc.c-torture/compile/2804-1.c no longer ICEs at -O3 -funroll-loops. I will run the full testsuite tomorrow when I get to work as I have access to hardware there. Thanks, Andrew Pinski
Re: Bootstrap broken on mipsel-linux...
Steven Bosscher wrote: On 12/11/06, David Daney <[EMAIL PROTECTED]> wrote: From svn r119726 (Sun, 10 Dec 2006) I am getting an ICE during bootstrap on mipsel-linux. This is a new failure since Wed Dec 6 06:34:07 UTC 2006 (revision 119575) which bootstrapped and tested just fine. I don't really want to do a regression hunt as bootstraps take 3 or 4 days for me. I will update and try it again. No need. It's my CSE patch, no doubt: http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00698.html I'll try to figure out what's wrong. /home/build/gcc-build/./prev-gcc/xgcc -B/home/build/gcc-build/./prev-gcc/ -B/usr/local/mipsel-unknown-linux-gnu/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../libdecnumber ../../gcc/gcc/c-decl.c -o c-decl.o ../../gcc/gcc/c-decl.c: In function 'set_type_context': ../../gcc/gcc/c-decl.c:691: internal compiler error: in cse_find_path, at cse.c:5930 Please submit a full bug report, with preprocessed source if appropriate. Sic :-) A test case would be helpful. Lets assume that it doesn't effect i686 or x86_64. Because if it did, someone else would have been hit by it by now. So you would need a mips[el]-linux system in order to reproduce it. But if you had that, you could compile c-decl.c yourself to reproduce it. But if you really want it, I can get you a preprocessed version of c-decl.c. I suppose one could try it on a cross-compiler, but I have no idea if that would fail in the same manner. David Daney
ggdb3 information lost using temporary preprocessed file
Hello,
I already post this message on gcc-help but had no answer.
Does anybody have a suggestion?
--
I recently started to test 'distcc' to speedup some compilations.
Then I noticed the sizes of generated objects were not the same
compiled locally (using gcc only) and remotely (using gcc through
distcc). After some investigations I found the issue was related to
the '-ggdb3' flag and the fact distcc splits the compilation in two
steps.
The issue can be reproduced without distcc; for the following 'main.c'
code the local command used is: 'gcc -ggdb3 -c main.c' and the distcc
one is equivalent to a local: 'gcc -ggdb3 -c main.c -E > main.i; gcc
-ggdb3 -c main.i'.
The resulting sizes are respectively 15400 and 3992 bytes. Using
'-ggdb2' the generated objects are the same. I guess some debugging
information is lost when the compilation is split into two steps but
it could prevent the use of 'distcc' in some cases.
Does anybody know if this is the expected behavior or if it is a bug?
Does a workaround exist?
Thanks in advance and best regards,
sb
PS: we use gcc 3.4.5 on a Linux/Suse Linux Enterprise Server 9 but the
behavior is the same on Solaris 10 (same gcc version).
The main.c code:
#include
int main(int argc, char **argv)
{
printf("Hello\n");
return 0;
}
re: ggdb3 information lost using temporary preprocessed file
You might want to file a bug at http://gcc.gnu.org/bugzilla/ for this.
Re: Bootstrap broken on mipsel-linux...
On 12/11/06, David Daney <[EMAIL PROTECTED]> wrote: Lets assume that it doesn't effect i686 or x86_64. Because if it did, someone else would have been hit by it by now. I'm sure it doesn't, I bootstrapped&tested on those targets (and on ia64). So you would need a mips[el]-linux system in order to reproduce it. But if you had that, you could compile c-decl.c yourself to reproduce it. But if you really want it, I can get you a preprocessed version of c-decl.c. I suppose one could try it on a cross-compiler, but I have no idea if that would fail in the same manner. If you have a test case, I should be able to reproduce it with a cross. Getting a test case with a cross-compiler is the more difficult part. I could try to use a preprocessed c-decl.c from the cross-compiler configuration. But it wouldn't be the same input file as the one from your ICE, so whether that would allow me to reproduce the problem remains to be seen. If you have a preprocessed c-decl.c that ICEs for you, that would be helpful. If not, I'll just have to figure out a way to reproduce the ICE in some different way. Gr. Steven
Re: Bootstrap broken on mipsel-linux...
David Daney <[EMAIL PROTECTED]> wrote:
> From svn r119726 (Sun, 10 Dec 2006) I am getting an ICE during
> bootstrap on mipsel-linux. This is a new failure since Wed Dec 6
> 06:34:07 UTC 2006 (revision 119575) which bootstrapped and tested just
> fine. I don't really want to do a regression hunt as bootstraps take 3
> or 4 days for me. I will update and try it again.
While I've looked at a wrong code problem on sh-elf, I've
noticed that it happens also on mips-elf. It might affect
mipsel-linux.
Now gcc.c-torture/execute/20010422-1.c is compiled like as
foo:
.frame $sp,0,$31 # vars= 0, regs= 0/0, args= 0, gp= 0
.mask 0x,0
.fmask 0x,0
.setnoreorder
.setnomacro
sltu$2,$2,5
beq $2,$0,$L2
nop
...
which looks wrong. The binary search shows that before
r119711 | amacleod | 2006-12-11 06:25:40 +0900 (Mon, 11 Dec 2006) | 103 lines
the assembler output is
foo:
.frame $sp,0,$31 # vars= 0, regs= 0/0, args= 0, gp= 0
.mask 0x,0
.fmask 0x,0
.setnoreorder
.setnomacro
sltu$4,$4,5
beq $4,$0,$L2
nop
...
It seems that the first tree dump which differs before and
after r119711 is .099t.optimized.
[r119710 .099t.optimized]
;; Function foo (foo)
Analyzing Edge Insertions.
foo (x)
{
unsigned int x.24;
:
if (x <= 4) goto ; else goto ;
:;
x.24 = 4;
goto ();
:;
x.24 = 8;
:;
return x.24;
}
[r119711 .099t.optimized]
;; Function foo (foo)
Analyzing Edge Insertions.
foo (x)
{
unsigned int x.24;
:
if (x.24 <= 4) goto ; else goto ;
:;
x = 4;
goto ();
:;
x = 8;
:;
return x;
}
Regards,
kaz
Re: Bootstrap broken on mipsel-linux...
On 12/11/06, Kaz Kojima <[EMAIL PROTECTED]> wrote: It seems that the first tree dump which differs before and after r119711 is .099t.optimized. In that case, this is a different problem, probably caused by the new out-of-SSA pass. But to be sure, I suggest you revert my CSE patch and see if that makes the problem go away for you. Gr. Steven
Re: Bootstrap broken on mipsel-linux...
On Mon, 2006-12-11 at 15:16 +0100, Steven Bosscher wrote: > On 12/11/06, Kaz Kojima <[EMAIL PROTECTED]> wrote: > > It seems that the first tree dump which differs before and > > after r119711 is .099t.optimized. > > In that case, this is a different problem, probably caused by the new > out-of-SSA pass. But to be sure, I suggest you revert my CSE patch > and see if that makes the problem go away for you. The out of ssa pass can generate different code since the costing routine was tweaked slightly. I am not suprised the listing is different, but that alone will not determine if that is where the bug is. Andrew
Re: Serious SPEC CPU 2006 FP performance regressions on IA32 and x86-64
On Fri, Dec 08, 2006 at 01:02:27PM -0600, Menezes, Evandro wrote: > HJ, > > I'll run the three worst offenders below and get back to y'all. > > The full results will take longer. Hi Evandro, I also saw similar issues on x86-64 with -O2 -ffast-math: gcc-4.2 rev 116820 gcc 4.3 rev 119497 410.bwaves 10.910.6-2.75229% 416.gamess 15.015.64% 433.milc 13.012.9-0.769231% 434.zeusmp 13.913.90% 435.gromacs 8.418.40-0.118906% 436.cactusADM10.310.2-0.970874% 437.leslie3d 10.67.55-28.7736% 444.namd 13.613.60% 447.dealII 23.723.80.421941% 450.soplex 15.515.4-0.645161% 453.povray 17.718.75.64972% 454.calculix 6.967.041.14943% 459.GemsFDTD 12.39.87-19.7561% 465.tonto12.612.4-1.5873% 470.lbm 15.916.00.628931% 481.wrf 10.39.97-3.20388% 482.sphinx3 18.518.4-0.540541% Est. SPECfp_base2006 12.912.5-3.10078% Did you see it on AMD? H.J.
Accessing CVS
Hi all, How to download GCC projects from CVS For e.g.i tried this one cvs -d :pserver:[EMAIL PROTECTED]:/cvsroot/gcc checkout -P /branches./fixed-point But it did not work. Regards, Rohit
Re: Accessing CVS
You have to use subversion, not CVS. Everything is explained here: http://gcc.gnu.org/svn.html The command you probably want is: svn -q checkout svn://gcc.gnu.org/svn/gcc/branches/fixed-point/ fixed-point I hope this helps. Cheers, Manuel. On 11/12/06, Rohit Arul Raj <[EMAIL PROTECTED]> wrote: Hi all, How to download GCC projects from CVS For e.g.i tried this one cvs -d :pserver:[EMAIL PROTECTED]:/cvsroot/gcc checkout -P /branches./fixed-point But it did not work. Regards, Rohit
RE: Serious SPEC CPU 2006 FP performance regressions on IA32
HJ, > > Gcc 4.3 revision 119497 has very poor SPEC CPU 2006 FP performance > > regressions on P4, Pentium M and Core Duo, comparing aganst > > gcc 4.2 20060910. With -O2, the typical regressions look like > > > > Gcc 4.2 Gcc 4.3 > > 410.bwaves 9.899.14-7.58342% > > 416.gamess 7.177.16-0.13947% > > 433.milc 7.687.65-0.390625% > > 434.zeusmp 5.575.55-0.359066% > > 435.gromacs 3.994.020.75188% > > 436.cactusADM4.594.50-1.96078% > > 437.leslie3d 5.783.98-31.1419% > > 444.namd 6.256.18-1.12% > > 447.dealII 11.311.30% > > 450.soplex 8.618.59-0.232288% > > 453.povray 6.706.720.298507% > > 454.calculix 2.812.74-2.4911% > > 459.GemsFDTD 6.074.95-18.4514% > > 465.tonto4.444.450.225225% > > 470.lbm 10.610.70.943396% > > 481.wrf 4.564.50-1.31579% > > 482.sphinx3 11.211.1-0.892857% > > Est. SPECfp_base2006 6.426.15-4.20561% > > > > Evandro, what do you get on AMD? > > > > Is that related to recent i386 backend FP changes? Here's what we got: ?% CPU2006 410.bwaves -6% 416.gamess 433.milc 434.zeusmp 435.gromacs 436.cactusADM 437.leslie3d-26% 444.namd 447.dealII 450.soplex 453.povray 454.calculix 459.GemsFDTD-12% 465.tonto 470.lbm 481.wrf 482.sphinx3 Though not as pronounced, definitely significant. -- ___ Evandro Menezes AMDAustin, TX
Re: Serious SPEC CPU 2006 FP performance regressions on IA32
On Mon, Dec 11, 2006 at 11:35:27AM -0600, Menezes, Evandro wrote: > HJ, > > > > Gcc 4.3 revision 119497 has very poor SPEC CPU 2006 FP performance > > > regressions on P4, Pentium M and Core Duo, comparing aganst > > > gcc 4.2 20060910. With -O2, the typical regressions look like > > > > > > Gcc 4.2 Gcc 4.3 > > > 410.bwaves 9.899.14-7.58342% > > > 416.gamess 7.177.16-0.13947% > > > 433.milc 7.687.65-0.390625% > > > 434.zeusmp 5.575.55-0.359066% > > > 435.gromacs 3.994.020.75188% > > > 436.cactusADM4.594.50-1.96078% > > > 437.leslie3d 5.783.98-31.1419% > > > 444.namd 6.256.18-1.12% > > > 447.dealII 11.311.30% > > > 450.soplex 8.618.59-0.232288% > > > 453.povray 6.706.720.298507% > > > 454.calculix 2.812.74-2.4911% > > > 459.GemsFDTD 6.074.95-18.4514% > > > 465.tonto4.444.450.225225% > > > 470.lbm 10.610.70.943396% > > > 481.wrf 4.564.50-1.31579% > > > 482.sphinx3 11.211.1-0.892857% > > > Est. SPECfp_base2006 6.426.15-4.20561% > > > > > > Evandro, what do you get on AMD? > > > > > > Is that related to recent i386 backend FP changes? > > Here's what we got: > > ?% > CPU2006 > 410.bwaves -6% > 416.gamess > 433.milc > 434.zeusmp > 435.gromacs > 436.cactusADM > 437.leslie3d -26% > 444.namd > 447.dealII > 450.soplex > 453.povray > 454.calculix > 459.GemsFDTD -12% > 465.tonto > 470.lbm > 481.wrf > 482.sphinx3 > > Though not as pronounced, definitely significant. > It is close to what we see on both x86 and x86-64. Are you going to track it down? H.J.
Re: failed to compile gcc-4.3-20061209/gcc/varasm.c on OSX 10.3
Andreas Tobler wrote: > Dominique Dhumieres wrote: >>... >>cc1: warnings being treated as errors >>../../gcc-4.3-20061209/gcc/varasm.c: In function 'elf_record_gcc_switches': >>../../gcc-4.3-20061209/gcc/varasm.c:6268: warning: format '%llu' expects type >>'long long unsigned int', but argument 3 has type 'long int' >>../../gcc-4.3-20061209/gcc/varasm.c:6275: warning: format '%llu' expects type >>'long long unsigned int', but argument 3 has type 'long int' >>../../gcc-4.3-20061209/gcc/varasm.c:6283: warning: format '%llu' expects type >>'long long unsigned int', but argument 3 has type 'long int' >>../../gcc-4.3-20061209/gcc/varasm.c:6302: warning: format '%llu' expects type >>'long long unsigned int', but argument 3 has type 'long int' >>make[3]: *** [varasm.o] Error 1 >> >> Any idea around about the cause and/or the way to fix it? > > This is known to break on all 32-bit targets. (afaik) On 64-bit targets > it works. > > You can either wait until the patch is reverted or the correct fix is done. Do you know if there a GCC bug report for this defect? I couldn't find one in bugzilla. I am seeing this problem with IA64 HP-UX on ToT. I tried the workaround you gave and that makes IA64 HP-UX work but causes other platforms to fail so I am wondering when there will be a real fix for this bootstrap problem. Steve Ellcey [EMAIL PROTECTED]
Unwinding CFI gcc practice of assumed `same value' regs
Hello, currently (on x86_64) the gdb backtrace does not properly stop at the outermost frame: #3 0x0036ddb0610a in start_thread () from /lib64/tls/libpthread.so.0 #4 0x0036dd0c68c3 in clone () from /lib64/tls/libc.so.6 #5 0x in ?? () Currently it relies only on clearing %rbp (0x above is unrelated to it, it got read from uninitialized memory). http://sourceware.org/ml/gdb/2004-08/msg00060.html suggests frame pointer 0x0 should be enough for a debugger not finding CFI to stop unwinding, still it is a heuristic. In the -fno-frame-pointer compiled code there is no indication the frame pointer register became a regular one and 0x0 is its valid value. The right unwinding stop indication should be CFI-undefined PC: http://dwarf.freestandards.org/Dwarf3.pdf - page 118 (130/267) - If a Return Address register is defined in the virtual unwind table, and its rule is undefined (for example, by DW_CFA_undefined), then there is no return address and no call address, and the virtual unwind of stack activations is complete. It has been recently patched for glibc clone() (as the outermost frame) http://sourceware.org/ml/libc-alpha/2006-11/msg00082.html but it had to be reverted as the current libgcc_s unwinder is incompatible: http://sourceware.org/ml/libc-alpha/2006-12/msg00078.html Current libgcc_s unwinder does not differentiate between `DW_CFA_undefined' and `DW_CFA_same_value' as both set a register state to its `REG_UNSAVED'. Updating its behavior unfortunately relies on another current ABI incoherency as DWARF specifies all the registers should be `undefined' by default http://dwarf.freestandards.org/Dwarf3.pdf - page 111 (123/267) - The default rule for all columns before interpretation of the initial instructions is the undefined rule. However, an ABI authoring body or a compilation system authoring body may specify an alternate default value for any or all columns. but current gcc produces CFI code assuming the default state of all the registers is `same value'. The strictly DWARF compliant gcc behavior would be to initialize all the callee saved registers to `DW_CFA_same_value' in all the CIE initial instructions blocks. This is currently not done and it would introduce a large increase of `.eh_frame' size, despite the merging of common CIEs. Therefore (Jakub is) proposing for gcc `compilation system authoring' to define the default callee saved registers as `same value' and callee unsaved registers as `undefined'. It would make the current gcc CFI practice stanards compliant and the unwinding stop CFI would became clear and -fomit-frame-pointer reliable. GCC: `unwind-dw2' needs update to differentiate `undefined' and `same value'. AFAIK its code (CFI) generator may remain the same. GLIBC: Reintroduce the patch above utilizing `.cfi_undefined rip'. GDB: The currently disabled (default `set complaints 0') warnings made obsolete: During symbol reading, incomplete CFI data; unspecified registers (e.g., eax) at 0xfc1400. Other unwinders: May need fix to support `DW_CFA_undefined', done for libunwind. Most of the problem analysis by the courtesy of Jakub Jelinek. Not providing any patches so far until the final solution decision is made. Regards, Jan
Re: failed to compile gcc-4.3-20061209/gcc/varasm.c on OSX 10.3
Steve Ellcey <[EMAIL PROTECTED]> writes: > Do you know if there a GCC bug report for this defect? I couldn't find > one in bugzilla. I am seeing this problem with IA64 HP-UX on ToT. Should be fixed now. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: "Fix alias slowdown" patch miscompiles 464.h264ref in SPEC CPU
On 12/11/06, H. J. Lu <[EMAIL PROTECTED]> wrote: On Sun, Dec 10, 2006 at 09:42:35PM -0800, H. J. Lu wrote: > On Mon, Dec 11, 2006 at 12:27:07AM -0500, Daniel Berlin wrote: > > Hey, by chance does the attached fix it? > > > > Yes, it fixes 464.h264ref with the test input. I am running the real > input now. > Do you need a testcase for your fix? We can try to extract one from 464.h264ref. No, i've got a short but valid testcase that will fail without this change. I'll finish the bootstrap and regtested and commit this. Thanks
RE: Serious SPEC CPU 2006 FP performance regressions on IA32
> -Original Message- > From: H. J. Lu [mailto:[EMAIL PROTECTED] > Sent: Monday, December 11, 2006 1:09 PM > To: Menezes, Evandro > Cc: gcc@gcc.gnu.org; [EMAIL PROTECTED]; rajagopal, dwarak; Meissner, > Michael > Subject: Re: Serious SPEC CPU 2006 FP performance regressions on IA32 > > On Mon, Dec 11, 2006 at 11:35:27AM -0600, Menezes, Evandro wrote: > > HJ, > > > > > > Gcc 4.3 revision 119497 has very poor SPEC CPU 2006 FP performance > > > > regressions on P4, Pentium M and Core Duo, comparing aganst > > > > gcc 4.2 20060910. With -O2, the typical regressions look like > > > > > > > > Gcc 4.2 Gcc 4.3 > > > > 410.bwaves 9.899.14-7.58342% > > > > 416.gamess 7.177.16-0.13947% > > > > 433.milc 7.687.65-0.390625% > > > > 434.zeusmp 5.575.55-0.359066% > > > > 435.gromacs 3.994.020.75188% > > > > 436.cactusADM4.594.50-1.96078% > > > > 437.leslie3d 5.783.98-31.1419% > > > > 444.namd 6.256.18-1.12% > > > > 447.dealII 11.311.30% > > > > 450.soplex 8.618.59-0.232288% > > > > 453.povray 6.706.720.298507% > > > > 454.calculix 2.812.74-2.4911% > > > > 459.GemsFDTD 6.074.95-18.4514% > > > > 465.tonto4.444.450.225225% > > > > 470.lbm 10.610.70.943396% > > > > 481.wrf 4.564.50-1.31579% > > > > 482.sphinx3 11.211.1-0.892857% > > > > Est. SPECfp_base2006 6.426.15-4.20561% > > > > > > > > Evandro, what do you get on AMD? > > > > > > > > Is that related to recent i386 backend FP changes? > > > > Here's what we got: > > > > ?% > > CPU2006 > > 410.bwaves -6% > > 416.gamess > > 433.milc > > 434.zeusmp > > 435.gromacs > > 436.cactusADM > > 437.leslie3d-26% > > 444.namd > > 447.dealII > > 450.soplex > > 453.povray > > 454.calculix > > 459.GemsFDTD-12% > > 465.tonto > > 470.lbm > > 481.wrf > > 482.sphinx3 > > > > Though not as pronounced, definitely significant. > > > > It is close to what we see on both x86 and x86-64. Are you going to > track it down? Just in case people are cherry picking the gcc mailing list and not reading all of the threads, this is also discussed in this thread, where 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?
Re: What's the status of autovectorization for MMX and 3DNow!?
Hello! I'm particularly interested in this patch (http://gcc.gnu.org/ml/gcc-patches/2005-07/msg01128.html); pretty nice for users of Pentium 3 and Athlon. Has it been or will it be integrated into mainline? This patch heavily depends on the functionality of optimize mode switching pass. Unfortunatelly, there is currently no way to tell optimize_mode_switching() which modes are exclusive. Due to the way how the emms switching patch was designed, it expects that either MMX or X87 mode can be active at once, to properly switch between x87 and MMX registers. PR target/19161 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19161) comment #17 has an example of the control flow that can block both register sets at once. Otherwise, the patch works as expected. Uros.
Re: Unwinding CFI gcc practice of assumed `same value' regs
GCC's unwinder doesn't distinguish undefined from same_value, because it doesn't matter for EH unwinding purposes. Both mean "nothing to be done for this register". The distinction only matters to informative unwinding purposes like debugging. I'm not sure why libgcc's unwinder really ought to care. It's not that I'm against it knowing the difference; that certainly seems a cleaner way for it to be internally. But as to the idea that it needs to distinguish them for correctness, and thus other things need to rely on having a libgcc_s version that does, and so forth, I don't see the motivation. In the ideal world, things would use cfi_undefined on the pc regno to indicate the base frame, as the dwarf3 spec says to. I certainly think it would be cleanest for everything to do that. But again, in practice on i386 and x86_64, I'm not sure I see the need. Correct unwind info should always restore the caller's bp register value. When that unwinds to the outermost frame, that will be a zero value as the runtime code of base frames sets it. My reading is that the "ABI authoring body" for GNU systems or the "compilation system authoring body" for GNU compilers already specifies that the default rule is same_value for callee-saves registers (as chosen by each particular ABI), even if this has not been formally documented anywhere heretofore. (This is how I've written ABI support in another unwinder implementation I've worked on.) As you've said, this is the only reading by which current CFI is correct and complete for getting the values of callee-saves registers. I presume that GCC's omission of rules for those registers is in fact simply because EH unwinding doesn't care and people on the generation side just didn't think about it beyond that. Regardless of the true reasons for the history, the description above applies to the manifest practice that constitutes what we want the formal specification to mean. Thanks, Roland
Re: Bootstrap broken on mipsel-linux...
"Steven Bosscher" <[EMAIL PROTECTED]> wrote: > In that case, this is a different problem, probably caused by the new > out-of-SSA pass. But to be sure, I suggest you revert my CSE patch > and see if that makes the problem go away for you. I've confirmed that that problem is remained after reverting r119706 changes of cse.c. So it may be another problem, though it might produce a wrong stage 1 compiler for mipsel-linux and end up with the ICE in stage 2. Regards, kaz
Re: Bootstrap broken on mipsel-linux...
On 12/12/06, Kaz Kojima <[EMAIL PROTECTED]> wrote: "Steven Bosscher" <[EMAIL PROTECTED]> wrote: > In that case, this is a different problem, probably caused by the new > out-of-SSA pass. But to be sure, I suggest you revert my CSE patch > and see if that makes the problem go away for you. I've confirmed that that problem is remained after reverting r119706 changes of cse.c. So it may be another problem, though it might produce a wrong stage 1 compiler for mipsel-linux and end up with the ICE in stage 2. In the mipsel-linux case, we ended up with a diamond region where the jump in the IF-block was folded, so that we could extend the path along one of the diamond's arms with the JOIN-block. This could happen because cse_main traversed the basic blocks in DFS order instead of in topological order. I have just posted a hopeful fix for this. Gr. Steven
bogon in a gcc-testresults post (sparc-sun-solaris2.8)
Hi all, The report in http://gcc.gnu.org/ml/gcc-testresults/2006-12/msg00459.html claims to be from the 4_2_branch at Mon Dec 11 08:40:27 UTC 2006 (revision 119731) That's wrong; it's actually from Sun Dec 10 08:39:43 UTC 2006 (revision 119704) but the run took more than 24 hours and the cron job re-synced. And that's without building Java. The test wasn't using -j, and it's only a 400 MHz Sparc. Seems I need to fix that. Running the tests twice (for 32 and 64 bits) seems to take ages. Sorry, especially to sparc/solaris folks, for any confusion.
Re: Bootstrap broken on mipsel-linux...
"Steven Bosscher" <[EMAIL PROTECTED]> wrote: > In the mipsel-linux case, we ended up with a diamond region where the > jump in the IF-block was folded, so that we could extend the path > along one of the diamond's arms with the JOIN-block. This could > happen because cse_main traversed the basic blocks in DFS order > instead of in topological order. I have just posted a hopeful fix for > this. Thanks for the explanation. I'd like to file the problem in http://gcc.gnu.org/ml/gcc/2006-12/msg00284.html as an independent PR. Regards, kaz
Re: bogon in a gcc-testresults post (sparc-sun-solaris2.8)
> The report in > > http://gcc.gnu.org/ml/gcc-testresults/2006-12/msg00459.html > > claims to be from the 4_2_branch at > > Mon Dec 11 08:40:27 UTC 2006 (revision 119731) > > That's wrong; it's actually from > > Sun Dec 10 08:39:43 UTC 2006 (revision 119704) > > but the run took more than 24 hours and the cron job re-synced. And > that's without building Java. Thanks for letting us know. > The test wasn't using -j, and it's only a 400 MHz Sparc. Seems I need > to fix that. Running the tests twice (for 32 and 64 bits) seems to take > ages. Right, this seems to be noticeably slower with 4.2, especially libstdc++. -- Eric Botcazou
Re: [PATCH] Relocated compiler should not look in $prefix.
On Fri, 2006-10-13 at 12:51 -0400, Carlos O'Donell wrote: > A relocated compiler should not look in $prefix. > Comments? > OK for Stage1? I do have another issue with these set of patches which I did not notice until today. I can no longer do inside a just built GCC do: ./cc1 t.c or ./xgcc -B. t.c If I used the same prefix of an already installed GCC. This makes debugging driver issues without installing the driver again. Thanks, Andrew Pinski
