Re: Infinite loop in compiling javax/swing/text/html/parser/HTML_401F.list
A full bootstrap took 12h 38' on my machine (1.8Ghz G5) minus probably ~1h diverted for other tasks. Although I did not measured accurately this time before, it could be my fastest one. Most of the improvement from my original post comes from gnu/javax/swing/text/html/parser/HTML_401F.deps, for which the compile time went from over 100 minutes to below 10 (twice due to multilib). For all the other pieces of code the saving (if any) was clearly well below a factor 2. Does anyone understand what is so special to jc1 and HTML_401F in order to explain this order of magnitude? Dominique
Extending jumps after block reordering
+++ Ian Lance Taylor [06/07/07 09:16 -0700]: > shorten_branches should work correctly--you shouldn't need to do > anything special. My only guess is that there is something wrong with > the way you are reordering the blocks. For example, perhaps you are > simply reordering the CFG without reordering the insn chain. Note > that shorten_branches is not (yet) CFG aware. It simply walks the > insn chain. > > I think that should work. Although it's bb->aux, not bb->rbi->next. > I'm not sure what bb->rbi is; which version of gcc are you using? It's the latest one now, so I have bb->aux. +++ Jim Wilson [09/07/07 15:36 -0700]: > that the main call to it is > shorten_branches (get_insns ()); > which runs it on the entire function. This is probably what you want. Recap: I am reordering the basic blocks in a special manner and it seems to be done properly, I do update the insns order after. The problem is on PPC some branches are too short to reach their targets which at assembly time results in assembler errors: Error: operand out of range (0x00017ef0 is not between 0x8000 and 0x7fff) In passes.c shorten_branches() is already run AFTER my pass (which is run just before pass_duplicate_computed_gotos). What I believe I need to do: a) find which branches cannot reach their destination, e.g. cond branches with relative addr, with targets beyond the maximum distance, b) split these branches into a cond branch to a non-cond branch, which should have a longer target span (create a new BB w/ non-cond branch to the target label and redirect the original branch to it) Questions: * shorten_branches() computes sizes of instructions so I know what the distance is between a jump instr and its target label. But how do I know what is the maximum distance each kind of branch can safely take? bb-reorder.c assumes that its only when cold/hot partitions are crossed it has to use indirect jumps, which is not the appropriate test in my case. * do I get it right that shorten_branches() does not really modify instructions but it helps to shorten branches by providing more accurate insns lengths? Thanks, Gregory -- Gregory B. Prokopski <[EMAIL PROTECTED]> Sable Research Group http://www.sable.mcgill.ca Montreal, Quebec, Canada
Re: Autovectorized HIRLAM - latest results.
On Oct 29, 2007 10:49 AM, Dorit Nuzman <[EMAIL PROTECTED]> wrote: > I wonder if it's versioning-for-aliasing (run-time dependence testing) that > was responsible for a lot of the new vectorizable loops > It is then possible that the code size noticeably increased. Toon could you provide more data on the size of the executables with and without vectorization, and also: $ grep 'versioning for alias checks' HL_Prepare_00.html | wc -l Thanks, Sebastian -- AMD - GNU Tools
Re: GCC 4.3 release schedule
Richard Guenther writes: > On 10/26/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote: > > > Note that we are building what-becomes-openSUSE 11.0 with current trunk > > > in parallel to 4.2 at the moment, switching to 4.3 is in the next weeks > > > (unless I get pushed back again ;)). > > > > > > > > It would be excellent to have both openSUSE and fedora pounding on 4.3 > > at the same time. > > Yes. I think Ubuntu is on track for 4.3 as well, most likely Debian, too. Ubuntu did plan the 2008 April release (8.04) with a compiler taken from the 4.2 branch; the main repository is already fixed to build with 4.3 and build tests are run regularily, so a change to 4.3 could be considered. About 5% of the packages needed a change to build with 4.3 (most of them added C++ headers). Debian's next release will be around fall 2008 (or later, when its ready), considering 4.3 as the system compiler, hopefully for all 10+ architectures. Both distributions do not rebuild the archive by default when changing the compiler version, so the new compiler is only used for new package uploads. For previous releases APIs of runtime libraries were changed up to close the release date. This makes it somewhat difficult to already use a prerelease version of the compiler in the distribution (or all packages uploaded between the compiler upload and the upload of a fixed comiler need to be rebuilt, which might be difficult for the slower Debian architectures). Would the GCC developers consider an ABI/API freeze somehwat between beginning of stage3 and the release? Matthias
Re: Infinite loop in compiling javax/swing/text/html/parser/HTML_401F.list
> Most of the improvement from my original post comes from > gnu/javax/swing/text/html/parser/HTML_401F.deps, for which the compile time > went from over 100 minutes to below 10 (twice due to multilib). For all the > other pieces of code the saving (if any) was clearly well below a factor 2. > Does anyone understand what is so special to jc1 and HTML_401F in order to > explain this order of magnitude? Very likely because HTML_401F relies heavily on memory partitioning, which is kind of a fuse that triggers when the number of virtual operands goes to the roof. The fix for PR tree-optimization/33870 basically short-circuited it. -- Eric Botcazou
Re: Optimization of conditional access to globals: thread-unsafe?
Ian Lance Taylor wrote: It appears that the draft C++0x memory model prohibits speculative stores. Therefore I now think we should aim toward prohibiting them unconditionally. I agree, or perhaps unless the user specifies a flag like -fthread-unsafe-opts or something. That memory model is just a draft. It was voted into the C++ standard working paper at the last meeting. And the C committee has expressed interest in adopting it, or something similar, as well. Jason
gcc-4.2-20071031 is now available
Snapshot gcc-4.2-20071031 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20071031/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch revision 129806 You'll find: gcc-4.2-20071031.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20071031.tar.bz2 C front end and core compiler gcc-ada-4.2-20071031.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20071031.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20071031.tar.bz2 C++ front end and runtime gcc-java-4.2-20071031.tar.bz2 Java front end and runtime gcc-objc-4.2-20071031.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20071031.tar.bz2The GCC testsuite Diffs from 4.2-20071024 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 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.
gcc 4.3.0 revision 129794 on hppa2.0w-hp-hpux11.00
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Builds fine with gcc 4.1.2 as boostrap compiler: Target: hppa2.0w-hp-hpux11.00 Configured with: /raid/tecosim/it/devel/projects/develtools/src/gcc-4.3.0/configure - --prefix=/appl/shared/gcc/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.0 --with-gnu-as - --with-as=/appl/shared/gcc/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.0/bin/as - --with-ld=/usr/ccs/bin/ld --enable-threads=posix --enable-shared - --enable-checking=release - --enable-languages=c,ada,c++,fortran,java,objc,obj-c++,treelang - --with-gmp=/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/install - --with-mpfr=/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/install - --with-local-prefix=/appl/shared/gnu/HP-UX/hppa2.0w-hp-hpux11.00 Thread model: posix gcc version 4.3.0 20071031 (experimental) (GCC) But using this as bootstrap compiler for itself results in the following error in stage 1: gcc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings - -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition - -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings-DHAVE_CONFIG_H - -DGENERATOR_FILE -o build/genconstants \ build/genconstants.o build/rtl.o build/read-rtl.o build/ggc-none.o build/vec.o build/min-insn-modes.o build/gensupport.o build/print-rtl.o build/errors.o ../build-hppa2.0w-hp-hpux11.00/libiberty /libiberty.a /usr/ccs/bin/ld: Unsatisfied symbols: ggc_free (first referenced in build/rtl.o) (data) /usr/ccs/bin/ld: (Warning) Linker features were used that may not be supported in future releases. The +vallcompatwarnings option can be used to display more details, and the ld(1) man page contains additio nal information. This warning can be suppressed with the +vnocompatwarnings option. collect2: ld returned 1 exit status gmake[3]: *** [build/genconstants] Error 1 gmake[3]: Leaving directory `/disk1/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.0/gcc-4.3.0/gcc' gmake[2]: *** [all-stage1-gcc] Error 2 gmake[2]: Leaving directory `/disk1/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.0/gcc-4.3.0' gmake[1]: *** [stage1-bubble] Error 2 gmake[1]: Leaving directory `/disk1/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/gcc-4.3.0/gcc-4.3.0' gmake: *** [all] Error 2 Comments? Should I file a bug report? Rainer - -- Mit freundlichen Grüßen / Best Regards Dipl.-Ing. Rainer Emrich Dept. Manager IT/Softwareentwicklung TECOSIM Technische Simulation GmbH Ferdinand-Stuttmann-Straße 15 D-65428 Rüsselsheim Phone +49 (0) 6142 8272-330 Fax+49 (0) 6142 8272-249 Mobile +49 (0) 163 5694920 www.tecosim.com best partner for simulation _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ TECOSIM Technische Simulation GmbH, Rüsselsheim Firmensitz: Ferdinand-Stuttmann-Straße 15, 65428 Rüsselsheim Registergericht: Amtsgericht Darmstadt, HRB 83704 Geschäftsführer: Udo Jankowski, Jürgen Veith -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHKQat3s6elE6CYeURAmIaAJ0Uqn3O6QM9Mf/0ZuaP7cKg7epuLgCgxSO4 t4aj2y8VtOYN3OG9odntFPI= =1+CX -END PGP SIGNATURE-
