Re: Bootstrap failure on trunk: x86_64-linux-gnu
> This code only works for one-complement machines, since it assumes a > symmetric range for Int. It breaks when UI_To_Int returns Integer'First, as > it did in this case. When it does, the abs produces an erroneous result > (since checking is disabled). So it almost doesn't matter what it puts into > Num (but it actually puts in an out-of-range value there too). Is there a simple way to have the Ada runtime (+ compiler) be built with checking enabled when bootstrapping? Thanks a lot, Duncan.
Re: automation: Problem with builddir != srcdir requirement
I'm happy to hear that. I've tried 4.1 and it works like a charm. I hope that the same happens with glibc. I doubt that. And glibc is much harder to set up and is usually built only by "people that know what they're doing"; which means you have a ~0 chance of getting the maintainers to do the change. (Note that GCC 4.1.x is just building with builddir != srcdir under your feet). Paolo
Re: Question about testsuit for native 2.95.3 files and procedure.
Yes, i know it's a long time since 2.95.3 but actually trying to improve new functionalities for that release due it's working for ARC targets specially. ARC was not supported after 2.95.3 if im not in mistake. Next release, 3.0 it's containing a testsuite folder within, but that's not the same for 2.95.3, this is why im searching the correct files to do the same, actually im trying with 3.0 testsuite in place of 2.95.3 to see what happend Help appreciatted, TIA Joe Buck wrote: > On Mon, Feb 27, 2006 at 08:15:58AM +0100, J.J.Garcia wrote: > >>Just gathering info about passing the testsuite for gcc 2.95.3, i've just >>downloaded the tarball from GNU and i realize that there is no specific >>'testsuite' folder included. > > > Is there a reason why you want to use a 6 1/2 year old compiler? > (While 2.95.3 was released in 2001, it is basically a small patch to > 2.95.2, from 1999, issued to address an incompatibility with the C > library on GNU/Linux systems). > > The problem with asking for help with such an old version is that even the > developers who worked on it and are still around have forgotten the > details. >
Re: automation: Problem with builddir != srcdir requirement
Ciao Paolo, --- Paolo Bonzini <[EMAIL PROTECTED]> ha scritto: > > I'm happy to hear that. I've tried 4.1 and it > works > > like a charm. I hope that the same happens with > glibc. > > I doubt that. And glibc is much harder to set up > and is usually built > only by "people that know what they're doing"; which > means you have a ~0 > chance of getting the maintainers to do the change. That's sad news. Maybe they would would consider a well-written patch; I have to try. > (Note that GCC 4.1.x is just building with builddir > != srcdir under your feet). That's perfectly good for me. > Paolo Thanks, CLaudio ___ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it
Re: automation: Problem with builddir != srcdir requirement
That's sad news. Maybe they would would consider a well-written patch; I have to try. If you want to remain sane, don't look at their makefiles. :-) (Note that GCC 4.1.x is just building with builddir != srcdir under your feet). That's perfectly good for me. That was to mean, that there are good reasons, when the build system becomes complex, to support only builddir != srcdir. Programs that do not support it are buggy and should be reported to the author. Paolo
Re: gcc 4.1.0 NOT built on i686-pc-linux-gnu (Scientific Linux 3.0.4)
On Thu, 2 Mar 2006 14:28:40 +0100, Vincent Lefevre wrote: The MPFR version distributed with GMP 4.1.4 is old, very buggy, and no longer maintained. It is highly recommended to compile GMP without MPFR support and compile the latest MPFR version separately. You can get it here: http://www.mpfr.org/mpfr-current/ that information has been extremely useful. actually, yesterday I had to bootstrap 4.1.0 on the platform with the oldest glibc and using 3.4.5, because compiling mpfr with 4.1.0 and using --with-mpfr-dir= triggered errors from the (old and buggy) mpfr header files. now I have downloaded libmpfr.2.2.0.tar.bz2 (no patches available), compiled gmp and mpfr with gcc 4, and used --with-gmp-dir to bootstrap 4.1.0 successfully. the only trouble is that the tree generated unpacking and compiling libmpfr.2.2.0.tar.bz2 is not compatible with what --with-mpfr-dir expects, so that configure exits; I had to copy the mpfr include files in foo/include, the libraries in foo/lib and use --with-mpfr=../../foo . -- Maurizio Loreti http://www.pd.infn.it/~loreti/mlo.html Un. of Padova, Dept. of Physics - Padova, Italy[EMAIL PROTECTED]
Re: automation: Problem with builddir != srcdir requirement
Hello, --- Paolo Bonzini <[EMAIL PROTECTED]> wrote: > > That's sad news. Maybe they would would consider a > > well-written patch; I have to try. > If you want to remain sane, don't look at their > makefiles. :-) > >> (Note that GCC 4.1.x is just building with > builddir > >> != srcdir under your feet). > >> > > That's perfectly good for me. > > > That was to mean, that there are good reasons, when > the build system > becomes complex, to support only builddir != srcdir. Yes, I agree. There are also good reasons not to fail noisily in this case, and satisfy the requirement automatically as it's the case with gcc-4.1.x . > Programs that do > not support it are buggy and should be reported to > the author. This might be good in theory, but in practice it's not that simple. I am screening _all_ GNU projects, and I'm testing, contacting the maintainers, advicing, writing many, many patches and whole new build systems just to have all GNU projects support the existence of a working configure script, or a Makefile with the common targets. Maybe when all GNU projects are mostly ok with the GNU coding standards, then we can be picky and start to fix projects with builddir == srcdir assumption. Now it's not a realistic goal. > Paolo Thanks, CLaudio ___ Yahoo! Messenger with Voice: chiama da PC a telefono a tariffe esclusive http://it.messenger.yahoo.com
GCC Torture documentation required
Hello Respected Sir/Madam, We are using the GCC Torture which has been downloaded from your website. It would be highly helpful if we could the documentation for these GCC Torture as to what each test case is testing, and intension of the testcase in the Torture testsuite. Your help with this regard would be highly appreciated. Thanks and Regards, Jayashree. > *91-080-41392027(O) > * email:[EMAIL PROTECTED] >
RE: automation: Problem with builddir != srcdir requirement
On 03 March 2006 11:38, Claudio Fontana wrote: >> Programs that do >> not support it are buggy and should be reported to >> the author. > > This might be good in theory, but in practice it's not > that simple. I am screening _all_ GNU projects, and > I'm testing, contacting the maintainers, advicing, > writing many, many patches and whole new build systems > just to have all GNU projects support the existence of > a working configure script, or a Makefile with the > common targets. > > Maybe when all GNU projects are mostly ok with the GNU > coding standards, then we can be picky and start to > fix projects with builddir == srcdir assumption. > Now it's not a realistic goal. Surely, now, when you're going over the build systems of all these projects and tidying them up to standard, rather than later, in an entire subsequent second pass over all the same ground again, is /exactly/ the right time to do it. Supporting builddir!=srcdir is only a tiny amount extra on top of what you're already doing, probably mostly handled simply by modifying your standard templates for configure scripts. Doing it in a second pass would require a /vast/ amount of redundant effort. _Please_ think very seriously about doing it now, as you go along. cheers, DaveK -- Can't think of a witty .sigline today
Re: gcc 4.1.0 NOT built on i686-pc-linux-gnu (Scientific Linux 3.0.4)
the only trouble is that the tree generated unpacking and compiling libmpfr.2.2.0.tar.bz2 is not compatible with what --with-mpfr-dir expects, so that configure exits; I had to copy the mpfr include files in foo/include, the libraries in foo/lib and use --with-mpfr=../../foo . You have to specify a --prefix option to the configure script, and install MPFR there (`make install' of course). Then, --with-mpfr will like the directory that you specified as prefix during MPFR compilation. The solution would be to allow one to drop GMP into GCC's source code, like this tar xvzf gcc-4.1.0.tar.gz cd gcc-4.1.0 tar xvzf ../gmp-4.1.4.tar.gz tar xvzf ../mpfr-2.2.0.tar.gz ln -sf gmp-4.1.4 gmp ln -sf mpfr-2.2.0 mpfr mkdir build cd build ../configure Paolo
RE: automation: Problem with builddir != srcdir requirement
--- Dave Korn <[EMAIL PROTECTED]> wrote: > On 03 March 2006 11:38, Claudio Fontana wrote: > > > >> Programs that do > >> not support it are buggy and should be reported > to > >> the author. > > > > This might be good in theory, but in practice it's > not > > that simple. I am screening _all_ GNU projects, > and > > I'm testing, contacting the maintainers, advicing, > > writing many, many patches and whole new build > systems > > just to have all GNU projects support the > existence of > > a working configure script, or a Makefile with the > > common targets. > > > > Maybe when all GNU projects are mostly ok with the > GNU > > coding standards, then we can be picky and start > to > > fix projects with builddir == srcdir assumption. > > Now it's not a realistic goal. > > Surely, now, when you're going over the build > systems of all these projects > and tidying them up to standard, rather than later, > in an entire subsequent > second pass over all the same ground again, is > /exactly/ the right time to do > it. Yes, when I have the chance to provide a completely new build system, I try to offer a complete and good one. > Supporting builddir!=srcdir is only a tiny > amount extra on top of what > you're already doing, probably mostly handled simply > by modifying your > standard templates for configure scripts. Doing it > in a second pass would > require a /vast/ amount of redundant effort. Sometimes the maintainers are not too happy to have their build systems changed, so it happens that I have to keep changes to a minimum in order to get anything at all. > _Please_ think very seriously about doing it now, > as you go along. > When I can, I do it. In practice I'll need more than one pass, and even more than two (test the release when it comes out, point out remaining problems, or bugs that crept in for example in the dist: rule,..) > cheers, > DaveK > -- > Can't think of a witty .sigline today Bye, CLaudio ___ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it
RE: GCC Torture documentation required
On 03 March 2006 11:44, [EMAIL PROTECTED] wrote: > Hello Respected Sir/Madam, > > We are using the GCC Torture which has been downloaded from your > website. It would be highly helpful if we could the documentation for > these GCC Torture as to what each test case is testing, and intension of > the testcase in the Torture testsuite. > > Your help with this regard would be highly appreciated. No such documentation exists. Many of the testcases can be tracked back, through research in the cvs history of gcc, the mailing list archives and the gcc bugzilla database, to find the precise bug that they were aimed at fixing, but there are probably quite a few fairly ad-hoc tests as well which may have been added without detailed cvs log messages; if their intent is not clear from the source code or the naming of the test file, then you are probably out of luck. cheers, DaveK -- Can't think of a witty .sigline today
Patch - GCC Port for Infineon xc16x
Hi all, KPIT Cummins is contributing the complete GCC port for Infineon XC16X architecture. We would like to request you to send in your comments on this port. As we are putting our best efforts on this port its quality will successively improve and fit more and more to the current GNU standards. KPIT Cummins has already signed copyright assignment with FSF. The XC16X is a new derivative of the popular C16X microcontroller family that is based on the enhanced C166S V2 architecture (http://www.infineon.com) it outperforms existing 16-bit solutions. Impressive DSP performance and advanced interrupt handling combined with an integrated powerful peripheral set and a high performance on-chip flash makes the XC16X the instrument of choice for demanding industrial and automotive applications. We have already submitted binutils port to FSF and it has got accepted http://sourceware.org/ml/binutils/2006-02/msg00230.html. Along with this patch you need to apply following patch http://sourceware.org/ml/binutils/2006-03/msg00042.html to binutils source so as to build the gcc. Here is the change log for GCC patch. GCC Version : gcc-4.2-20060218 Please find following two Patches attached with this mail Patch_gcc.tar.gz : Gcc Patch for xc16x Patch_gcc_configure.tar.gz : Patch for top level configure 2006-03-03Shrirang Khisti <[EMAIL PROTECTED]> *config.sub : Add xc16x entry xc16x*-*-*) so that GCC will understand new xc16x processor *configure.in : Add Entry for xc16x. *configure : Regenerate *gcc/config.gcc : Specify source files of xc16x for building *gcc/config/xc16x/xc16x.h: New file for xc16x macros *gcc/config/xc16x/xc16x.c: New file for target specific C routines *gcc/config/xc16x/xc16x.md : New file for xc16x machine description *gcc/config/xc16x/lib1funcs.asm : New file for library routines *gcc/config/xc16x/t-xc16x : New file - target makefile for xc16x *gcc/config/xc16x/xc16x-protos.h : New file containing prototypes of the functions *gcc/config/xc16x/xc16x-modes.def: New file defining PSI mode for xc16x -mlarge target option *gcc/doc/invoke.texi : Infineon xc16x specific target memory options are added *gcc/doc/md.texi : Infineon xc16x specific constraints specification *gcc/doc/install.texi: General information about xc16x *gcc/doc/extend.texi : Infineon xc16x specific attributes *gcc/doc/contrib.texi: Added the information about KPIT's contribution . Best Regards Shrirang Khisti KPIT Cummins Infosystems Ltd. Patch_gcc_configure.tar.gz Description: Patch_gcc_configure.tar.gz Patch_gcc.tar.gz Description: Patch_gcc.tar.gz
Re: Patch - GCC Port for Infineon xc16x
> 2006-03-03Shrirang Khisti <[EMAIL PROTECTED]>=20=20=20=09 > =20=09=20 > > *config.sub : Add xc16x entry xc16x*-*-*) so that GCC will > understand new xc16x processor This should go upstream and GCC should just import the newest versions of config.sub/config.guess instead. -- Pinski
[RFC] Removal of loop notes
Hello,
here is a proposal for the patch to remove loop notes (I still need to
benchmark it, and probably split into smaller parts). However, I do not
understand some of the code from that it removes loop note usage, so I
would appreciate comments on them:
cse.c:cse_end_of_basic_block -- something related to jump following.
Steven, you had some patches towards removing this, right?
jump.c:follow_jumps -- claims something about creating loops with
multiple entries. However, it seemts to be only used in cse (that won't
affect cfg), and then in dbr_schedule (way after the point where we
care about loop structures).
*sched* -- no idea what happens there; it seems to make REG_SAVE_NOTE
notes from loop notes, and then makes some magic, but I do not
understand what and why.
config/sh/sh.c: sh_adjust_unroll_max seems unused,
sh_optimize_target_register_callee_saved contains some heuristics
based on loops, I have no idea how important that heuristics is
(and I do not have hardware to benchmark it).
Zdenek
Index: doc/tm.texi
===
*** doc/tm.texi (revision 111675)
--- doc/tm.texi (working copy)
*** The maximum number of bytes to skip when
*** 7942,7949
@end defmac
@defmac LOOP_ALIGN (@var{label})
! The alignment (log base 2) to put in front of @var{label}, which follows
! a @code{NOTE_INSN_LOOP_BEG} note.
This macro need not be defined if you don't want any special alignment
to be done at such a time. Most machine descriptions do not currently
--- 7942,7949
@end defmac
@defmac LOOP_ALIGN (@var{label})
! The alignment (log base 2) to put in front of @var{label} at the beginning
! of the loop.
This macro need not be defined if you don't want any special alignment
to be done at such a time. Most machine descriptions do not currently
Index: doc/rtl.texi
===
*** doc/rtl.texi(revision 111675)
--- doc/rtl.texi(working copy)
*** level of scoping for exception handling.
*** 3139,3168
identifies which @code{CODE_LABEL} or @code{note} of type
@code{NOTE_INSN_DELETED_LABEL} is associated with the given region.
- @findex NOTE_INSN_LOOP_BEG
- @findex NOTE_INSN_LOOP_END
- @item NOTE_INSN_LOOP_BEG
- @itemx NOTE_INSN_LOOP_END
- These types of notes indicate the position of the beginning and end
- of a @code{while} or @code{for} loop. They enable the loop optimizer
- to find loops quickly.
-
- @findex NOTE_INSN_LOOP_CONT
- @item NOTE_INSN_LOOP_CONT
- Appears at the place in a loop that @code{continue} statements jump to.
-
- @findex NOTE_INSN_LOOP_VTOP
- @item NOTE_INSN_LOOP_VTOP
- This note indicates the place in a loop where the exit test begins for
- those loops in which the exit test has been duplicated. This position
- becomes another virtual start of the loop when considering loop
- invariants.
-
- @findex NOTE_INSN_FUNCTION_BEG
- @item NOTE_INSN_FUNCTION_BEG
- Appears at the start of the function body, after the function
- prologue.
-
@findex NOTE_INSN_FUNCTION_END
@item NOTE_INSN_FUNCTION_END
Appears near the end of the function body, just before the label that
--- 3139,3144
Index: cfgloopmanip.c
===
*** cfgloopmanip.c (revision 111675)
--- cfgloopmanip.c (working copy)
*** loop_split_edge_with (edge e, rtx insns)
*** 1275,1374
return new_bb;
}
- /* Uses the natural loop discovery to recreate loop notes. */
- void
- create_loop_notes (void)
- {
- rtx insn, head, end;
- struct loops loops;
- struct loop *loop;
- basic_block *first, *last, bb, pbb;
- struct loop **stack, **top;
-
- #ifdef ENABLE_CHECKING
- /* Verify that there really are no loop notes. */
- for (insn = get_insns (); insn; insn = NEXT_INSN (insn))
- gcc_assert (!NOTE_P (insn) ||
- NOTE_LINE_NUMBER (insn) != NOTE_INSN_LOOP_BEG);
- #endif
-
- flow_loops_find (&loops);
- free_dominance_info (CDI_DOMINATORS);
- if (loops.num > 1)
- {
- last = XCNEWVEC (basic_block, loops.num);
-
- FOR_EACH_BB (bb)
- {
- for (loop = bb->loop_father; loop->outer; loop = loop->outer)
- last[loop->num] = bb;
- }
-
- first = XCNEWVEC (basic_block, loops.num);
- stack = XCNEWVEC (struct loop *, loops.num);
- top = stack;
-
- FOR_EACH_BB (bb)
- {
- for (loop = bb->loop_father; loop->outer; loop = loop->outer)
- {
- if (!first[loop->num])
- {
- *top++ = loop;
- first[loop->num] = bb;
- }
-
- if (bb == last[loop->num])
- {
- /* Prevent loops from overlapping. */
- while (*--top != loop)
- last[(*top)->num] = EXIT_BLOCK_PTR;
-
- /* If loo
Re: [RFC] Removal of loop notes
Zdenek Dvorak wrote: Hello, here is a proposal for the patch to remove loop notes (I still need to benchmark it, and probably split into smaller parts). However, I do not understand some of the code from that it removes loop note usage, so I would appreciate comments on them: cse.c:cse_end_of_basic_block -- something related to jump following. Steven, you had some patches towards removing this, right? While the unreviewed fwprop patches make jump following unnecessary, I probably won't argue for its removal until 4.3. The code in question is just looking for the last instruction in the preceding basic block. If it does not find a NOTE_INSN_LOOP_END note, it will find a non-note just before it. If you really want to be sure, you may want to look for a NOTE_INSN_BASIC_BLOCK_BEG note instead. For the -fcse-follow-jumps case, we'll find a BARRIER after the LOOP_END note. For the -fcse-skip-blocks case, we're only looking for a non-label and in this case the basic-block-beginning note should do the same function as the LOOP_END note. CCing Joern because he seems to have used this stuff in the SH back-end, and can probably help understanding this code too. Paolo
GCC SC request about ecj
Andrew Haley and I had a long talk about gcj and the eclipse java compiler (we call it "ecj" for short) while we were at FOSDEM last week. We concluded that we didn't foresee any serious technical problems with using ecj as the java language front end to gcj, and that we would like to move forward with this approach. Naturally we would do the work on a branch and it would be subjected to the normal review processes, etc, before any merge to the trunk. However, we wanted to get a ruling on our plan from the steering committee before proceeding. It would be inefficient to put a lot of work into this if it were later found to be politically or legally impossible. In particular we would like to import a copy of the ecj sources into the GCC source tree, so that we can continue to deliver a complete compiler system in a single download. So, could the SC please discuss the ecj plan and let us know whether it is acceptable? It would also be helpful to have some idea of how long the discussion might take. Tom
gcc-4.1-20060303 is now available
Snapshot gcc-4.1-20060303 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20060303/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch revision 111687 You'll find: gcc-4.1-20060303.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20060303.tar.bz2 C front end and core compiler gcc-ada-4.1-20060303.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20060303.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20060303.tar.bz2 C++ front end and runtime gcc-java-4.1-20060303.tar.bz2 Java front end and runtime gcc-objc-4.1-20060303.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20060303.tar.bz2The GCC testsuite Diffs from 4.1-20060224 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 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: GCC 4.1.0 Released
* H. J. Lu: > Here are diffs of SPEC CPU 2K between before and after with gcc 4.1 > using "-O2 -ffast-math" on Nocona: And what about Opterons? IOW, how "generic" is the optimization?
