.tar.gz
http://www.mpfr.org/mpfr-2.3.0/mpfr-2.3.0-rc1.zip
[...]
Please send success and failure reports to [EMAIL PROTECTED].
Works for me on sparc-sun-solaris2.10 and sparc64-sun-solaris2.10.
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
that it is not normal.
So how do we detect or work around this promotion issue and discriminate
between the case where a float is promoted because of the variadic
prototype vs a user supplied cast or other user code?
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
On Fri, 6 Jul 2007, Joseph S. Myers wrote:
On Fri, 6 Jul 2007, Kaveh R. GHAZI wrote:
So how do we detect or work around this promotion issue and discriminate
between the case where a float is promoted because of the variadic
prototype vs a user supplied cast or other user code?
I think
On Sat, 7 Jul 2007, Joseph S. Myers wrote:
On Sat, 7 Jul 2007, Kaveh R. GHAZI wrote:
Ok, how about e.g. __attribute__ ((__type_generic__)), which would only be
allowed on variadic functions?
I don't think we want this available to user code, just to builtins, so a
name such as type
On Sat, 7 Jul 2007, Joseph S. Myers wrote:
No, that's something else entirely (a float old-style parameter
declaration corresponds to a double argument in a prototype). It's
convert_arguments that handles converting to prototype types and default
argument promotions for arguments not covered
following that example. We don't want to confuse users into thinking they
can use it IMHO. What do you suggest?
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
users
are used to it syntax-wise.
I don't know about using reference types, but there are several math
builtins that return multiple values, the extra ones via pointer
arguments. E.g. see frexp, lgamma_r, modf, remquo and/or sincos.
--Kaveh
--
Kaveh R. Ghazi
-Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -version
-fkeep-inline-functions -fPIC -o libgcc2.s
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
libgcc2.i.gz
Description: libgcc2.i.gz
On Fri, 24 Aug 2007, Brian Sidebotham wrote:
This ICE is caused by the following patch:
2007-08-10 Kaveh R. Ghazi [EMAIL PROTECTED]
* system.h (CONST_CAST): New.
* c-decl.c (c_make_fname_decl): Use it.
* c-lex.c (cb_ident, lex_string): Likewise.
* c-typeck.c
On Sun, 26 Aug 2007, Richard Guenther wrote:
+#if defined(__GNUC__) GCC_VERSION != 4000
There were 4.0.0, 4.0.1, 4.0.2, 4.0.3 and 4.0.4 releases.
Yes, and... ?
GCC_VERSION == 4000 for all of them.
--
Kaveh R. Ghazi [EMAIL PROTECTED]
.
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
On Tue, 28 Aug 2007, Brian Sidebotham wrote:
2007-08-26 Kaveh R. Ghazi [EMAIL PROTECTED]
* system.h (CONST_CAST): Avoid union for gcc-4.0.x.
diff -rup orig/egcc-SVN20070825/gcc/system.h egcc-SVN20070825/gcc/system.h
--- orig/egcc-SVN20070825/gcc/system.h 2007-08-10 14:11
is needed, but it does seem to be.
*/
This second patch also allows bootstrap to complete on my sparc box.
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
)))
+ delete_insn (insn);
if (!JUMP_P (insn))
continue;
FWIW, this patch fixes the problem. Test results here:
http://gcc.gnu.org/ml/gcc-testresults/2007-09/msg00313.html
I'll try again with your updated version tonight.
--Kaveh
--
Kaveh R. Ghazi [EMAIL
) throw (std::bad_alloc);
void operator delete(void*) throw();
void operator delete[](void*) throw();
If this is accepted, IMHO you should use __attribute__((__malloc__)) not
__attribute__ ((malloc)).
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL
if there is no i-cache.
Is anyone else having a similar problem?
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
/postreload.c:1018
1018 reg_state[i].store_ruid = reload_combine_ruid;
(gdb)
Any luck figuring out which patch broke it?
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
('a'); putchar('b'); ?
I'd say not, unless that code was a hot spot.
One simplification I don't believe we do yet, that should always be a win,
is turning: sprintf (foo, %c, bar); into:*foo = bar;
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
On Wed, 10 Oct 2007, Joe Buck wrote:
On Wed, Oct 10, 2007 at 12:12:25AM -0400, Kaveh R. GHAZI wrote:
One simplification I don't believe we do yet, that should always be a win,
is turning: sprintf (foo, %c, bar); into:*foo = bar;
You need the null terminator: foo[0] = bar; foo[1
maintainers can weigh the
risk vs benefit and make an informed decision.
So far you've only shown us the risky part, i.e. the patch.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
, is the glass half full or half empty?
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
On Sun, 18 Nov 2007, David Edelsohn wrote:
Kaveh R GHAZI writes:
Kaveh I think the answer is maybe. In the past we have counted
compile-time
Kaveh savings as appropriate for stage3 regression fixes. However IMHO you
Kaveh would need to provide some measurement of the improvements
for anything less than mpfr-2.3.0.
I have no strong opinion on which way to go.
Thoughts?
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
, I'll do more rigorous checks before
installing when I move my stuff to a new home.
Ok for mainline?
Thanks,
--Kaveh
2007-12-10 Kaveh R. Ghazi [EMAIL PROTECTED]
* configure.ac: Change required MPFR from 2.2.0 - 2.2.1.
Change recommended MPFR
?
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
On Tue, 1 Jan 2008, Vincent Lefevre wrote:
On 2007-12-31 14:38:21 -0500, Kaveh R. GHAZI wrote:
The bug would need to be exposed using a mantissa size of a C type, like
53 for double, and the default exponent range. And all the global mpfr
flags are cleared beforehand,
Are they cleared
will intentionally
bypass folding. So this particular case is not something I can use.
I don't know if this mpfr case should be setting the underflow flag or if
it's a bug. Calling the glibc tgamma doesn't seem to think it underflowed
when looking at fetestexcept().
--Kaveh
--
Kaveh R. Ghazi
it?
--Kaveh
2008-01-16 Kaveh R. Ghazi [EMAIL PROTECTED]
* toplev.c (toplev_main): Call mpfr_free_cache().
diff -rup orig/egcc-SVN20080116/gcc/toplev.c egcc-SVN20080116/gcc/toplev.c
--- orig/egcc-SVN20080116/gcc/toplev.c 2008-01-03 23:37:34.0 +0100
+++ egcc
From: Tom Tromey [EMAIL PROTECTED]
Kaveh == Kaveh R GHAZI [EMAIL PROTECTED] writes:
Kaveh + mpfr_free_cache ();
Why not just add a valgrind suppression for this?
There's little point in freeing things just before exit.
Tom
A valgrind suppression only silences the error for valgrind. What
From: Tom Tromey [EMAIL PROTECTED]
Kaveh == Kaveh R Ghazi [EMAIL PROTECTED] writes:
Kaveh A valgrind suppression only silences the error for valgrind. What
if
Kaveh someone uses another memory checking tool? Better to fix it for
real
Kaveh IMHO.
Add suppressions for all of them. Any
On Wed, 16 Jan 2008, Andrew Haley wrote:
Kaveh R. Ghazi writes:
A valgrind suppression only silences the error for valgrind. What if
someone uses another memory checking tool? Better to fix it for real IMHO.
Because it's not a bug? You're changing the code to silence a false
negative
in order to
invoke cc1 which has the info.
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
.
The minimum version is supposed to be 2.3.0 [*]. Or is that page outdated?
[*] http://gcc.gnu.org/install/prerequisites.html
That page is up to date WRT mpfr.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
On Mon, 21 Jan 2008, [ISO-8859-1] Manuel L?pez-Ib??ez wrote:
On 20/01/2008, Kaveh R. GHAZI [EMAIL PROTECTED] wrote:
What does gcc -v foo.c say about GMP and MPFR?
[EMAIL PROTECTED]:~/131656/build/gcc$ ./xgcc -v -c -B . foo.c
[...]
revision 131656], GMP version 4.2.1, MPFR version 2.3.0
in parallel for their multilibs.
I'd be interested in your results if you try it out.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
--
Kaveh R. Ghazi [EMAIL PROTECTED]
headers. So where I differ from
your method is that I then have my mailer read this file as my mbox, e.g.
pine -f ~/foo. It'll contain this one message which you read and then
reply to. All the mail thread stuff then just works.
--Kaveh
--
Kaveh R. Ghazi [EMAIL
,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
: of the many if-aborts, which is triggered when running
under gdb? That will tell us which builtin is failing. (May be they all
are.) I don't know what the header looks like to know what if anything
should be changed by fixincludes.
--Kaveh
--
Kaveh R. Ghazi
); })
It may pass isinf, but fail on a later if-abort. But hopefully this is the
only broken bit in that header on solaris.
--Kaveh
--
Kaveh R. Ghazi
ones.
But that's up to them. In fixincludes we're free to make any choice we want
for mainline and/or branches as needed.
Thoughts?
Thanks,
--Kaveh
--
Kaveh R. Ghazi
,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
. :-)
--Kaveh
--
Kaveh R. Ghazi
From: Kaveh R. Ghazi [EMAIL PROTECTED]
From: Mike Stump [EMAIL PROTECTED]
Perhaps others are rooted from generic parts of the compiler, not
objc++. Still it would be nice to clean them up.
Agreed. If you want to work on it, I'd be happy to help out, just let
me know.
Okay, I'll file
Hi Uros,
This broke on x86_64 in the last day or so, I thought maybe you might know
what happened. (You touched config/i386 FP stuff recently.) I'm seeing a
regression in gcc.target/i386/pr32268.c as seen here:
http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg01108.html
Right now the execute
) b))
32 abort();
33
34return 0;
35 }
(gdb) p a
$1 = 0
(gdb) p b
$2 = 0
b should be 1.0.
--Kaveh
--
Kaveh R. Ghazi
sources? If not, maybe we need more Darwin maintainers.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
From: Mike Stump [EMAIL PROTECTED]
On Feb 21, 2008, at 8:31 PM, Kaveh R. GHAZI wrote:
Are current Darwin maintainers working on fixing anything in the FSF
sources?
Currently no. The transition to GPL v3 is problematic for us in the
short/mid term. :-( Longer term, we'll see how it goes
. Thanks for volunteering.
--Kaveh
--
Kaveh R. Ghazi
2005 i686 GNU/Linux
on x86_64 I get:
Linux gcc12 2.6.18-4-vserver-amd64 #1 SMP Fri May 4 01:21:52 UTC 2007 x86_64
GNU/Linux
Any help would be appreciated.
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
?
Uros looked at this for me and thinks it might be due to using an old
libc on the cfarm. I'll let him explain exactly what's needed.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
, and happy hacking!)
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
to convert that branch to GPLv3... ?
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
On Sat, 15 Mar 2008, NightStrike wrote:
On 3/15/08, Kaveh R. GHAZI [EMAIL PROTECTED] wrote:
I support the final-release-then-close approach. But can we get a
volunteer to convert that branch to GPLv3... ?
How complicated is the task?
It's not complicated, but perhaps it is tedious
--
Kaveh R. Ghazi [EMAIL PROTECTED]
.
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
On Mon, 17 Mar 2008, Mark Mitchell wrote:
Kaveh R. GHAZI wrote:
I too think that it would be a bad idea to switch the 4.1 branch to
GPLv3,
Can you please elabortate why?
I think it's a bad idea to change the license on a release branch in
deep maintenance mode. That would
From: Mark Mitchell [EMAIL PROTECTED]
Kaveh R. GHAZI wrote:
My understanding is that *users* of GCC are not impacted by the license
change.
Some users certainly are impacted by the license change -- there are in
fact quite a few companies that disallow their users using any GPLv3
software
not everyone shares my
enthusiasm for it. :-/
--Kaveh
--
Kaveh R. Ghazi
On Tue, 10 Jun 2008, Joern Rennecke wrote:
From: Ian Lance Taylor [EMAIL PROTECTED]
Use CONST_CAST_RTX where necessary.
On Mon, Jun 09, 2008 at 04:45:14PM -0700, Kaveh R. Ghazi wrote:
Or pass in a struct pointer to the data parameter containing both your
hash table and the rtx
, using C++
reserved keywords like class in C comes to mind.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
On Thu, 19 Jun 2008, Kaveh R. GHAZI wrote:
[...] I believe some work could be done (maybe even on mainline) to
activate -Wc++-compat during bootstrap as a warning only, (not an
error). E.g.:
#pragma GCC diagnostic warning -Wc++-compat
This would help clean up some of the easy stuff
into mainline.
Once done we can -Werror this warning and avoid regressions.
Strongly agree. Would you mind submitting the patch for activation of
-Wc++-compat?
Done.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
and I'd like to address those quickly.
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
On Thu, 19 Jun 2008, Ian Lance Taylor wrote:
Kaveh R. GHAZI [EMAIL PROTECTED] writes:
I'd like to avoid stomping on each other and duplicating work. Can you
tell me what you've already done and/or plan to do?
I have a bunch of patches, but as far as getting them into mainline
I'm
On Thu, 19 Jun 2008, Kaveh R. GHAZI wrote:
I'll do fortran next, then some top level files. I'll post in this thread
which ones so we don't overlap. Please do the same.
Okay, I'm starting on the top level files. I'll go backwards through the
alphabet. Doing [t-z]* right now, that's
relax the testing rules for the overlapping parts if we want
to keep our bits all working nicely.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
On Fri, 20 Jun 2008, Diego Novillo wrote:
On Fri, Jun 20, 2008 at 16:56, Kaveh R. GHAZI [EMAIL PROTECTED] wrote:
That aside, our current policy already allows e.g. not testing java if
your change is to a part of the compiler that can't possible affect it.
I didn't make it completely clear
From: Joe Buck [EMAIL PROTECTED]
On Fri, Jun 20, 2008 at 05:16:41PM -0400, Kaveh R. GHAZI wrote:
On Fri, 20 Jun 2008, Diego Novillo wrote:
On Fri, Jun 20, 2008 at 16:56, Kaveh R. GHAZI [EMAIL PROTECTED]
wrote:
That aside, our current policy already allows e.g. not testing java
On Sat, 21 Jun 2008, Andrew Haley wrote:
Steven Bosscher wrote:
On Sat, Jun 21, 2008 at 12:41 AM, Kaveh R. Ghazi [EMAIL PROTECTED] wrote:
Fundamentally, our philosophy has been to catch errors *before* they get
into the repository. Sure one day of breaking the trunk isn't so bad
been posted to fix it
and I included links for them in the PR. However they haven't been
approved for mainline yet. I think we have enough time between now and
the Aug 6th gcc-4.3.2 release date to get them in the trunk and 4.3.x
branch.
Thanks,
--Kaveh
--
Kaveh R
a few things to try? E.g. I did --with-gc=zone and a
couple of errors cropped up. If there are other configurations that come
to mind, let me know.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
bootstrapped with --with-gc=zone on
x86_64-unknown-linux-gnu. Okay for mainline?
Thanks,
--Kaveh
2008-07-04 Kaveh R. Ghazi [EMAIL PROTECTED]
* ggc-zone.c (lookup_page_table_if_allocated,
set_page_table_entry, zone_find_object_size, alloc_small_page
On Thu, 3 Jul 2008, Kaveh R. GHAZI wrote:
On Thu, 3 Jul 2008, Diego Novillo wrote:
Can you suggest a few things to try? E.g. I did --with-gc=zone and a
couple of errors cropped up. If there are other configurations that come
to mind, let me know.
I had these in mind
, this looks correct to me. (However I can't approve it).
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
From: NightStrike [EMAIL PROTECTED]
On 7/8/08, Ian Lance Taylor [EMAIL PROTECTED] wrote:
NightStrike [EMAIL PROTECTED] writes:
I was under the impression that these would be cleaned up before the
-W options were applied to the trunk.
It's pretty hard to clean up all the warnings for every
this (IMHO convoluted) part of the
bitmap implementation. So I'd rather leave it to someone who does.
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
preserving an alias for the old names)
so that they reflect reality?
I would suggest NOT using svn in the list name in case we switch version
control software yet again, however unlikely doing so may be today.
E.g. gcc-cvs - gcc-checkins, (or similar) etc.
--Kaveh
--
Kaveh R. Ghazi
On Sun, 20 Jul 2008, Richard Guenther wrote:
The mailing list webpage still refers to CVS:
http://gcc.gnu.org/lists.html
Can we rename these lists (perhaps preserving an alias for the old names)
so that they reflect reality?
I don't see a reason to rename the list.
Richard.
We don't
From: Dave Korn [EMAIL PROTECTED]
Hear, hear. The name of the list is an arbitrary label, not instructions
on what kind of client to use to access the repository; why, just for the
sake of making it correct in some non-functional sense of the word
should
everyone in the world have to adjust
On Sun, 21 Sep 2008, NightStrike wrote:
On Sun, Sep 21, 2008 at 12:36 PM, Brian Dessent [EMAIL PROTECTED] wrote:
Simon Hill wrote:
http://gcc.gnu.org/onlinedocs/gccint/index.html. (Of course I was
horrified to see it's not written in C++, and it's loaded with macros
--- why??).
You
if necessary.
Okay for mainline?
Thanks,
--Kaveh
2008-10-04 Kaveh R. Ghazi [EMAIL PROTECTED]
* configure.ac (MPFR check): Bump minimum version to 2.3.0 and
recommended version to 2.3.2.
* builtins.c: Remove MPFR_VERSION_NUM(2,3,0) conditionals
From: Adrian Bunk [EMAIL PROTECTED]
On Sat, Oct 04, 2008 at 09:33:48PM -0400, Kaveh R. GHAZI wrote:
Since we're in stage3, I'm raising the issue of the MPFR version we
require for GCC, just as in last year's stage3 for gcc-4.3:
http://gcc.gnu.org/ml/gcc/2007-12/msg00298.html
I'd like
From: Richard Guenther [EMAIL PROTECTED]
On Sun, Oct 5, 2008 at 3:33 AM, Kaveh R. GHAZI [EMAIL PROTECTED]
wrote:
Okay for mainline?
Ok if there are no objections within the week.
Thanks,
Richard.
Great, thanks. Can I get an explicit ack from a fortran maintainer as well?
Regards
From: Tobias Schlüter [EMAIL PROTECTED]
[EMAIL PROTECTED] and @option{--with-gmp-include}. Alternatively,
+if a GMP source ditribution is found in a subdirectory of you GCC
+sources named @file{gmp}, it will be built together with [EMAIL PROTECTED]
+Library is not installed in your default
From: Geoff Keating [EMAIL PROTECTED]
I found that simply building MPFR in a non-default location (configure
--prefix make) and then pointing GCC at it with --with-mpfr, as in
the installation instructions, causes the bootstrap to fail when first
running xgcc, because xgcc can't find the built
,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
,
Are there any MPFR bugs fixed in 2.4.0 that can be exposed through the
limited way GCC uses MPFR?
Thanks,
--Kaveh
--
Kaveh R. Ghazi gh...@caip.rutgers.edu
From: Vincent Lefevre vincent+...@vinc17.org
On 2008-12-13 01:46:21 -0500, Kaveh R. GHAZI wrote:
Changes from version 2.3.2 to version 2.4.0:
[...]
- Bug fixes.
Are there any MPFR bugs fixed in 2.4.0 that can be exposed through the
limited way GCC uses MPFR?
The announce was incorrect
--
Kaveh R. Ghazi gh...@caip.rutgers.edu
On Tue, 27 Jan 2009, James Dennett wrote:
On Mon, Jan 26, 2009 at 11:52 PM, zol...@bendor.com.au wrote:
I was debugging a function and by inserting the debug statement crashed
the system. Some investigation revealed that gcc 4.3.2 arm-eabi (compiled
from sources) with -O2 under some
part get changed?
Thanks,
--Kaveh
--
Kaveh R. Ghazi gh...@caip.rutgers.edu
From: Tobias Burnus bur...@net-b.de
Hi Kaveh,
Kaveh R. GHAZI wrote:
I'm trying to create complex number expressions that contain inf or
nan in the imaginary part. I.e. (0 + inf I) or (0 + nan I).
If it does not need to be C (e.g. to try MPC in the middle end), you
could use Fortran
From: Joseph S. Myers jos...@codesourcery.com
On Thu, 29 Jan 2009, Kaveh R. GHAZI wrote:
I don't think these results are a bug, rather it's just an artifact of
the
way complex multiplcation is done and having these special values in
See bug 24581. Some aspects are a bug (GCC doesn't
://gcc.gnu.org/ml/gcc/2006-01/msg00951.html
was sufficient to get a C-only bootstrap working on solaris2.10 using
cc for stage1.
I'm going to run a full test, but that'll take many many hours
longer.
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
--
Kaveh R. Ghazi [EMAIL PROTECTED]
was a target library. No extra
dependencies are introduced for bootstrap it just modifies the order
things get done.
It'll be more complicated for a cross-config, but at least everything
you need is in the local src tree.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
?)
Looking at the testsuite results, many of the people who don't bother
to compile Ada do currently compile and test java. I suspect if we
make it harder to boot/test java then we'll see it's testing and
support decline.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
instead.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
like this idea better.
Next you need to recruit someone to implement this enhancement, or
submit a patch. :-) Although given that you can silence the warning by
adding an extra NULL at the call site, I'm not sure it's worth it.
--Kaveh
--
Kaveh R. Ghazi [EMAIL
1 - 100 of 287 matches
Mail list logo
