Hi,
I'm posting this announce to this list as GCC now uses MPFR...
The release of MPFR 2.2.1 is imminent. Please help to make this
release as good as possible by downloading and testing this
release candidate:
http://www.mpfr.org/mpfr-2.2.1/mpfr-2.2.1-rc1.tar.bz2
http://www.mpfr.org/mpfr-2.2.1/m
> Vladimir Yanovsky wrote:
>
> That comment was about SMS. Last time when I tried SMS for Itanium on
> SPEC2000 a few monts ago, a lot of tests did not work. As RCSP I don't
> think we need this. It is too complicated algorithm. Mainstream
> approach is modulo scheduling. I hope people from I
I am working on a ARM backend for LLVM. The problemis that llvm-gcc is
currently based on gcc 4.0 and I would like to use the new EABI.
I have started to back port the ABI from 4.1 to 4.0. The first attempt
was to just copy the gcc/config/arm directory and try to fix build
errors. This proved har
Maybe this is not the right list for such question?
Should I directly use gcc bugzilla?
Thanks,
Francesco
Francesco Montorsi ha scritto:
Hi all,
I'm getting a lot of warnings of type:
warning: type attributes are honored only at type definition
when building a library which uses the
On Nov 21, 2006, at 11:06 AM, Doug Gregor wrote:
Make DEPTH=6, we get an 85% speedup:
Yes, this mirrors the type of speed up I expect for _some_ types of
template code. I'd love to see us go in this direction. Anyway, I
endorse this type of work.
Anyway, on to the review...
Any thought
To the gcc packagers:
Shall libgomp/libgomp.info ever be distributed, i.e. is there any reason to
add the --enable-generated-files-in-srcdir flag from gcc/configure.ac to
libgomp/configure.ac as well?
The tarball of 4.1.1 includes fastjar/fastjar.info, but not
libiberty/libiberty.info. The co
On Wed, 2006-11-22 at 22:52 +0100, Daniel Franke wrote:
> The tarball of 4.1.1 includes fastjar/fastjar.info, but not
> libiberty/libiberty.info. The config file fastjar/configure.ac has the
> enable-...-srcdir flag, libiberty/configure.ac does not.
This is because libiberty's API is all interna
> This is because libiberty's API is all internal really and is always
> changing and never stable. It is not really a well defined library
> unlike say libgomp.
... although we do try to keep backward compatiblity when possible, so
that newer libiberties work with older gcc/binutils/gdb/whateve
