Re: toplevel *again* out of sync
> DJ, can you amend your scripts so that the head of gcc/ChangeLog and > src/ChangeLog is included? This will make it easier to bug relevant > people. Done.
Problem in bootstrapping on mingw
Hi all, I'm trying to bootstrap trunk on i686-pc-mingw32. I configure with --disable-werror --enable-threads --disable-nls --build=i686-pc-mingw32 --enable-libgomp --with-dwarf2 --disable-sjlj-exceptions During stage 1, bootstrap fails when comparing trunk tm.texi and the version regenerated from tm.texi.in. The comparison fails because of newlines (the generated ones are Windows-style, and the trunk ones are Unix-style). I can't find a bugzilla PR for that, so I believe this may be something local to me, although the description of the problem seems generic. Has this happened to someone already? How do you fix it? Thanks, FX
Re: Problem in bootstrapping on mingw
2010/10/3 FX :
> Hi all,
>
> I'm trying to bootstrap trunk on i686-pc-mingw32. I configure with
> --disable-werror --enable-threads --disable-nls --build=i686-pc-mingw32
> --enable-libgomp --with-dwarf2 --disable-sjlj-exceptions
>
> During stage 1, bootstrap fails when comparing trunk tm.texi and the version
> regenerated from tm.texi.in. The comparison fails because of newlines (the
> generated ones are Windows-style, and the trunk ones are Unix-style). I can't
> find a bugzilla PR for that, so I believe this may be something local to me,
> although the description of the problem seems generic. Has this happened to
> someone already? How do you fix it?
>
> Thanks,
> FX
>
>
>
This is a known issue and related to timestamps of those generated
.texi files. By touching generated .texi it can be solved. This test
in make is here a bit broken IMHO, as a content check would satisfy
needs for validity-check alone.
Kai
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
Re: Problem in bootstrapping on mingw
> This is a known issue and related to timestamps of those generated > .texi files. By touching generated .texi it can be solved. This test > in make is here a bit broken IMHO, as a content check would satisfy > needs for validity-check alone. I'm wondering about this part of the Makefile: elif test $(srcdir)/doc/tm.texi -nt $(srcdir)/doc/tm.texi.in \ && test $(srcdir)/doc/tm.texi -nt $(srcdir)/doc/target.def; then \ because I don't think I have a $(srcdir)/doc/target.def, but $(srcdir)/target.def
Re: Problem in bootstrapping on mingw
> This is a known issue and related to timestamps of those generated > .texi files. By touching generated .texi it can be solved. This test > in make is here a bit broken IMHO, as a content check would satisfy > needs for validity-check alone. Actually, it doesn't solve it. If "cpmd -s" returns false, the build dies right there. FX
Who owns config.rpath?
Hi all, I can't find any mention of it at the usual place for external sources (http://gcc.gnu.org/codingconventions.html#upstream), so is our version forked, or is that just an oversight? cheers, DaveK
Re: Who owns config.rpath?
[ adding bug-gnulib ] Hi Dave, * Dave Korn wrote on Sun, Oct 03, 2010 at 01:42:15PM CEST: > I can't find any mention of it at the usual place for external sources > (http://gcc.gnu.org/codingconventions.html#upstream), so is our version > forked, or is that just an oversight? It comes originally from gettext, but for all practical matters I think you can consider gnulib to be upstream. Contents should be kept in sync with relevant parts of libtool.m4 from Libtool though. Cheers, Ralf
Re: Who owns config.rpath?
On 03/10/2010 12:24, Ralf Wildenhues wrote: > [ adding bug-gnulib ] > > Hi Dave, > > * Dave Korn wrote on Sun, Oct 03, 2010 at 01:42:15PM CEST: >> I can't find any mention of it at the usual place for external sources >> (http://gcc.gnu.org/codingconventions.html#upstream), so is our version >> forked, or is that just an oversight? > > It comes originally from gettext, but for all practical matters I think > you can consider gnulib to be upstream. > > Contents should be kept in sync with relevant parts of libtool.m4 from > Libtool though. Thank you Ralf. (Groan, 3-way sync! Might see if I can find an alternative to patching it, lazy me...) cheers, DaveK
GCC 4.4.5 Released
The GNU Compiler Collection version 4.4.5 has been released. GCC 4.4.5 is a bug-fix release containing fixes for regressions and serious bugs in GCC 4.4.4. This release is available from the FTP servers listed at: http://www.gnu.org/order/ftp.html Please do not contact me directly regarding questions or comments about this release. Instead, use the resources available from http://gcc.gnu.org. As always, a vast number of people contributed to this GCC release -- far too many to thank individually!
RFE: 'enable checking' as a GCC compilation switch?
Recently, I ran into a couple of bugs/regessions that show up only if checking is enabled. This led me to the observation that it might be useful if checking can be enabled at runtime via a gcc command line switch. If this capability can be enabled by default, then regression tests could depend upon the checking capability, or users could be asked to run with full checks enabled when reporting bugs, etc. There will be some overhead to test for the switch, though the code that does the checking might remain under an #ifdef as it does now, to ensure that it absolutely isn't compiled unless the appropriate configuration option is enabled. That said, I would argue that if we go to the trouble to implement the capability, then support for checking switches should be enabled by default. If the code is never conditionalized, then --enable-checking=xxx might be re-defined to assert the various checking flags by default. Here is are some quick stats on the use/frequency of various checking options in GCC: ENABLE_CHECKING251 ENABLE_RTL_CHECKING 21 ENABLE_IRA_CHECKING 11 ENABLE_FOLD_CHECKING10 ENABLE_GC_CHECKING 9 ENABLE_DF_CHECKING 7 ENABLE_MALLOC_CHECKING 7 ENABLE_TYPES_CHECKING5 ENABLE_TREE_CHECKING 4 ENABLE_ASSERT_CHECKING 3 ENABLE_GIMPLE_CHECKING 3 ENABLE_RTL_FLAG_CHECKING 1 ENABLE_SCOPE_CHECKING1 ENABLE_VALGRIND_CHECKING 1 --- Total 334 Certainly, plenty of them to deal with, but perhaps with a bit of scripting the bulk of the changes can be automated.
Re: RFE: 'enable checking' as a GCC compilation switch?
Gary Funck writes: > Recently, I ran into a couple of bugs/regessions that show up > only if checking is enabled. This led me to the observation that > it might be useful if checking can be enabled at runtime via a > gcc command line switch. If this capability can be enabled by > default, then regression tests could depend upon the checking > capability, or users could be asked to run with full checks > enabled when reporting bugs, etc. You will need to try a sample implementation and see how much the compiler slows down and how much bigger it gets. Ian
gcc-4.3-20101003 is now available
Snapshot gcc-4.3-20101003 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20101003/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 164917 You'll find: gcc-4.3-20101003.tar.bz2 Complete GCC (includes all of below) MD5=be62b7ae0d1c13bca6a5a2b6f8c4cab0 SHA1=59f3621f21b9a6d207cfbc4679819f8643766582 gcc-core-4.3-20101003.tar.bz2C front end and core compiler MD5=709bc410956e74a339b3affe170570b9 SHA1=e821f66f37726a299db468411a17347e28eb6c89 gcc-ada-4.3-20101003.tar.bz2 Ada front end and runtime MD5=1c57b4a999cadf20da5c3f0d3d9148f6 SHA1=820d422eb4ed3f245fbd6c33d5a1e2a7c20b101a gcc-fortran-4.3-20101003.tar.bz2 Fortran front end and runtime MD5=d39636645c5a463f935eb4f634123f2a SHA1=4bede5309954280ef19cadb3a223c90484887438 gcc-g++-4.3-20101003.tar.bz2 C++ front end and runtime MD5=bffd320fc8e5c4a1aaf7392f08983aa6 SHA1=bc3b802888ebaedcd27459c92a516f508a8414fa gcc-java-4.3-20101003.tar.bz2Java front end and runtime MD5=3182c550767a799409de047767e3fa71 SHA1=2340a8962089a30079adf97f2a2171de76ef2199 gcc-objc-4.3-20101003.tar.bz2Objective-C front end and runtime MD5=fe0fa8768444c9f4a95805d327ec4699 SHA1=62ac6edffe0060388bfa01479f2400c4015c274f gcc-testsuite-4.3-20101003.tar.bz2 The GCC testsuite MD5=bfdcc992e239ff71fa395288b7119fcb SHA1=97ba555bbf9179e3e9cbeb593c0891702717e4af Diffs from 4.3-20100926 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 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: Problem in bootstrapping on mingw
On Sun, Oct 3, 2010 at 6:05 AM, FX wrote: >> This is a known issue and related to timestamps of those generated >> .texi files. By touching generated .texi it can be solved. This test >> in make is here a bit broken IMHO, as a content check would satisfy >> needs for validity-check alone. > > Actually, it doesn't solve it. If "cpmd -s" returns false, the build dies > right there. > > FX > I talked to the gcc folks. We need a GCC bugzilla PR. Can you write one and add me ot the CC list?
