--- Comment #5 from ghazi at gcc dot gnu dot org 2007-05-19 05:12 ---
Functionality installed on trunk.
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ghazi at gcc dot gnu dot org 2007-05-18 02:31 ---
Subject: Bug 31796
Author: ghazi
Date: Fri May 18 01:31:20 2007
New Revision: 124820
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124820
Log:
PR middle-end/31796
* builtins.c (do_mpf
--- Comment #4 from ghazi at gcc dot gnu dot org 2007-05-18 02:15 ---
Subject: Bug 30251
Author: ghazi
Date: Fri May 18 01:15:28 2007
New Revision: 124819
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124819
Log:
PR middle-end/30251
* builtins.c (fold_b
--- Comment #3 from ghazi at gcc dot gnu dot org 2007-05-18 02:04 ---
Subject: Bug 30251
Author: ghazi
Date: Fri May 18 01:04:12 2007
New Revision: 124818
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124818
Log:
PR middle-end/30251
* bu
--- Comment #9 from ghazi at gcc dot gnu dot org 2007-05-15 17:47 ---
(In reply to comment #8)
> My recommendations are to document, in the description of test directives in
> the GCC Internals manual, that xfail for dg-do is only honored for dg-do run
> and ignored for other
--- Comment #7 from ghazi at gcc dot gnu dot org 2007-05-10 17:44 ---
Ben, Janis,
Would you please offer an update on the status of this PR? I'm running into
another situation where I need to xfail a dg-do link, and due to the issues
discussed in this PR it doesn't work. H
--- Comment #2 from ghazi at gcc dot gnu dot org 2007-05-07 07:35 ---
I'll be doing the reentrant lgamma_r/gamma_r versions as well. (They're
actually easier because I get the signgam identifer as a pointer parameter
rather than having to find it at global scope.)
--- Comment #1 from ghazi at gcc dot gnu dot org 2007-05-05 18:57 ---
Patch posted here:
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00297.html
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
-time
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: middle-end
AssignedTo: ghazi at gcc dot gnu dot org
ReportedBy: ghazi at gcc dot
--- Comment #2 from ghazi at gcc dot gnu dot org 2007-05-03 03:43 ---
Bessel patches posted here:
http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01624.html
http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01663.html
Awaiting review.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30251
gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ghazi at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31795
--- Comment #4 from ghazi at gcc dot gnu dot org 2007-05-03 02:50 ---
I see a similar failure on sparc-sun-solaris2.10 (where I have gmp installed in
some place not available to system.h without -I flags.) Without clear access
to gmp.h, configure botches the test for rlim_t and defines
--- Comment #3 from ghazi at gcc dot gnu dot org 2007-04-27 19:33 ---
I see it on sparc-sun-solaris2.10 as well.
http://gcc.gnu.org/ml/gcc-testresults/2007-04/msg01390.html
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from ghazi at gcc dot gnu dot org 2007-04-25 18:14 ---
(In reply to comment #5)
> ah, ok. so, in that case we probably want to just change the '3' to '2' in the
> above test:
> Index: testsuit
--- Comment #8 from ghazi at gcc dot gnu dot org 2007-04-25 18:08 ---
Updated testsuite results:
http://gcc.gnu.org/ml/gcc-testresults/2007-04/msg01287.html
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from ghazi at gcc dot gnu dot org 2007-04-25 18:07 ---
Patch installed
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #6 from ghazi at gcc dot gnu dot org 2007-04-23 08:52 ---
Subject: Bug 31616
Author: ghazi
Date: Mon Apr 23 08:52:24 2007
New Revision: 124059
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124059
Log:
PR fortran/31616
* gfortran.dg/open_er
--- Comment #5 from ghazi at gcc dot gnu dot org 2007-04-23 05:58 ---
Patch posted here:
http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01457.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31616
--- Comment #4 from ghazi at gcc dot gnu dot org 2007-04-19 05:11 ---
(In reply to comment #3)
> But then I wonder why we don't see the same failure on ia64?
Because the failing part of the testcase is only done on ilp32 targets:
! { dg-final { scan-tree-dump-times "
--- Comment #4 from ghazi at gcc dot gnu dot org 2007-04-19 04:49 ---
(In reply to comment #3)
> It looks like this platform has different error messages for a given error.
Yes that's correct. I ran open_errors.exe under the solaris truss command and
saw this:
open64(&quo
--- Comment #2 from ghazi at gcc dot gnu dot org 2007-04-18 07:05 ---
Created an attachment (id=13387)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13387&action=view)
Dump file using -fdump-tree-vect-details
Created dump file using -fdump-tree-vect-details
--
--- Comment #2 from ghazi at gcc dot gnu dot org 2007-04-18 06:58 ---
(In reply to comment #1)
> Try changing:
> call abort()
> to:
> print *, msg
> This will then print the error messages instead of aborting and you may be
> able
> to see what is going on.
If
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ghazi at gcc dot gnu dot org
GCC target triplet: sparc-sun-sol
onent: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ghazi at gcc dot gnu dot org
GCC target triplet: sparc-sun-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31615
--- Comment #28 from ghazi at gcc dot gnu dot org 2007-03-19 16:41 ---
(In reply to comment #27)
> I did a non-bootstrap build and test on hppa1.1-hp-hpux11.11 over the weekend
> (C only) and I got two failures that I don't normally see,
> builtin-pow-mpfr-1.c
> and b
--- Comment #21 from ghazi at gcc dot gnu dot org 2007-03-17 14:12 ---
I get similar "make compare" errors on sparc-sun-solaris2.10. Reverting the
bit from comment#15 fixes it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31169
--- Comment #17 from ghazi at gcc dot gnu dot org 2007-02-17 19:10 ---
(In reply to comment #16)
> Maybe we should have "gcc -v" print out the gmp and mpfr versions to help
> debug
> situations like this.
Patch for "gcc -v" here:
http://gcc.gnu.org/ml/gcc-
--- Comment #16 from ghazi at gcc dot gnu dot org 2007-02-17 18:36 ---
(In reply to comment #14)
> (In reply to comment #13)
> > Midair collision, I had just written this, but I do indeed have problems
> > with
> > shared libraries taking precedence over others,
--- Comment #12 from ghazi at gcc dot gnu dot org 2007-02-17 16:15 ---
(In reply to comment #11)
> I understand the idea of bulding with --prefix, it's just that I've had mixed
> success using it wiht mpfr/gmp. Especially, when the system administrator
> installed
--- Comment #10 from ghazi at gcc dot gnu dot org 2007-02-16 19:23 ---
(In reply to comment #7)
> The backtrace ends in mpfr_erf, I couldn't go further up. To overcome this
> difficulty, I set a breakpoint on the caller, see below.
That's perhaps because mpfr_er
--- Comment #9 from ghazi at gcc dot gnu dot org 2007-02-16 19:13 ---
(In reply to comment #8)
> Oh, just noticed this by chance: Steve's testcase also fails with optimization
> disabled, again the call to mpfr_erf is issued in do_mpfr_arg1.
Do you get a failure with a
--- Comment #6 from ghazi at gcc dot gnu dot org 2007-02-16 05:16 ---
(In reply to comment #4)
> [...] It may be darwin-specific.
> This is my best guess. Consider
> program j
> x = erf(1.5)
> end program j
> With a 4.2 gfortran prior to your patches, -fdump-t
--- Comment #5 from ghazi at gcc dot gnu dot org 2007-02-16 05:08 ---
(In reply to comment #3)
> 3. I'm suspicious about the mpfr you grabbed. Try building mpfr yourself
> from
> source and run it's testsuite to make sure it's healthy. Then link gcc with
>
--- Comment #3 from ghazi at gcc dot gnu dot org 2007-02-16 03:44 ---
I'll try to help but I don't think this has anything to do with my patches.
Fortran was using mpfr for evaluating intrinsics way before I touched anything,
and I believe it uses it's own historical
--- Comment #3 from ghazi at gcc dot gnu dot org 2007-02-12 15:22 ---
Hmm on June *15th*, the -fbounds-check flag was added to the fortran testcase
gfortran.dg/cray_pointers_2.f90, and taking that flag out of today's sources
allows the testcase to pass with -fpic.
However clear
--- Comment #2 from ghazi at gcc dot gnu dot org 2007-02-12 14:56 ---
Correction, on 4.0.3 & 4.0.4, I get one error:
FAIL: tmpdir-gcc.dg-struct-layout-1/t002 c_compat_x_tst.o-c_compat_y_tst.o link
http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg00732.html
http://gcc.gnu.org/ml
--- Comment #1 from ghazi at gcc dot gnu dot org 2007-02-12 14:39 ---
This didn't seem to arise in 4.0.x, but all later branches have the problem.
--
ghazi at gcc dot gnu dot org changed:
What|Removed |
Keywords: link-failure
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ghazi at gcc dot gnu dot org
GCC target triplet: sparc-sun-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30774
--- Comment #6 from ghazi at gcc dot gnu dot org 2007-02-01 04:23 ---
(In reply to comment #5)
> I'll take a look.
Any ideas?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29404
--- Comment #39 from ghazi at gcc dot gnu dot org 2007-01-31 15:06 ---
Subject: Bug 29335
Author: ghazi
Date: Wed Jan 31 15:06:19 2007
New Revision: 121423
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121423
Log:
PR middle-end/29335
* bu
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ghazi at gcc dot gnu dot org
GCC target triplet: sparc-sun-solaris2.10
http://gcc.gn
--- Comment #6 from ghazi at gcc dot gnu dot org 2007-01-25 04:15 ---
Subject: Bug 30447
Author: ghazi
Date: Thu Jan 25 04:15:26 2007
New Revision: 121163
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121163
Log:
PR middle-end/30447
* bu
--- Comment #4 from ghazi at gcc dot gnu dot org 2007-01-21 04:35 ---
Tom, I tried your patch and now I get the following error. On line 14 in
AnnotationInvocationHandler.h, there is "namespace sun" and "sun" is defined to
1 on solaris. When I recompile with -an
Severity: critical
Priority: P3
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ghazi at gcc dot gnu dot org
GCC target triplet: sparc-sun-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30513
--- Comment #38 from ghazi at gcc dot gnu dot org 2007-01-20 00:33 ---
Subject: Bug 29335
Author: ghazi
Date: Sat Jan 20 00:33:00 2007
New Revision: 120993
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120993
Log:
PR middle-end/29335
* bu
--- Comment #5 from ghazi at gcc dot gnu dot org 2007-01-19 14:45 ---
Patch for __complex__ builtins infrastructure and csin posted here:
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01610.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30447
--- Comment #13 from ghazi at gcc dot gnu dot org 2007-01-18 14:42 ---
4.1.x branch still has the fold checking errors with labels:
http://gcc.gnu.org/ml/gcc-testresults/2007-01/msg00699.html
http://gcc.gnu.org/ml/gcc-testresults/2007-01/msg00700.html
--
ghazi at gcc dot gnu dot org
--- Comment #12 from ghazi at gcc dot gnu dot org 2007-01-16 04:52 ---
Same results one year later on sparc/sparc64 solaris2.10 with 4.0.x branch
using --enable-checking=yes,rtl,fold:
http://gcc.gnu.org/ml/gcc-testresults/2007-01/msg00592.html
http://gcc.gnu.org/ml/gcc-testresults/2007
--- Comment #7 from ghazi at gcc dot gnu dot org 2007-01-16 04:44 ---
Patch installed on all active branches.
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from ghazi at gcc dot gnu dot org 2007-01-16 04:22 ---
Subject: Bug 12325
Author: ghazi
Date: Tue Jan 16 04:22:44 2007
New Revision: 120821
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120821
Log:
PR testsuite/12325
* gcc.dg/torture/buil
--- Comment #5 from ghazi at gcc dot gnu dot org 2007-01-16 04:13 ---
Subject: Bug 12325
Author: ghazi
Date: Tue Jan 16 04:13:43 2007
New Revision: 120820
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120820
Log:
PR testsuite/12325
* gcc.dg/torture/buil
--- Comment #4 from ghazi at gcc dot gnu dot org 2007-01-16 04:01 ---
Subject: Bug 12325
Author: ghazi
Date: Tue Jan 16 04:01:32 2007
New Revision: 120819
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120819
Log:
PR testsuite/12325
* gcc.dg/torture/buil
--- Comment #3 from ghazi at gcc dot gnu dot org 2007-01-16 03:10 ---
Subject: Bug 12325
Author: ghazi
Date: Tue Jan 16 03:10:37 2007
New Revision: 120818
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120818
Log:
PR testsuite/12325
* gcc.dg/torture/buil
--- Comment #2 from ghazi at gcc dot gnu dot org 2007-01-13 19:43 ---
Patch posted here:
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01146.html
Confirm that it cures the testcase on a vax would be nice...
--
ghazi at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from ghazi at gcc dot gnu dot org 2007-01-13 05:17 ---
(In reply to comment #2)
> (In reply to comment #1)
> > We can implement the complex variants in term of the real ones in mpfr, no?
> > I
> > don't like the idea of another build-depende
--- Comment #7 from ghazi at gcc dot gnu dot org 2007-01-13 05:01 ---
(In reply to comment #6)
> Stuff in --tool_opts from RUNTESTFLAGS goes before the dg-options on the
> command line, I just tried it. Is there some other way to do it?
Yes, the GCC docs suggest using --target
--- Comment #5 from ghazi at gcc dot gnu dot org 2007-01-13 01:01 ---
(In reply to comment #4)
> so the test fails, but the generated code is correct and optimal. I suggest
> adding -fno-pic to the test, does that look OK?
I no longer have access to the x86 boxes I was usi
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last
mplex math functions at compile-time
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: middle-end
AssignedTo: ghazi at gcc dot gnu do
--- Comment #26 from ghazi at gcc dot gnu dot org 2007-01-12 15:54 ---
Testcases deleted, problem solved.
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #25 from ghazi at gcc dot gnu dot org 2007-01-12 15:36 ---
Subject: Bug 30399
Author: ghazi
Date: Fri Jan 12 15:36:16 2007
New Revision: 120727
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120727
Log:
PR fortran/30399
* actual_array_const
--- Comment #22 from ghazi at gcc dot gnu dot org 2007-01-11 22:54 ---
> However, I note that the commit to which you pointed, was made by me to
> trunk:
> http://gcc.gnu.org/ml/gcc-cvs/2006-07/msg00074.html
> The commit to 4.0 that introduced the testcases was made by aoli
--- Comment #20 from ghazi at gcc dot gnu dot org 2007-01-11 17:16 ---
(In reply to comment #14)
> Subject: Re: testsuite failures in actual_array_constructor_2.f90
> and actual_array_substr_2.f90
> Kaveh
> > --- Comment #13 from ghazi at gcc dot gnu dot org 2
--- Comment #19 from ghazi at gcc dot gnu dot org 2007-01-11 17:04 ---
(In reply to comment #18)
> Well then please accept my humble apology. No intent to disparage. I was
> attempting to concur with Kaveh's suggestion in Comment #13 that ""WONTFIX"
--- Comment #13 from ghazi at gcc dot gnu dot org 2007-01-10 21:45 ---
Paul - The bug is not "FIXED" in 4.0, please don't mark it as such yet.
"WONTFIX" may be a more accurate description if that is the group decision.
You can remove yourself from the assigned
--- Comment #9 from ghazi at gcc dot gnu dot org 2007-01-09 15:23 ---
Assigned so that Paul gets replies.
See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30399#c8
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from ghazi at gcc dot gnu dot org 2007-01-09 15:13 ---
(In reply to comment #7)
> Kaveh,
> I haven't the slightest idea what is happening. These cases test fine on
> IA64/FC5 with gcc-4.1.2-20061101.
> The worst of it is, to judge by your gdb output,
--- Comment #6 from ghazi at gcc dot gnu dot org 2007-01-09 03:19 ---
(In reply to comment #5)
> Kaveh,
> As the culprit for both patches, I'll take a look. I had no idea that there
> was and 4.1 regressions associated with them. I'll come back to you.
> Paul
--- Comment #3 from ghazi at gcc dot gnu dot org 2007-01-07 01:39 ---
Here's the actual_array_substr_2.f90 error:
gfortran.dg/actual_array_substr_2.f90: In function 'foo':
gfortran.dg/actual_array_substr_2.f90:23: internal compiler error: in
gfc_conv_constant, at fortra
--- Comment #2 from ghazi at gcc dot gnu dot org 2007-01-07 01:24 ---
Sorry, flags to reproduce the actual_array_constructor_2.f90 failure on
sparc-sun-solaris2.10 are:
f951 actual_array_constructor_2.f90 -quiet -dumpbase
actual_array_constructor_2.f90 -mcpu=v7 -auxbase
--- Comment #1 from ghazi at gcc dot gnu dot org 2007-01-07 01:22 ---
The failure for actual_array_constructor_2.f90 looks like this:
gfortran.dg/actual_array_constructor_2.f90: In function 'MAIN__':
gfortran.dg/actual_array_constructor_2.f90:10: internal compiler
nedTo: unassigned at gcc dot gnu dot org
ReportedBy: ghazi at gcc dot gnu dot org
GCC target triplet: sparc-sun-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30399
--- Comment #6 from ghazi at gcc dot gnu dot org 2007-01-06 16:05 ---
sparc-sun-solaris2.10 issue appears to be fixed.
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00470.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30311
--- Comment #3 from ghazi at gcc dot gnu dot org 2006-12-29 04:45 ---
I think the first step is to report it to sun so they track it and hopefully
one day fix their toolchain. Does anyone have a support contract who can file
a report?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #3 from ghazi at gcc dot gnu dot org 2006-12-29 04:45 ---
I think the first step is to report it to sun so they track it and hopefully
one day fix their toolchain. Does anyone have a support contract who can file
a report?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #4 from ghazi at gcc dot gnu dot org 2006-12-29 04:36 ---
A similar error that may be related was posted here:
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01713.html
The testcase in my post was from a gcc bootstrap.
--
ghazi at gcc dot gnu dot org changed
--- Comment #37 from ghazi at gcc dot gnu dot org 2006-12-26 19:13 ---
Done.
Remaining functions (Bessel & lgamma) await implementation in MPFR and marked
for PR30250 & PR30251.
--
ghazi at gcc dot gnu dot org changed:
What|Removed
--- Comment #36 from ghazi at gcc dot gnu dot org 2006-12-26 19:03 ---
Subject: Bug 29335
Author: ghazi
Date: Tue Dec 26 19:03:17 2006
New Revision: 120211
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120211
Log:
PR middle-end/29335
* builtins.c (do_m
tedBy: ghazi at gcc dot gnu dot org
BugsThisDependsOn: 29335
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30251
--- Comment #35 from ghazi at gcc dot gnu dot org 2006-12-18 14:53 ---
Mine, obviously.
Almost done, targetted to gcc-4.3.
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
dot gnu dot org
ReportedBy: ghazi at gcc dot gnu dot org
BugsThisDependsOn: 29335
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30250
--- Comment #1 from ghazi at gcc dot gnu dot org 2006-11-26 14:03 ---
Is this a known bug or do we need to report it to Sun?
If known, is there a patch we can recommend in the Solaris-specific
installation docs?
--
ghazi at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from ghazi at gcc dot gnu dot org 2006-11-26 14:02 ---
Is this a known bug or do we need to report it to Sun?
If known, is there a patch we can recommend in the Solaris-specific
installation docs?
--
ghazi at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from ghazi at gcc dot gnu dot org 2006-11-16 03:14 ---
Not a bug, see:
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01127.html
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from ghazi at gcc dot gnu dot org 2006-11-16 00:41 ---
Another manifestation and (presumably nonportable) workaround:
http://gcc.gnu.org/ml/gcc/2006-11/msg00095.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21547
--- Comment #6 from ghazi at gcc dot gnu dot org 2006-11-16 00:13 ---
This issue may have more impact now that we're using GMP/MPFR for all languages
via the middle-end. IMHO, the link step for cc1 et al. should prefer the
static libs over the shared ones, if they exist. Not su
--- Comment #34 from ghazi at gcc dot gnu dot org 2006-11-07 02:46 ---
(In reply to comment #33)
> > Okay, sounds fine. Would this make it into 2.2.1 or 2.3?
> For compatibility reasons (i.e. the 2.2.x versions must have the same
> interface), this can only be in 2.3.0.
&g
--- Comment #32 from ghazi at gcc dot gnu dot org 2006-11-02 22:44 ---
(In reply to comment #31)
> (In reply to comment #30)
> So, I don't think a mpfr_signgam alone would really be useful. So, I think
> that
> choice 2 would be better.
Okay, sounds fine. Would
--- Comment #30 from ghazi at gcc dot gnu dot org 2006-11-02 14:41 ---
(In reply to comment #28)
> (In reply to comment #27)
> > It's likely that I'll end up doing it, so would you please tell me how?
> According to the C rationale (I haven't checked), the s
--- Comment #29 from ghazi at gcc dot gnu dot org 2006-11-02 03:21 ---
Subject: Bug 29335
Author: ghazi
Date: Thu Nov 2 03:20:49 2006
New Revision: 118409
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118409
Log:
PR middle-end/29335
* bu
--- Comment #27 from ghazi at gcc dot gnu dot org 2006-10-31 20:08 ---
(In reply to comment #26)
> Yes, it's true that it is useful to have this value. But determining it
> separately is quite easy, without taking a noticeable additional time in
> average.
It's like
--- Comment #25 from ghazi at gcc dot gnu dot org 2006-10-31 03:14 ---
(In reply to comment #18)
> (In reply to comment #17)
> This is because MPFR defines
> lngamma as log(gamma(x)) while the C standard defines it as log|gamma(x)|. I
> wonder if this should be regarded as a
--- Comment #24 from ghazi at gcc dot gnu dot org 2006-10-30 20:22 ---
Subject: Bug 29335
Author: ghazi
Date: Mon Oct 30 20:21:59 2006
New Revision: 118200
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118200
Log:
PR middle-end/29335
* bu
--- Comment #23 from ghazi at gcc dot gnu dot org 2006-10-29 02:02 ---
Subject: Bug 29335
Author: ghazi
Date: Sun Oct 29 02:02:10 2006
New Revision: 118129
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118129
Log:
PR middle-end/29335
* builtins.c (do_m
--- Comment #21 from ghazi at gcc dot gnu dot org 2006-10-28 16:03 ---
(In reply to comment #20)
> I agree. And I think that none of the MPFR developers were aware of this
> problem (I didn't notice the difference when I was looking for C functions
> that were missing in
--- Comment #19 from ghazi at gcc dot gnu dot org 2006-10-28 13:28 ---
(In reply to comment #18)
> (In reply to comment #17)
> > Yes, I can reproduce the NaN. In fact, any negative value
> > gives a NaN.
> Not any negative value, but in lngamma.c:
> /* if x <
--- Comment #16 from ghazi at gcc dot gnu dot org 2006-10-28 03:20 ---
I'm getting wierd NaN results when I hook up __builtin_lgamma to mpfr_lngamma.
I can expose the problem using a standlone C program calling mpfr like so.
Results are first, C testcase is second. Now I know l
--- Comment #37 from ghazi at gcc dot gnu dot org 2006-10-26 00:59 ---
A request for this optimization made by Bruce in Sept 2000. :-)
http://gcc.gnu.org/ml/gcc-patches/2000-09/msg00877.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21982
--- Comment #15 from ghazi at gcc dot gnu dot org 2006-10-25 20:44 ---
Subject: Bug 29335
Author: ghazi
Date: Wed Oct 25 20:44:09 2006
New Revision: 118042
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118042
Log:
PR middle-end/29335
* bu
--- Comment #14 from ghazi at gcc dot gnu dot org 2006-10-24 17:44 ---
Subject: Bug 29335
Author: ghazi
Date: Tue Oct 24 17:44:36 2006
New Revision: 118009
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118009
Log:
PR middle-end/29335
* bu
301 - 400 of 633 matches
Mail list logo
