MPFR 2.2.1 Release Candidate

[Vincent Lefevre]

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/mpfr-2.2.1-rc1.tar.gz
http://www.mpfr.org/mpfr-2.2.1/mpfr-2.2.1-rc1.zip

The MD5's:
7f886c72df47dccf348165cc9feb0bb5  mpfr-2.2.1-rc1.tar.bz2
7d7f8667f577a87a435ed168db24d131  mpfr-2.2.1-rc1.tar.gz
d415d4e45fbb2ef6b69e1a565d76cfee  mpfr-2.2.1-rc1.zip

Changes from version 2.2.0 to version 2.2.1:
- Many bug fixes.
- Updated mpfr-longlong.h from the GMP 4.2 longlong.h file.
- Moved some internal declarations from mpfr.h to mpfr-impl.h.
- Use -search_paths_first on Darwin (Mac OS X) to fix linking behavior.
- Improved MPFR manual.

Please send success and failure reports to <[EMAIL PROTECTED]>.

If no problem is found, MPFR 2.2.1 should be released on 2006-11-28.

Regards,

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: 9 Nov 06 notes from GCC improvement for Itanium conference call

[Dorit Nuzman]

> 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 ISP RAS will
> implement enhanced software pipleining (as part of their new insn
> scheduler) as a complimentary software pipelining algorithm for loops
> with branches.
>
> Imho the big problem of implementing software pipelining in gcc
> environment is passes working after the MS and changing the pipelined
> code.  SMS is actually good for gcc because it makes register allocator
> changes (when register pressure is high) is less frequent.
>  Unfortunately reload (ant other subsequent passes) does other
> transformations too (not only spilling registers when the pressure is
> high).  But as Dorit wrote in her email SMS works well at least for PPC.
>

just for the record - I was actually referring to the Cell SPU (which is
not a PPC architecture).

dorit

> >
> >> We also plan to fix swing modulo scheduling to make it work on ia64
> >> and improve it by propagating data dependency information to RTL. We
> >> plan to discuss this project on the GCC mailing list in a few weeks.
> >
> >
> >
>
>

backporting arm eabi to 4.0

[Rafael Espíndola]

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 hard because the new files depend on new
infrastructure.

What I am trying right now is to build a list of patches that are in
the 4.1 branch but not in the 4.0. Then I will try to selectively move
then to 4.0.

Does someone has a better idea or some suggestions on how to do this?

Thanks,
Rafael

Re: Help for warning: type attributes are honored only at type definition

[Francesco Montorsi]

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 
__attribute__((visibility("default"))) also on forward declarations...


While I greatly appreciate the new C++ visibility support in GCC, I 
think the above warning is a big malus for cross-platform projects which 
need the M$'s __declspec() attribute also on forward declarations


in fact reading

  http://gcc.gnu.org/wiki/Visibility

I see that this feature was designed with win32's declspec() 
attribute-compatibility in mind. This has definitively been a Good Thing 
but that warning does not make GCC fully compatible with __declspec.


To remove all those warnings from the sources of my apps I'd need to use 
a DLLEXPORT_FORWARD macro when forward-declaring stuff (which would be 
defined as __declspec(dllexport) for win32 compilers like MSVC or 
Borland and which would expand to nothing for GCC).

And that would require me to change thousands of lines by hand :(

Looking around for a solution (e.g. suppress that specific warning) I've 
found:


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20345

and I wonder if the patch referenced there 
(http://gcc.gnu.org/ml/gcc-patches/2006-06/msg01511.html) does fix my 
problem, too. Does anyone know that?


In that case, which is the first GCC version which will include that patch?

Last, if that patch does not fix the warning, would it be possible to 
add a -Wno-type-attribute-declaration (or something like that) switch to 
suppress it?



Thanks a lot and keep up the good work!
Francesco Montorsi



PS: I'm using the following CC version:

[EMAIL PROTECTED]:~$ gcc --version
gcc (GCC) 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)

Re: [PATCH] Re: Canonical type nodes, or, comptypes considered harmful

[Mike Stump]

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 thoughts of enabling the checking code with --enable-checking and  
running it that way.  The speed type people already know how to  
disable it for speed testing, and releases turn it off automatically,  
and stage 1 runs the checker.  Something like:


#ifdef ENABLE_CHECKING
#define VERIFY_CANONICAL_TYPES 1
#endif

I'd like to see some random larger C++ code shoved though it to  
ensure if doesn't fall over, if you structure it that way, however,  
if instead you just warn:


+#ifdef VERIFY_CANONICAL_TYPES
+  result = structural_comptypes (t1, t2, strict);
+
+  if (result && TYPE_CANONICAL (t1) != TYPE_CANONICAL (t2))
+   {
+ /* The two types are structurally equivalent, but their
+canonical types were different. This is a failure of the
+canonical type propagation code.*/
+ warning (0, "internal: canonical types differ for identical  
types %T and %T",

+   t1, t2);
+ debug_tree (t1);
+ debug_tree (t2);
+   }
+  else if (!result && TYPE_CANONICAL (t1) == TYPE_CANONICAL (t2))
+   {
+ /* Two types are structurally different, but the canonical
+types are the same. This means we were over-eager in
+assigning canonical types. */
+ warning (0, "internal: same canonical type node for  
different types %T and %T",

+t1, t2);
+ debug_tree (t1);
+ debug_tree (t2);
+   }
+
+  return result;
+#else

or even maybe just a note, it'll make it just a bit safer in the  
short term.  People can then watch for these messages and report  
them.  I've been known to do this type of code before and the warning  
definitely was nicer as the complex cases came in after release in my  
case.


Other than that, this looks like a nice step in the right direction,  
thanks.

[gomp] distributing libgomp/libgomp.info ?

[Daniel Franke]

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 config file fastjar/configure.ac has the 
enable-...-srcdir flag, libiberty/configure.ac does not.

Thanks
Daniel

subscribe me

[Ravikiran Muppalla]

Re: [gomp] distributing libgomp/libgomp.info ?

[Andrew Pinski]

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 internal really and is always
changing and never stable.  It is not really a well defined library
unlike say libgomp.

-- Pinski

Re: [gomp] distributing libgomp/libgomp.info ?

[DJ Delorie]

> 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/whatever.