Cheers...
http://bit.ly/aagDPH
Re: Changing PR to ASSIGNED doesn't assign to me automatically
On 5 November 2010 19:54, Rainer Orth wrote: > I've noticed an annoying change of behaviour in current Bugzilla > compared to the old installation. If I changed a PR to ASSIGNED, it was > automatically assigned to me. Now, the state does change to ASSIGNED > alright, but the PR still remains assigned to unassig...@gcc.gnu.org, > which doesn't seem to make sense to me. Am I doing something wrong > here? If not, it would be extremely helpful to restore the old 2.x > behaviour. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45911 When I reported it to the bugzilla-test instance I was told it's by design as the status and assigned-to fields are distinct. FWIW I prefer the old behaviour too, so a compromise would be a button which sets both fields, like the one to mark as a duplicate.
Re: Discussion about merging Go frontend
> 2010-10-28 Ian Lance Taylor
>
> * lto-objfile.c: New file.
> * lto-elf.c: Remove file.
This has removed the support for compatible architectures present in lto-elf.c
and hasn't added any replacement in libiberty, so a bunch of LTO tests fail
again on 32-bit SPARC/Solaris.
The old code reads:
/* Return true if ELF_MACHINE is compatible with the cached value of the
architecture and possibly update the latter. Return false otherwise.
Note: if you want to add more EM_* cases, you'll need to provide the
corresponding definitions at the beginning of the file. */
static bool
is_compatible_architecture (Elf64_Half elf_machine)
{
if (cached_file_attrs.elf_machine == elf_machine)
return true;
switch (cached_file_attrs.elf_machine)
{
case EM_SPARC:
if (elf_machine == EM_SPARC32PLUS)
{
cached_file_attrs.elf_machine = elf_machine;
return true;
}
break;
case EM_SPARC32PLUS:
if (elf_machine == EM_SPARC)
return true;
break;
default:
break;
}
return false;
}
so it was not only accepting object files with compatible architectures in the
same LTO compilation, but also updating the current architecture for later
write operations. This is modelled on the linker.
--
Eric Botcazou
Re: build issue
Thanks for your help. I just try to clean all I could in the gcc folder but I still have the same problem. Here is the way I configure with the result: [...@localhost gcc]$ ./configure --prefix=/home/fdt --with-mpc=/home/fdt --with-mpfr=/home/fdt --with-gmp=/home/fdt --enable-languages=c++ checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking target system type... x86_64-unknown-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether ln works... yes checking whether ln -s works... yes checking for a sed that does not truncate output... /bin/sed checking for gawk... gawk checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking for gnatbind... no checking for gnatmake... no checking whether compiler driver understands Ada... no checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1 $$f2 checking for objdir... .libs checking for the correct version of gmp.h... yes checking for the correct version of mpfr.h... yes checking for the correct version of mpc.h... yes checking for the correct version of the gmp/mpfr/mpc libraries... yes checking for version 0.10 (or later revision) of PPL... no The following languages will be built: c,c++,lto *** This configuration is not supported in the following subdirectories: target-libada gnattools target-libgfortran target-libffi target-zlib target-libjava target-libobjc target-boehm-gc (Any other directories should still work fine.) checking for default BUILD_CONFIG... bootstrap-debug checking for bison... bison -y checking for bison... bison checking for gm4... no checking for gnum4... no checking for m4... m4 checking for flex... flex checking for flex... flex checking for makeinfo... makeinfo checking for expect... expect checking for runtest... runtest checking for ar... ar checking for as... as checking for dlltool... no checking for ld... ld checking for lipo... no checking for nm... nm checking for ranlib... ranlib checking for strip... strip checking for windres... no checking for windmc... no checking for objcopy... objcopy checking for objdump... objdump checking for cc... cc checking for c++... c++ checking for gcc... gcc checking for gcj... no checking for gfortran... no checking for ar... no checking for ar... ar checking for as... no checking for as... as checking for dlltool... no checking for dlltool... no checking for ld... no checking for ld... ld checking for lipo... no checking for lipo... no checking for nm... no checking for nm... nm checking for objdump... no checking for objdump... objdump checking for ranlib... no checking for ranlib... ranlib checking for strip... no checking for strip... strip checking for windres... no checking for windres... no checking for windmc... no checking for windmc... no checking where to find the target ar... host tool checking where to find the target as... host tool checking where to find the target cc... just compiled checking where to find the target c++... just compiled checking where to find the target c++ for libstdc++... just compiled checking where to find the target dlltool... host tool checking where to find the target gcc... just compiled checking where to find the target gcj... host tool checking where to find the target gfortran... host tool checking where to find the target ld... host tool checking where to find the target lipo... host tool checking where to find the target nm... host tool checking where to find the target objdump... host tool checking where to find the target ranlib... host tool checking where to find the target strip... host tool checking where to find the target windres... host tool checking where to find the target windmc... host tool checking whether to enable maintainer-specific portions of Makefiles... no checking whether -fkeep-inline-functions is supported... yes configure: creating ./config.status config.status: creating Makefile I just see that among the additional language is the lto one. Even if I did not understood the mail from Ian Lance Taylor he is already talking about lto, maybe there is a relation. I have also attached the config.log file, it might help. Regards On 11/05/2010 01:09 AM, Dave Korn wrote: On 04/11/2010 23:27, Paolo Carlini wrote: Hi, I've been working in this area lately and have been using GOLD rather than GNU LD, so there could be a problem here. I'll see if I can reproduce it. Thanks Dave for your availability. For the
Re: build issue
Hi My latest build finally succeeded, I have simply removed everything reported by 'svn status' as unknown and done a re-configuration and build. Thanks for your help and sorry for the noise. François On 11/05/2010 01:09 AM, Dave Korn wrote: On 04/11/2010 23:27, Paolo Carlini wrote: Hi, I've been working in this area lately and have been using GOLD rather than GNU LD, so there could be a problem here. I'll see if I can reproduce it. Thanks Dave for your availability. For the record, I don't personally use gold. Paolo I configured r.166338 using: da...@gcc10:~/gcc/obj2$ '/n/10/davek/gcc/gcc/configure' '--prefix=/n/10/davek/gcc' '--with-mpfr=/opt/cfarm/mpfr-2.4.1' '--with-gmp=/opt/cfarm/gmp-4.2.4' '--with-mpc=/opt/cfarm/mpc-0.8' '--with-libelf=/n/10/davek/usr' '--enable-bootstrap' '--enable-static' '--enable-shared' '--enable-shared-libgcc' '--enable-lto' '--enable-plugin' --with-plugin-ld=ld '--enable-languages=c,c++,fortran,objc,obj-c++' ... and it just completed bootstrap fine, so I definitely need François' settings. I'll try a few other variants experimentally while waiting to hear back. cheers, DaveK
Re: Discussion about merging Go frontend
On Wed, 3 Nov 2010, Ian Lance Taylor wrote: > "Joseph S. Myers" writes: > > > I think new front ends should be reviewed for general style, coding > > conventions, use of deprecated interfaces, unportabilities etc., just as > > new back ends should be reviewed. > > Would anybody care to volunteer to review the Go frontend on these > grounds? The code can be found on the gccgo branch in the gcc/go > subdirectory. I have now posted reviews of this code for various issues, though I think it could do with more eyes on it, from front-end maintainers, build-system maintainers and others. I did not go exhaustively through all the code in gofrontend/. http://gcc.gnu.org/ml/gcc-patches/2010-11/msg00640.html http://gcc.gnu.org/ml/gcc-patches/2010-11/msg00654.html http://gcc.gnu.org/ml/gcc-patches/2010-11/msg00656.html > There is also the libgo directory. The contents of libgo/go are a copy > of the standard Go library and I don't think a review of that would be > useful. But it would be reasonable to review the contents of libgo > outside of libgo/go. This code can found on the gccgo branch in the > libgo subdirectory. I don't propose to review this. A build-system maintainer might be most useful there. -- Joseph S. Myers jos...@codesourcery.com
gcc-4.6-20101106 is now available
Snapshot gcc-4.6-20101106 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20101106/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 166408 You'll find: gcc-4.6-20101106.tar.bz2 Complete GCC (includes all of below) MD5=0ad75af541b7d6dff5453c99558e61d4 SHA1=539d4b3675c478aa475a9e7ebdbf061cfbd371ce gcc-core-4.6-20101106.tar.bz2C front end and core compiler MD5=a0e0c76b78d1bfae91c886290362902a SHA1=3ecce8a51be8dd10fa9f4171c535fc9ba112120f gcc-ada-4.6-20101106.tar.bz2 Ada front end and runtime MD5=804e4ccbb9d039e47f1efd5c120e1565 SHA1=22af7b9e4dc61f613499ea143d62a7148c4467f6 gcc-fortran-4.6-20101106.tar.bz2 Fortran front end and runtime MD5=7c871fc41f8d4c40e31288fc663b5cb9 SHA1=21db0d8d99b10d280f44bd27138aad374c528237 gcc-g++-4.6-20101106.tar.bz2 C++ front end and runtime MD5=e10e76d1ddf149e3993da85ca90b28df SHA1=0406a4bbe87085eda9056edd99b9d4f812b55b54 gcc-java-4.6-20101106.tar.bz2Java front end and runtime MD5=9d0cc18fc1925359733b631faa2259f0 SHA1=461f28e74c3c2f5c024413b9ae8d96c31fe0de19 gcc-objc-4.6-20101106.tar.bz2Objective-C front end and runtime MD5=980e1ad8b9dc76aa04c8dda876b4b47f SHA1=0f4c7ed9510e3f17635365a1c8436c4313afeb92 gcc-testsuite-4.6-20101106.tar.bz2 The GCC testsuite MD5=33cf92076c6e27b29855142801f8eaaa SHA1=c387454b3e0f7cf5c68197a73325e58b0983d7a3 Diffs from 4.6-20101030 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.6 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: build issue
On 6 November 2010 21:47, François Dumont wrote: > Hi > > My latest build finally succeeded, I have simply removed everything > reported by 'svn status' as unknown and done a re-configuration and build. That would imply you're building in the source directory - don't do that. It is strongly advised against by the docs at http://gcc.gnu.org/install/configure.html but the main reason not to is that you can simply 'rm -r objdir/*' to completely remove the build tree and start fresh.
