Re: SVN tags, branches and checkouts
John David Anglin <[EMAIL PROTECTED]> wrote: > I find the documentation on checking out branches, particularly > for branch releases, confusing. It doesn't say you need to use "tags" > instead of "branches" for releases. Which documentation, exactly? Giovanni Bajo
Re: g++.dg/ext/packed3.C
Jan Beulich wrote:
I don't think this is the case. The questionable code (from the test
case) really is
struct Unpacked { int i; };
struct __attribute__ ((packed)) Packed
{
char c;
int i;
Unpacked u;
};
and the test expects that you cannot bind Packed::u to Unpacked& (error
expected), but that you can bind Packed::u::i to int& (not even a
warning expected). No warning is expected on the definition of Packed's
u member.
ok. I think you're right. I think I've remembered why it is the way it is, and
that's because rejecting such a binding broke overload resolution of (the
trivial) Unpacked::operator=. I think that no longer applies.
nathan
--
Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Testing/debugging single Ada tests
Can someone of the Ada folks provide some info how I can get a debugging session with a failing acats test? Looking at the testsuite log file I f.i. see c32001e failing and an (appearant) build line(s) BUILD c32001e.adb gnatmake --GCC="/space/rguenther/obj/obj3/gcc/xgcc -B/space/rguenther/obj/obj3/gcc/" -gnatws -O2 -I/space/rguenther/obj/obj3/gcc/testsuite/ada/acats/support c32001e.adb -largs --GCC="/space/rguenther/obj/obj3/gcc/xgcc -B/space/rguenther/obj/obj3/gcc/" /space/rguenther/obj/obj3/gcc/xgcc -c -B/space/rguenther/obj/obj3/gcc/ -gnatws -O2 -I/space/rguenther/obj/obj3/gcc/testsuite/ada/acats/support c32001e.adb but neither of them is invokable from no existing directory (even if you supply the correct path to the c32001e.adb file). Like f.i. within the testsuite/ada directory ../../gnatmake --GCC="/space/rguenther/obj/obj3/gcc/xgcc -B/space/rguenther/obj/obj3/gcc/" -gnatws -O2 -I/space/rguenther/obj/obj3/gcc/testsuite/ada/acats/support acats/tests/c3/c32001e/c32001e.adb -largs --GCC="/space/rguenther/obj/obj3/gcc/xgcc -B/space/rguenther/obj/obj3/gcc/" fatal error, run-time library not installed correctly cannot locate file system.ads gnatmake: *** make failed. /space/rguenther/obj/obj3/gcc/xgcc -c -B/space/rguenther/obj/obj3/gcc/ -gnatws -O2 -I/space/rguenther/obj/obj3/gcc/testsuite/ada/acats/support acats/tests/c3/c32001e/c32001e.adb fatal error, run-time library not installed correctly cannot locate file system.ads compilation abandoned I see there's magic going on in the testsuite/ada/acats/run_acats and run_all.sh scripts, but they cannot be invoked directly to set up the environment. So - help please! Back to /ignore ada mode. Richard.
Re: Testing/debugging single Ada tests
> I see there's magic going on in the testsuite/ada/acats/run_acats and > run_all.sh scripts, but they cannot be invoked directly to set up the > environment. The magic is only there to support testing in the build tree, with the compiler not installed. Assuming you've done a make install, then compiling an ACATS test is as simple as: gnatmake -O2 -I/space/rguenther/obj/obj3/gcc/testsuite/ada/acats/support file.adb is the file generated in the obj directory. If you start from the src directory, then you need one extra step: gnatchop > So - help please! You're welcome. Arno
Re: Testing/debugging single Ada tests
On Tue, 13 Dec 2005, Arnaud Charlet wrote: > > I see there's magic going on in the testsuite/ada/acats/run_acats and > > run_all.sh scripts, but they cannot be invoked directly to set up the > > environment. > > The magic is only there to support testing in the build tree, > with the compiler not installed. This is exactly what I'm trying to do, as I'm testing with the stage1 compiler that happens to miscompile the stage2 compiler, so I guessed it might be easier to debug the testsuite fallout of the stage1 compiler. I'm used to do ./xgcc -B/whatever in the gcc/ directory, maybe gnatmake can be taught to do the required setup following this way, too? Or a split-out script with just the required environment setup I can source in contrib/ or testsuite/ada? That would be of great help. Thanks for the quick response, Richard. > Assuming you've done a make install, then compiling an ACATS > test is as simple as: > > gnatmake -O2 -I/space/rguenther/obj/obj3/gcc/testsuite/ada/acats/support > ok, I'll try to install the stage1 compiler. > file.adb is the file generated in the obj directory. > > If you start from the src directory, then you need one extra step: > > gnatchop > > > So - help please! > > You're welcome. > > Arno > >
mainline bootstrap broken on i686-pc-linux-gnu
Hi, current mainline configured with the following command $SRCDIR/configure --quiet --prefix=$DESTDIR --enable-languages=c++,fortran --with-gmp=/afs/mpa/data/martin/mygmp aborts during bootstrap at this place: /scratch/ogcc/./gcc/xgcc -B/scratch/ogcc/./gcc/ -B/afs/mpa/data/martin/ugcc/i686-pc-linux-gnu/bin/ -B/afs/mpa/data/martin/ugcc/i686-pc-linux-gnu/lib/ -isystem /afs/mpa/data/martin/ugcc/i686-pc-linux-gnu/include -isystem /afs/mpa/data/martin/ugcc/i686-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I/scratch/gcc/libmudflap -I. -Wall -ffunction-sections -fdata-sections -O2 -g -O2 -MT mf-runtime.lo -MD -MP -MF .deps/mf-runtime.Tpo -c /scratch/gcc/libmudflap/mf-runtime.c -fPIC -DPIC -o .libs/mf-runtime.o /scratch/gcc/libmudflap/mf-runtime.c: In function '__mf_usage': /scratch/gcc/libmudflap/mf-runtime.c:478: warning: value computed is not used /scratch/gcc/libmudflap/mf-runtime.c: In function '__mfu_check': /scratch/gcc/libmudflap/mf-runtime.c:1032: error: unrecognizable insn: (insn 1385 1384 1386 31 /scratch/gcc/libmudflap/mf-runtime.c:1457 (set (mem:HI (pre_dec:SI (reg/f:SI 7 sp)) [0 S2 A8]) (reg:HI 0 ax [orig:182 __mf_lc_shift ] [182])) -1 (nil) (nil)) /scratch/gcc/libmudflap/mf-runtime.c:1032: internal compiler error: in extract_insn, at recog.c:2084 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[5]: *** [mf-runtime.lo] Error 1 make[5]: Leaving directory `/scratch/ogcc/i686-pc-linux-gnu/libmudflap' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/scratch/ogcc/i686-pc-linux-gnu/libmudflap' make[3]: *** [all] Error 2 make[3]: Leaving directory `/scratch/ogcc/i686-pc-linux-gnu/libmudflap' make[2]: *** [all-target-libmudflap] Error 2 make[2]: Leaving directory `/scratch/ogcc' make[1]: *** [all] Error 2 make[1]: Leaving directory `/scratch/ogcc' make: *** [bootstrap] Error 2 Cheers, Martin
Re: Testing/debugging single Ada tests
> This is exactly what I'm trying to do, as I'm testing with the > stage1 compiler that happens to miscompile the stage2 compiler, > so I guessed it might be easier to debug the testsuite fallout > of the stage1 compiler. > > I'm used to do ./xgcc -B/whatever in the gcc/ directory, maybe > gnatmake can be taught to do the required setup following this > way, too? Well, that's basically what gnatmake does in the script... Except that unlike C, Ada needs a run-time, even for simple things, so you need in addition to point (using e.g. -I) to the runtime, which is built under obj/gcc/ada/rts, so from obj/gcc directory, you can do e.g: ./xgcc -Bstage1/ -c -Iada/rts -Itestsuite/ada/acats/support Not that difficult after all... And if the Ada run-time hasn't been built yet (partial build), then you can do: ./xgcc -Bstage1/ -c -Iada -Itestsuite/ada/acats/support although this is not recommended, as you will not end up using the same run-time file, which might have an impact on the generated code. Arno
Re: Testing/debugging single Ada tests
On Tue, 13 Dec 2005, Arnaud Charlet wrote: > > This is exactly what I'm trying to do, as I'm testing with the > > stage1 compiler that happens to miscompile the stage2 compiler, > > so I guessed it might be easier to debug the testsuite fallout > > of the stage1 compiler. > > > > I'm used to do ./xgcc -B/whatever in the gcc/ directory, maybe > > gnatmake can be taught to do the required setup following this > > way, too? > > Well, that's basically what gnatmake does in the script... > Except that unlike C, Ada needs a run-time, even for simple things, > so you need in addition to point (using e.g. -I) to the runtime, > which is built under obj/gcc/ada/rts, > > so from obj/gcc directory, you can do e.g: > > ./xgcc -Bstage1/ -c -Iada/rts -Itestsuite/ada/acats/support > > Not that difficult after all... Ah! This works very many thanks! So maybe we can print this additional -I and full path to the source in the acats.log file? I.e. instead of /space/rguenther/obj/obj3/gcc/xgcc -c -B/space/rguenther/obj/obj3/gcc/ -gnatws -O2 -I/space/rguenther/obj/obj3/gcc/testsuite/ada/acats/support c32001e.adb print /space/rguenther/obj/obj3/gcc/xgcc -c -B/space/rguenther/obj/obj3/gcc/ -gnatws -O2 -I/space/rguenther/obj/obj3/gcc/testsuite/ada/acats/support /space/rguenther/obj/obj3/gcc/testsuite/ada/acats/tests/c3/c32001e/c32001e.adb -I/space/rguenther/obj/obj3/gcc/ada/rts ? This way it would work out-of-the box with cut&paste and avoid some confusion. Thanks again, Richard.
Re: Testing/debugging single Ada tests
> /space/rguenther/obj/obj3/gcc/xgcc -c -B/space/rguenther/obj/obj3/gcc/ > -gnatws -O2 -I/space/rguenther/obj/obj3/gcc/testsuite/ada/acats/support > /space/rguenther/obj/obj3/gcc/testsuite/ada/acats/tests/c3/c32001e/c32001e.adb > > -I/space/rguenther/obj/obj3/gcc/ada/rts > > ? This way it would work out-of-the box with cut&paste and avoid some > confusion. If that can clear some confusion, sure. In case you're curious, the script uses another search path mechanism (the ADA_INCLUDE_PATH and ADA_OBJECTS_PATH environment variables), which is why there is no -I appearing on the gnatmake command line. Changing the acats script to use -I instead of ADA_*_PATH is certainly possible. Arno
Re: Testing/debugging single Ada tests
Can someone of the Ada folks provide some info how I can get a debugging session with a failing acats test? Looking at the testsuite log file I f.i. see c32001e failing and an (appearant) build line(s) BUILD c32001e.adb but neither of them is invokable from no existing directory (even if you supply the correct path to the c32001e.adb file). Like f.i. within the testsuite/ada directory It is indeed tricky. What I usually do is copy the acats test in question into a new directory (so I can cut it down or modify it as part of the debugging) and then put the following in /tmp/sh (modified appropriately for acats test name and GCC build directory) and then do "source /tmp/sh". /gcc/gcc/i386-64-h/gcc/gnatmake --GCC="/gcc/gcc/i386-64-h/gcc/xgcc -B/gcc/gcc/i386-64-h/gcc/ -I/gcc/gcc/i386-64-h/gcc/ada/rts" -gnatws -O2 -I/gcc/gcc/i386-64-h/gcc/testsuite/ada/acats/support -I/gcc/gcc/i386-64-h/gcc/ada/rts c380004.adb -largs --GCC="/gcc/gcc/i386-64-h/gcc/xgcc -B/gcc/gcc/i386-64-h/gcc/ -I/gcc/gcc/i386-64-h/gcc/ada/rts" /gcc/gcc/i386-64-h/gcc/gnatbind -aO./ -I/gcc/gcc/i386-64-h/gcc/testsuite/ada/acats/support -I/gcc/gcc/i386-64-h/gcc/ada/rts -x c380004.ali /gcc/gcc/i386-64-h/gcc/gnatlink c380004.ali -I/gcc/gcc/i386-64-h/gcc/ada/rts --GCC="/gcc/gcc/i386-64-h/gcc/xgcc -B/gcc/gcc/i386-64-h/gcc/ -I/gcc/gcc/i386-64-h/gcc/ada/rts"
Re: Testing/debugging single Ada tests
The magic is only there to support testing in the build tree, with the compiler not installed. Assuming you've done a make install, then compiling an ACATS test is as simple as: Yeah, but the problem is that most of us don't want to do a "make install" of a compiler that we know doesn't work (if it did, we wouldn't be debugging an ACATS failure!), so that magic is needed.
Re: Testing/debugging single Ada tests
Richard Guenther wrote: > On Tue, 13 Dec 2005, Arnaud Charlet wrote: > > Except that unlike C, Ada needs a run-time, even for simple things, > > so you need in addition to point (using e.g. -I) to the runtime, > > which is built under obj/gcc/ada/rts, > > > > so from obj/gcc directory, you can do e.g: > > > > ./xgcc -Bstage1/ -c -Iada/rts -Itestsuite/ada/acats/support > > > > Not that difficult after all... > > Ah! This works very many thanks! So maybe we can print this There is also a note in: http://gcc.gnu.org/wiki/DebuggingGCC Debugging the ada compiler If you run the debugger on ../../objdir/gnat1, you get an error message: fatal error, run-time library not installed correctly cannot locate file system.ads compilation abandoned For correcting this error, simply invoke the following command at the gdb prompt: (gdb) set env ADA_INCLUDE_PATH path_to_objdir/gcc/ada/rts
Re: SVN tags, branches and checkouts
> John David Anglin <[EMAIL PROTECTED]> wrote: > > > I find the documentation on checking out branches, particularly > > for branch releases, confusing. It doesn't say you need to use "tags" > > instead of "branches" for releases. > > Which documentation, exactly? http://gcc.gnu.org/svn.html It would help if there was an example in how to check out a release. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Ada and TYPE_SIZE of ARRAY_TYPEs
Ada seems to set TYPE_SIZE of an ARRAY_TYPE to integer_zero_node, which does not follow (tree.def): /* Each node that represents a data type has a component TYPE_SIZE containing a tree that is an expression for the size in bits. also it makes querying the element size difficult if you have an array of an array. From c43207b.adb we f.i. get (gdb) call debug_tree(type) sizes-gimplified public SI size unit size user align 32 symtab 0 alias set 19 precision 32 min max RM size pointer_to_this > sizes-gimplified nonaliased-component type_1 BLK size unit size user align 32 symtab 0 alias set 6 domain sizes-gimplified SI size unit size align 32 symtab 0 alias set -1 precision 32 min max index type > pointer_to_this > sizes-gimplified nonaliased-component BLK size unit size user align 32 symtab 0 alias set 7 domain unit size align 32 symtab 0 alias set -1 precision 32 min max > sizes-gimplified SI size unit size align 32 symtab 0 alias set -1 precision 32 min max index type sizes-gimplified SI size unit size user align 32 symtab 0 alias set -1 precision 32 min max RM size >> pointer_to_this > which could have TYPE_SIZE of both subtypes set correctly. (Why does ada chose integer_zero_node here and not NULL_TREE, btw.?) Any idea on how to fix ada? Or does it not need fixing and I am just confused about the validity of TYPE_SIZE here? Thanks, Richard.
Re: GCC CompileFarm Project
Hi, I was thinking about collecting the patches to be tested dirrectly in the gcc-patches mailing list, like the patch queue tracks new patches. This could also be convenient for having some control by peer review on the patches proposed for testing. If the machines that run the bootstrap and test act as volunteers, it is possible to provide the client scripts to other gcc developers that can decide to help test the patches with their spare machines. Once the patch is bootstrapped and tested, the results are sent back to gcc-patches. Sebastian
Re: RELOAD_OTHER bug?
Note that 4157 is out of order. I *think* what's happening is that the MERGE_TO_OTHER macro isn't taking into account that if you merge RELOAD_OTHER and RELOAD_FOR_OTHER_ADDRESS, you can't end up with a RELOAD_OTHER. No, anything merged with RELOAD_OTHER has to be RELOAD_OTHER.
Re: Installing libgcj consumes huge amounts of memory
> "Gerald" == Gerald Pfeifer <[EMAIL PROTECTED]> writes: Gerald> Is anyone seeing this? With current 4.1 sources, on a machine Gerald> with "only" 1GB of main memory + 1GB swap, the following part Gerald> of `make install` [...] Gerald> spawns a recursive make (GNU make 3.80) that consumes some Gerald> 450MB of memory and triggers a system load of 12+, basically Gerald> rendering the machine dead for about a minute. Gerald> Any ideas how I could nail this down? Anyone else seeing this? First, yeah, this is known. And, kudos to HJ for trying to fix this in 'make'. I've been considering working around this problem by just redoing the whole .java->.class step whenever any .java file changes. That would probably be slower for libgcj developers but at least wouldn't hugely hurt folks working elsewhere. Also, most class library development happens in Classpath these days anyway. Any comments on this? Tom
Re: Installing libgcj consumes huge amounts of memory
On Tue, 2005-12-13 at 11:41 -0700, Tom Tromey wrote: > First, yeah, this is known. And, kudos to HJ for trying to fix this > in 'make'. If nothing else, HJ's hack is keeping things from being too insane while y'all sort out the best fix. > I've been considering working around this problem by just redoing the > whole .java->.class step whenever any .java file changes. That would > probably be slower for libgcj developers but at least wouldn't hugely > hurt folks working elsewhere. Also, most class library development > happens in Classpath these days anyway. > > Any comments on this? No strong opinions on how you fix it, so long as it gets fixed :-) Waiting on this is a major time sink right now. In fact, this may be one of those cases where it's advisable to fix make *and* fix the Java runtime build stuff. jef
Re: RELOAD_OTHER bug?
> No, anything merged with RELOAD_OTHER has to be RELOAD_OTHER. Why? Does this mean that RELOAD_FOR_OTHER_ADDRESS reloads can never be merged with RELOAD_OTHER reloads?
Re: Installing libgcj consumes huge amounts of memory
Tom Tromey wrote: "Gerald" == Gerald Pfeifer <[EMAIL PROTECTED]> writes: Gerald> Is anyone seeing this? With current 4.1 sources, on a machine Gerald> with "only" 1GB of main memory + 1GB swap, the following part Gerald> of `make install` [...] Gerald> spawns a recursive make (GNU make 3.80) that consumes some Gerald> 450MB of memory and triggers a system load of 12+, basically Gerald> rendering the machine dead for about a minute. Gerald> Any ideas how I could nail this down? Anyone else seeing this? First, yeah, this is known. And, kudos to HJ for trying to fix this in 'make'. I've been considering working around this problem by just redoing the whole .java->.class step whenever any .java file changes. That would probably be slower for libgcj developers but at least wouldn't hugely hurt folks working elsewhere. Also, most class library development happens in Classpath these days anyway. Any comments on this? Maybe it could be a configure option. If you want full dependencies use --with-libgcj-dependencies or something. But I agree that the default should be no dependencies until most of the world has a make that can handle it. David Daney.
Re: RELOAD_OTHER bug?
DJ Delorie wrote: No, anything merged with RELOAD_OTHER has to be RELOAD_OTHER. Why? RELOAD_FOR_OTHER_ADDRESS only lives till the RELOAD_OTHER input reloads. Does this mean that RELOAD_FOR_OTHER_ADDRESS reloads can never be merged with RELOAD_OTHER reloads? Yes. But if they load the same value as a RELOAD_OTHER input, they can share the same reload register.
Re: mainline bootstrap broken on i686-pc-linux-gnu
I see this here too. Apparently this was caused by the i386.h PUSH_ROUNDING change of this patch: 2005-12-13 Jakub Jelinek <[EMAIL PROTECTED]> PR debug/25023 PR target/25293 * expr.c (emit_move_resolve_push): Handle PRE_MODIFY and POST_MODIFY with CONST_INT adjustment equal to PUSH_ROUNDING. Fix POST_INC/POST_DEC handling if PUSH_ROUNDING is not identity. * config/i386/i386.md (pushhi2, pushqi2): Use pushl instead of pushw. Set mode to SI, adjust constraints. (pushhi2_rex64, pushqi2_rex64): Set mode to DI. * config/i386/i386.h (PUSH_ROUNDING): Round up to 4 instead of 2 for 32-bit code. The push_operand predicate does not allow pushes with a mode that does not agree with PUSH_ROUNDING.
Re: mainline and 4.1 bootstrap broken on i686-pc-linux-gnu
I see the same failure on x86-linux both 4.1 and trunk as of revision 108478 (was working on trunk as of 108381). x86_64-linux is fine on both branches at the same revision. Probably: 2005-12-13 Jakub Jelinek <[EMAIL PROTECTED]> PR debug/25023 PR target/25293 * expr.c (emit_move_resolve_push): Handle PRE_MODIFY and POST_MODIFY with CONST_INT adjustment equal to PUSH_ROUNDING. Fix POST_INC/POST_DEC handling if PUSH_ROUNDING is not identity. * config/i386/i386.md (pushhi2, pushqi2): Use pushl instead of pushw. Set mode to SI, adjust constraints. (pushhi2_rex64, pushqi2_rex64): Set mode to DI. * config/i386/i386.h (PUSH_ROUNDING): Round up to 4 instead of 2 for 32-bit code. Jakub, any idea? Laurent On Tue, 2005-12-13 at 11:25 +0100, Martin Reinecke wrote: > Hi, > > current mainline configured with the following command > $SRCDIR/configure --quiet --prefix=$DESTDIR --enable-languages=c++,fortran > --with-gmp=/afs/mpa/data/martin/mygmp > > aborts during bootstrap at this place: > > /scratch/ogcc/./gcc/xgcc -B/scratch/ogcc/./gcc/ > -B/afs/mpa/data/martin/ugcc/i686-pc-linux-gnu/bin/ > -B/afs/mpa/data/martin/ugcc/i686-pc-linux-gnu/lib/ -isystem > /afs/mpa/data/martin/ugcc/i686-pc-linux-gnu/include -isystem > /afs/mpa/data/martin/ugcc/i686-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. > -I/scratch/gcc/libmudflap -I. -Wall -ffunction-sections -fdata-sections -O2 > -g -O2 -MT mf-runtime.lo -MD -MP -MF .deps/mf-runtime.Tpo -c > /scratch/gcc/libmudflap/mf-runtime.c -fPIC -DPIC -o .libs/mf-runtime.o > /scratch/gcc/libmudflap/mf-runtime.c: In function '__mf_usage': > /scratch/gcc/libmudflap/mf-runtime.c:478: warning: value computed is not used > /scratch/gcc/libmudflap/mf-runtime.c: In function '__mfu_check': > /scratch/gcc/libmudflap/mf-runtime.c:1032: error: unrecognizable insn: > (insn 1385 1384 1386 31 /scratch/gcc/libmudflap/mf-runtime.c:1457 (set > (mem:HI (pre_dec:SI (reg/f:SI 7 sp)) [0 S2 A8]) > (reg:HI 0 ax [orig:182 __mf_lc_shift ] [182])) -1 (nil) > (nil)) > /scratch/gcc/libmudflap/mf-runtime.c:1032: internal compiler error: in > extract_insn, at recog.c:2084 > Please submit a full bug report, > with preprocessed source if appropriate. > See http://gcc.gnu.org/bugs.html> for instructions. > make[5]: *** [mf-runtime.lo] Error 1 > make[5]: Leaving directory `/scratch/ogcc/i686-pc-linux-gnu/libmudflap' > make[4]: *** [all-recursive] Error 1 > make[4]: Leaving directory `/scratch/ogcc/i686-pc-linux-gnu/libmudflap' > make[3]: *** [all] Error 2 > make[3]: Leaving directory `/scratch/ogcc/i686-pc-linux-gnu/libmudflap' > make[2]: *** [all-target-libmudflap] Error 2 > make[2]: Leaving directory `/scratch/ogcc' > make[1]: *** [all] Error 2 > make[1]: Leaving directory `/scratch/ogcc' > make: *** [bootstrap] Error 2 > > Cheers, >Martin >
Re: mainline and 4.1 bootstrap broken on i686-pc-linux-gnu
On Tue, Dec 13, 2005 at 07:44:39PM +0100, Laurent GUERBY wrote: > 2005-12-13 Jakub Jelinek <[EMAIL PROTECTED]> > > PR debug/25023 > PR target/25293 > * expr.c (emit_move_resolve_push): Handle PRE_MODIFY > and POST_MODIFY with CONST_INT adjustment equal to PUSH_ROUNDING. > Fix POST_INC/POST_DEC handling if PUSH_ROUNDING is not identity. > * config/i386/i386.md (pushhi2, pushqi2): Use pushl instead of pushw. > Set mode to SI, adjust constraints. > (pushhi2_rex64, pushqi2_rex64): Set mode to DI. > * config/i386/i386.h (PUSH_ROUNDING): Round up to 4 instead of 2 for > 32-bit code. > > Jakub, any idea? > > /scratch/gcc/libmudflap/mf-runtime.c:1032: error: unrecognizable insn: > > (insn 1385 1384 1386 31 /scratch/gcc/libmudflap/mf-runtime.c:1457 (set > > (mem:HI (pre_dec:SI (reg/f:SI 7 sp)) [0 S2 A8]) > > (reg:HI 0 ax [orig:182 __mf_lc_shift ] [182])) -1 (nil) > > (nil)) > > /scratch/gcc/libmudflap/mf-runtime.c:1032: internal compiler error: in > > extract_insn, at recog.c:2084 I can't reproduce it (otherwise I wouldn't have committed it), it bootstrapped/regtested just fine for me. Can one of those who can reproduce it give me preprocessed mf-runtime.i and exact gcc options that triggered it? It is correct that the above is rejected, but nothing should be generating it, unless it disregards PUSH_ROUNDING. Jakub
GCC CompileFarm: maintenance within two hours
I'll leaving home for the datacenter, the machines will reboot within the next two hours. I'll setup the account for people who requested them by email tonight. Laurent
Re: Installing libgcj consumes huge amounts of memory
Tom Tromey writes: > > "Gerald" == Gerald Pfeifer <[EMAIL PROTECTED]> writes: > > Gerald> Is anyone seeing this? With current 4.1 sources, on a machine > Gerald> with "only" 1GB of main memory + 1GB swap, the following part > Gerald> of `make install` > [...] > Gerald> spawns a recursive make (GNU make 3.80) that consumes some > Gerald> 450MB of memory and triggers a system load of 12+, basically > Gerald> rendering the machine dead for about a minute. > > Gerald> Any ideas how I could nail this down? Anyone else seeing this? > > First, yeah, this is known. And, kudos to HJ for trying to fix this > in 'make'. > > I've been considering working around this problem by just redoing the > whole .java->.class step whenever any .java file changes. That would > probably be slower for libgcj developers but at least wouldn't hugely > hurt folks working elsewhere. Also, most class library development > happens in Classpath these days anyway. > > Any comments on this? It wouldn't delight me. A "class depends on packages" model would, and would mostly solve the problem. Andrew.
Re: mainline bootstrap broken on i686-pc-linux-gnu
I can't reproduce it (otherwise I wouldn't have committed it), it
bootstrapped/regtested just fine for me.
Can one of those who can reproduce it give me preprocessed mf-runtime.i
and exact gcc options that triggered it?
I have attached the stripped down testcase.
The bug is triggered with:
./cc1 mf-runtime-i.c -march=i686
extern unsigned char __mf_lc_shift;
float
__mf_adapt_cache ()
{
return __mf_lc_shift;
}
Re: RELOAD_OTHER bug?
> >Does this mean that RELOAD_FOR_OTHER_ADDRESS reloads can never be
> >merged with RELOAD_OTHER reloads?
> >
> Yes. But if they load the same value as a RELOAD_OTHER input, they can
> share the same reload register.
So why does reload specifically check for RELOAD_FOR_OTHER_ADDRESS
when deciding if a merge to RELOAD_OTHER is permitted? Is this a bug
in the current logic?
for (j = 0; j < n_reloads; j++)
if (i != j && rld[j].reg_rtx != 0
&& rtx_equal_p (rld[i].reg_rtx, rld[j].reg_rtx)
&& (! conflicting_input
|| rld[j].when_needed == RELOAD_FOR_INPUT_ADDRESS
|| rld[j].when_needed == RELOAD_FOR_OTHER_ADDRESS))
{
rld[i].when_needed = RELOAD_OTHER;
rld[j].in = 0;
reload_spill_index[j] = -1;
transfer_replacements (i, j);
Re: RELOAD_OTHER bug?
DJ Delorie wrote:
Does this mean that RELOAD_FOR_OTHER_ADDRESS reloads can never be
merged with RELOAD_OTHER reloads?
Yes. But if they load the same value as a RELOAD_OTHER input, they can
share the same reload register.
So why does reload specifically check for RELOAD_FOR_OTHER_ADDRESS
when deciding if a merge to RELOAD_OTHER is permitted? Is this a bug
in the current logic?
for (j = 0; j < n_reloads; j++)
if (i != j && rld[j].reg_rtx != 0
&& rtx_equal_p (rld[i].reg_rtx, rld[j].reg_rtx)
&& (! conflicting_input
|| rld[j].when_needed == RELOAD_FOR_INPUT_ADDRESS
|| rld[j].when_needed == RELOAD_FOR_OTHER_ADDRESS))
{
rld[i].when_needed = RELOAD_OTHER;
rld[j].in = 0;
reload_spill_index[j] = -1;
transfer_replacements (i, j);
That test checks that the value can actually live in the reload register
not only during, but also
in-between (if there is such a time) the two reloads. If there is a
reload type available that is
suitable for the merged reload is another matter.
I see now that this code is in merge_assigned_reloads, so it might even
be safe there to set the
reload type to RELOAD_FOR_OTHER_ADDRESS. You'll have to check if the
reload type from
that point onward is only needed to determine the time of the reload
insn (rather than also the lifetime
of the reload register).
[PATCH] Fix bootstrap on i686-pc-linux-gnu
On Tue, Dec 13, 2005 at 08:49:56PM +, Joern RENNECKE wrote:
> >I can't reproduce it (otherwise I wouldn't have committed it), it
> >bootstrapped/regtested just fine for me.
>
> >Can one of those who can reproduce it give me preprocessed mf-runtime.i
> >and exact gcc options that triggered it?
>
> I have attached the stripped down testcase.
> The bug is triggered with:
> ./cc1 mf-runtime-i.c -march=i686
Turns out I missed -mtune=pentium4 I was using when building libmudflap
and other target libraries, sorry.
Here is a fix I have verified on the testcase and am going to bootstrap
it right now. As pushhi2 pattern is now actually pushing 32 bits,
it is the same insn as pushsi2. While we could use pushhi2 insn
(would need to use pre_modify rather than pre_dec etc.), it wouldn't
buy us anything. For -m64 we always do a DImode push as well.
Ok to commit if it succeeds?
2005-12-13 Jakub Jelinek <[EMAIL PROTECTED]>
PR debug/25023
* config/i386/i386.c (ix86_force_to_memory): Always use
SImode push for HImode in -m32.
* gcc.dg/pr25023.c: New test.
--- gcc/config/i386/i386.c.jj 2005-12-13 12:31:15.0 +0100
+++ gcc/config/i386/i386.c 2005-12-13 22:07:18.0 +0100
@@ -15790,9 +15790,8 @@ ix86_force_to_memory (enum machine_mode
}
break;
case HImode:
- /* It is better to store HImodes as SImodes. */
- if (!TARGET_PARTIAL_REG_STALL)
- operand = gen_lowpart (SImode, operand);
+ /* Store HImodes as SImodes. */
+ operand = gen_lowpart (SImode, operand);
/* FALLTHRU */
case SImode:
emit_insn (
--- gcc/testsuite/gcc.dg/pr25023.c.jj 2005-12-13 22:11:38.0 +0100
+++ gcc/testsuite/gcc.dg/pr25023.c 2005-12-13 22:12:50.0 +0100
@@ -0,0 +1,12 @@
+/* PR debug/25023 */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+/* { dg-options "-O2 -mtune=i686" { target { { i?86-*-* || x86_64-*-* } &&
ilp32 } } } */
+
+extern unsigned char v;
+
+float
+foo (void)
+{
+ return v;
+}
Jakub
Re: [PATCH] Fix bootstrap on i686-pc-linux-gnu
Jakub Jelinek wrote: While we could use pushhi2 insn (would need to use pre_modify rather than pre_dec etc.), it wouldn't buy us anything. Presumably, it would prevent a partial register stall.
Re: RELOAD_OTHER bug?
> That test checks that the value can actually live in the reload > register not only during, but also in-between (if there is such a > time) the two reloads. If there is a reload type available that is > suitable for the merged reload is another matter. I see now that > this code is in merge_assigned_reloads, so it might even be safe > there to set the reload type to RELOAD_FOR_OTHER_ADDRESS. Well, this is the case where the reload in question is changed, and where I proposed adding the test for RELOAD_FOR_OTHER_ADDRESS.
Re: [PATCH] Fix bootstrap on i686-pc-linux-gnu
On Tue, Dec 13, 2005 at 09:25:45PM +, Joern RENNECKE wrote: > >While we could use pushhi2 insn > >(would need to use pre_modify rather than pre_dec etc.), it wouldn't > >buy us anything. > > > Presumably, it would prevent a partial register stall. Only if we use the real pushw instruction. But in that case unwind info can't represent the stack movement. Jakub
Re: [PATCH] Fix bootstrap on i686-pc-linux-gnu
On Tue, Dec 13, 2005 at 09:25:45PM +, Joern RENNECKE wrote:
> >While we could use pushhi2 insn
> >(would need to use pre_modify rather than pre_dec etc.), it wouldn't
> >buy us anything.
> >
> Presumably, it would prevent a partial register stall.
Alternatively we could
subl $4, %esp
movw %ax, (%esp)
instead of
pushl %eax
Not sure how would that perform cycle wise though (on the testcase
there is actually not a partial register stall at all, since the QI->HI
zero extension is movzbl, so pushl %eax in this case is best).
BTW, I just noticed I posted an older incomplete version of the patch,
ix86_free_from_memory obviously needs corresponding adjustement.
2005-12-13 Jakub Jelinek <[EMAIL PROTECTED]>
PR debug/25023
* config/i386/i386.c (ix86_force_to_memory): Always use
SImode push for HImode in -m32.
(ix86_free_from_memory): Likewise.
* gcc.dg/pr25023.c: New test.
--- gcc/config/i386/i386.c.jj 2005-12-13 12:31:15.0 +0100
+++ gcc/config/i386/i386.c 2005-12-13 22:07:18.0 +0100
@@ -15790,9 +15790,8 @@ ix86_force_to_memory (enum machine_mode
}
break;
case HImode:
- /* It is better to store HImodes as SImodes. */
- if (!TARGET_PARTIAL_REG_STALL)
- operand = gen_lowpart (SImode, operand);
+ /* Store HImodes as SImodes. */
+ operand = gen_lowpart (SImode, operand);
/* FALLTHRU */
case SImode:
emit_insn (
@@ -15820,8 +15819,6 @@ ix86_free_from_memory (enum machine_mode
if (mode == DImode || TARGET_64BIT)
size = 8;
- else if (mode == HImode && TARGET_PARTIAL_REG_STALL)
- size = 2;
else
size = 4;
/* Use LEA to deallocate stack space. In peephole2 it will be converted
--- gcc/testsuite/gcc.dg/pr25023.c.jj 2005-12-13 22:11:38.0 +0100
+++ gcc/testsuite/gcc.dg/pr25023.c 2005-12-13 22:12:50.0 +0100
@@ -0,0 +1,12 @@
+/* PR debug/25023 */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+/* { dg-options "-O2 -mtune=i686" { target { { i?86-*-* || x86_64-*-* } &&
ilp32 } } } */
+
+extern unsigned char v;
+
+float
+foo (void)
+{
+ return v;
+}
Jakub
gcc-3.4-20051213 is now available
Snapshot gcc-3.4-20051213 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20051213/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 3.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-3_4-branch revision 108486 You'll find: gcc-3.4-20051213.tar.bz2 Complete GCC (includes all of below) gcc-core-3.4-20051213.tar.bz2 C front end and core compiler gcc-ada-3.4-20051213.tar.bz2 Ada front end and runtime gcc-g++-3.4-20051213.tar.bz2 C++ front end and runtime gcc-g77-3.4-20051213.tar.bz2 Fortran 77 front end and runtime gcc-java-3.4-20051213.tar.bz2 Java front end and runtime gcc-objc-3.4-20051213.tar.bz2 Objective-C front end and runtime gcc-testsuite-3.4-20051213.tar.bz2The GCC testsuite Diffs from 3.4-20051206 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-3.4 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Ada and TYPE_SIZE of ARRAY_TYPEs
Ada seems to set TYPE_SIZE of an ARRAY_TYPE to integer_zero_node, Not integer_zero_node, but to bitsize_zero_node, for any type that has a size of zero, which is the case here domain min max since the size in elements of the ARRAY_TYPE is zero. Note that ACATS tests are not testing *typical* Ada usage, but usage at the fringes of the language, so things like zero-sized types or array with bounds of 2**31 - 10 to 2**31 - 1 are quite common!
GCC mailing list archive search omits results after May 2005
I don't think the mailing list archive search functionality is working. It's not showing any results after May 2005. Go to: http://gcc.gnu.org/ml/gcc/ Type the name of any frequent contributor, oh say "rth" and sort by "newest". I don't get anything after May 2005. I tried several other lists and they all seems to exhibit this problem. Also if you go to the monthly page like this: http://gcc.gnu.org/ml/gcc/2005-12/ And search for anybody (say "rth" again) in "this time period only" you get zero results. This happens for all months going back to June. As of the May page, you start getting results again. I don't know how long this has been broken. (If it's been broken since May, it would be funny that nobody noticed.) Would you please look into it? Thanks, --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: GCC mailing list archive search omits results after May 2005
On 2005-12-14, Kaveh R. Ghazi <[EMAIL PROTECTED]> wrote: > I don't think the mailing list archive search functionality is > working. It's not showing any results after May 2005. Go to: > > http://gcc.gnu.org/ml/gcc/ It was noted about a week ago (but ironically you couldn't search for this thread in the list archives!) http://thread.gmane.org/gmane.comp.gcc.devel/74617 Summary of the thread: it's known about and may never be fixed, but alternative searchable archives exist (gmane, nabble, probably others like marc and mail-archive too). Cheers, Olly
Re: GCC mailing list archive search omits results after May 2005
> Summary of the thread: it's known about and may never be fixed, but > alternative searchable archives exist (gmane, nabble, probably > others like marc and mail-archive too). Could we put in a google search box on the archive pages at least, to stop confusing people? http://www.google.com/search";> http://gcc.gnu.org/ml/gcc/";>
Re: GCC CompileFarm Project
> "Sebastian" == Sebastian Pop <[EMAIL PROTECTED]> writes: Sebastian> I was thinking about collecting the patches to be tested Sebastian> dirrectly in the gcc-patches mailing list, like the patch Sebastian> queue tracks new patches. This is a nice idea. I wonder, though, whether most of the patches posted would actually apply cleanly (and to what revision...). A similar idea would be to supply a 'submit-patch' script that could be used by anybody with an account on the test machines. It could run 'svn diff' in the current workspace; upload the patch, the base revision, and the submitter; queue a full bootstrap for the patch; and mail back the results. Tom
Re: GCC mailing list archive search omits results after May 2005
On Tue, 13 Dec 2005, DJ Delorie wrote: > > Summary of the thread: it's known about and may never be fixed, but > > alternative searchable archives exist (gmane, nabble, probably > > others like marc and mail-archive too). > > Could we put in a google search box on the archive pages at least, to > stop confusing people? Technically feasible but politically sensitive. Considering that links on readings.html to sites that provide some software that's non-free-by-FSF-definition is forbidden, I'd like to know if that'd be allowed, and I'd want that answer straight from the GNU's mouth (so please don't start discussing it among just-subscribers-to-this-list and anyway don't CC me if you do). SC? brgds, H-P
Re: Installing libgcj consumes huge amounts of memory
I've been considering working around this problem by just redoing the whole .java->.class step whenever any .java file changes. That would probably be slower for libgcj developers but at least wouldn't hugely hurt folks working elsewhere. Also, most class library development happens in Classpath these days anyway. Like Andrew, I would like dependencies between one Java file and all the class file in the package. This would also help on parallelization. A possibility (which can be applied either if you have a single huge .java->.class step, or if you make it more fine grained) is to make all class files depend on all sources via an intermediate rule, like gnu/java/lang/a.class gnu/java/lang/b.class gnu/java/lang/c.class: \ gnu/java/lang.stamp touch $@ gnu/java/lang.stamp: \ gnu/java/lang/a.java gnu/java/lang/b.java gnu/java/lang/c.java $(JAVAC) $? echo stamp > $@ Paolo
