--- Comment #15 from ghazi at gcc dot gnu dot org 2008-05-19 06:16 ---
Addressed this by adding __builtin_isinf_sign()
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ghazi at gcc dot gnu dot org
|dot org
--- Comment #16 from ghazi at gcc dot gnu dot org 2008-05-19 06:19 ---
Fixed in 4.4.0 by adding a new builtin for systems that care about the sign of
isinf's return value. E.g. do this:
#define isinf(x) __builtin_isinf_sign(x)
--
ghazi at gcc dot gnu dot org ch
--- Comment #26 from ghazi at gcc dot gnu dot org 2008-05-25 17:29 ---
I also get this failure on x86 when using ilp32 && pic. See:
x86_64: http://gcc.gnu.org/ml/gcc-testresults/2008-05/msg02221.html
i686: http://gcc.gnu.org/ml/gcc-testresults/2008-05/msg01800.html
--
ghaz
--- Comment #1 from ghazi at gcc dot gnu dot org 2008-05-25 17:31 ---
I also get this failure on x86 when using ilp32 && pic. See:
x86_64: http://gcc.gnu.org/ml/gcc-testresults/2008-05/msg02221.html
i686: http://gcc.gnu.org/ml/gcc-testresults/2008-05/msg01800.html
--
ghaz
--- Comment #6 from ghazi at gcc dot gnu dot org 2008-05-25 18:03 ---
The testcase also fails for me on x86_64-unknown-linux-gnu or
i686-unknown-linux-gnu but requires -fpic/-fPIC to trigger. (That may explain
the darwin x86 error.) See:
x86_64: http://gcc.gnu.org/ml/gcc-testresults
--- Comment #10 from ghazi at gcc dot gnu dot org 2008-05-25 18:08 ---
I see the failure with x86_64 -m32 or native i686 on the trunk:
x86_64: http://gcc.gnu.org/ml/gcc-testresults/2008-05/msg02221.html
i686: http://gcc.gnu.org/ml/gcc-testresults/2008-05/msg01800.html
--
ghazi at
--- Comment #10 from ghazi at gcc dot gnu dot org 2008-05-25 18:13 ---
Failure also occurs on x86_64-unknown-linux-gnu and i686-unknown-linux-gnu,
see:
x86_64: http://gcc.gnu.org/ml/gcc-testresults/2008-05/msg02221.html
i686: http://gcc.gnu.org/ml/gcc-testresults/2008-05/msg01800.html
--- Comment #11 from ghazi at gcc dot gnu dot org 2008-06-07 04:02 ---
What remains to be done for this PR?
The generic FP classification implementations are all done, including builtin
fpclassify(). Perhaps some optabs still need to be finished? Or can we close
this one
--- Comment #6 from ghazi at gcc dot gnu dot org 2008-06-19 08:03 ---
Manuel - "quick and dirty" list got posted here:
http://gcc.gnu.org/ml/gcc/2008-06/msg00412.html
I think #3 & #4 are implemented, #1 & #2 remain. There might be others of
course.
--
ghazi at g
--- Comment #1 from ghazi at gcc dot gnu dot org 2008-06-23 17:50 ---
Patches to fix these problems in c-common.c/tree.c were posted here:
http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00687.html
http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00858.html
--
ghazi at gcc dot gnu dot org
--- Comment #4 from ghazi at gcc dot gnu dot org 2008-06-26 20:51 ---
This is a valid feature request...
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from ghazi at gcc dot gnu dot org 2008-06-26 20:52 ---
but it is a dup...
*** This bug has been marked as a duplicate of 18624 ***
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from ghazi at gcc dot gnu dot org 2008-06-26 20:52 ---
*** Bug 16517 has been marked as a duplicate of this bug. ***
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from ghazi at gcc dot gnu dot org 2008-06-29 17:50 ---
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01890.html
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from ghazi at gcc dot gnu dot org 2008-07-06 22:22 ---
Another C/C++ conflict (?) that could be possibly implemented in this warning
feature, enum declaration scoping:
http://gcc.gnu.org/ml/gcc-patches/2008-07/msg00470.html
Not sure what the exact error message was
--- Comment #3 from ghazi at gcc dot gnu dot org 2008-07-15 00:59 ---
Also occurs on x86_64-unknown-linux-gnu and i686-unknown-linux-gnu:
http://gcc.gnu.org/ml/gcc-testresults/2008-07/msg01321.html
http://gcc.gnu.org/ml/gcc-testresults/2008-07/msg01323.html
--
ghazi at gcc dot gnu
--- Comment #3 from ghazi at gcc dot gnu dot org 2008-07-15 01:06 ---
Fixed.
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
CC|ghazi at
--- Comment #8 from ghazi at gcc dot gnu dot org 2006-02-06 13:49 ---
Subject: Bug 13906
Author: ghazi
Date: Mon Feb 6 13:49:41 2006
New Revision: 110642
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110642
Log:
include:
Backport:
2006-01-18 DJ
--- Comment #9 from ghazi at gcc dot gnu dot org 2006-02-06 14:06 ---
Subject: Bug 13906
Author: ghazi
Date: Mon Feb 6 14:06:55 2006
New Revision: 110643
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110643
Log:
include:
Backport:
2006-01-18 DJ
--- Comment #10 from ghazi at gcc dot gnu dot org 2006-02-06 14:07 ---
Fix backported to 3.4 and 4.0.
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from ghazi at gcc dot gnu dot org 2006-02-14 01:51 ---
Subject: Bug 24901
Author: ghazi
Date: Tue Feb 14 01:51:28 2006
New Revision: 110952
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110952
Log:
Backport:
2006-02-01 Steve Ellcey
--- Comment #6 from ghazi at gcc dot gnu dot org 2006-02-14 01:59 ---
Subject: Bug 24901
Author: ghazi
Date: Tue Feb 14 01:59:16 2006
New Revision: 110953
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110953
Log:
Backport:
2006-02-01 Steve Ellcey
--- Comment #7 from ghazi at gcc dot gnu dot org 2006-02-14 02:04 ---
Also affects sparc64-sun-solaris2.10, backported to 4.0 and 3.4.
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from ghazi at gcc dot gnu dot org 2006-02-16 02:51 ---
Still have the address of labels failure on 4.0, 4.1 and mainline:
http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg00383.html
http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg00431.html
http://gcc.gnu.org/ml/gcc
--- Comment #7 from ghazi at gcc dot gnu dot org 2006-02-17 23:49 ---
Subject: Bug 16045
Author: ghazi
Date: Fri Feb 17 23:49:13 2006
New Revision: 111215
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111215
Log:
Backport:
2005-08-18 Andrew Pinski
--- Comment #8 from ghazi at gcc dot gnu dot org 2006-02-17 23:50 ---
Backported to 4.0.
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
CC
--- Comment #7 from ghazi at gcc dot gnu dot org 2006-02-21 13:34 ---
Subject: Bug 21583
Author: ghazi
Date: Tue Feb 21 13:34:23 2006
New Revision: 111333
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111333
Log:
PR c++/21583
Backport:
20
--- Comment #8 from ghazi at gcc dot gnu dot org 2006-02-21 13:40 ---
This issue was fixed by backporting the 4.0 version of the testcase. The
update to the testcase necessary for ia64-hpux is on mainline/4.1 and is not
included in this fix. However it is tracked in PR 19888 in case
--- Comment #10 from ghazi at gcc dot gnu dot org 2006-02-21 13:59 ---
4.0 results are now on par with 4.1, meaning AFAICS we only have the address of
labels problem to worry about on all 4.* branches.
http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg00986.html
--
http
read (iunit, rec=1) string
close (iunit)
if (string.ne.'ABCD') call abort
end
--
Summary: gfortran.dg/pr16597.f90 leaves behind a file
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
--- Comment #19 from ghazi at gcc dot gnu dot org 2006-03-31 13:51 ---
Of the 3 workarounds in comment #17, bootstrap with Sun cc doesn't work because
of PR 18058 (although there is a patch posted for that PR). Also bootstrap
with GCC 2.x or 3.x isn't quite right since I t
--- Comment #21 from ghazi at gcc dot gnu dot org 2006-03-31 14:29 ---
(In reply to comment #20)
> It's the wrong PR, this one is for pre-4.2, the 3 workarounds work.
> The problem is minor for pre-4.2. The blocker PR for 4.2 is PR other/26507.
Huh? The third comment in 26
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ghazi at gcc
--- Additional Comments From ghazi at gcc dot gnu dot org 2005-04-28 13:11
---
Roger Sayle provided this feedback to me in private email and agreed to have it
copied here:
--
I've glanced through the code and I susp
s
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ghazi at gcc dot gnu d
Version: 4.0.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ghazi at gcc dot gnu dot org
CC: gcc-bugs at gcc dot g
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ghazi at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED
--
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21911
--- Additional Comments From ghazi at gcc dot gnu dot org 2005-06-06 18:41
---
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00507.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21911
--- Additional Comments From ghazi at gcc dot gnu dot org 2005-06-09 16:49
---
(In reply to comment #4)
> (In reply to comment #1)
> > If side effects appear in the arguments, that also would be a problem, e.g.:
> >
> > printf("%d", i++);
> > prin
--- Additional Comments From ghazi at gcc dot gnu dot org 2005-06-09 16:55
---
(In reply to comment #3)
> Subject: Re: GCC should combine adjacent stdio
> calls
> Another problem case is if the first format has excess arguments (which is
> permitted by ISO C) - those ar
--- Additional Comments From ghazi at gcc dot gnu dot org 2005-06-09 17:02
---
(In reply to comment #10)
> Subject: Re: GCC should combine adjacent stdio calls
> But remember that we are not optimizing C, we are optimizing
> GIMPLE. And in GIMPLE we don't have those pro
--- Additional Comments From ghazi at gcc dot gnu dot org 2005-06-09 17:21
---
(In reply to comment #14)
> Subject: Re: GCC should combine adjacent stdio
> calls
> On Thu, 9 Jun 2005, ghazi at gcc dot gnu dot org wrote:
> >
> > --- Additional Comments From
d printf("foo")
into fputs(foo,stdout)
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
--- Additional Comments From ghazi at gcc dot gnu dot org 2005-06-09 19:48
---
(In reply to comment #19)
> Subject: Re: GCC should combine adjacent stdio calls
> On Thu, Jun 09, 2005 at 07:29:42PM -, joseph at codesourcery dot com
wrote:
> > that function on th
--- Additional Comments From ghazi at gcc dot gnu dot org 2005-06-10 01:20
---
(In reply to comment #22)
> Subject: Re: GCC should combine adjacent stdio calls
> On Thu, Jun 09, 2005 at 07:52:42PM -, joseph at codesourcery dot com
wrote:
> > (a) It could be stdio&#
--- Additional Comments From ghazi at gcc dot gnu dot org 2005-06-10 12:42
---
(In reply to comment #25)
> Subject: Re: GCC should combine adjacent stdio
> calls
> On Fri, 10 Jun 2005, ghazi at gcc dot gnu dot org wrote:
> POSIX defines how streams and file descriptors
--- Additional Comments From ghazi at gcc dot gnu dot org 2005-06-10 12:55
---
(In reply to comment #25)
> Subject: Re: GCC should combine adjacent stdio
> calls
> On Fri, 10 Jun 2005, ghazi at gcc dot gnu dot org wrote:
> > Case (b) involves fmemopen, and I assume you
--- Additional Comments From ghazi at gcc dot gnu dot org 2005-06-10 14:22
---
(In reply to comment #30)
> Subject: Re: GCC should combine adjacent stdio calls
> On Fri, Jun 10, 2005 at 01:49:54PM -, joseph at codesourcery dot com
wrote:
> > Not that I really see th
--- Additional Comments From ghazi at gcc dot gnu dot org 2005-06-10 15:05
---
(In reply to comment #33)
> Subject: Re: GCC should combine adjacent stdio
> calls
> On Fri, 10 Jun 2005, ghazi at gcc dot gnu dot org wrote:
> Since putc and puts are typically faster than
#x27;t see these failures with 3.3.x so it's a
regression.
--
Summary: [3.4 regression] RTL checking failures on i686-pc-linux-
gnu
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Componen
: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ghazi at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet
us: UNCONFIRMED
Severity: normal
Priority: P2
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ghazi at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-p
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ghazi at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
G
ion: 3.3.6
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ghazi at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc
es.c when using -fpic/-fPIC on
i686-pc-linux-gnu
Product: gcc
Version: 3.3.6
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ghazi at gcc dot
es.c when using -fpic/-fPIC on
i686-pc-linux-gnu
Product: gcc
Version: 3.3.6
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ghazi at gcc dot
--- Additional Comments From ghazi at gcc dot gnu dot org 2005-01-02 17:58
---
*** Bug 19230 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19229
--- Additional Comments From ghazi at gcc dot gnu dot org 2005-01-02 17:58
---
*** This bug has been marked as a duplicate of 19229 ***
--
What|Removed |Added
: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ghazi at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ghazi at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux
--- Additional Comments From ghazi at gcc dot gnu dot org 2005-01-04 00:39
---
Okay thanks, I've backported the testcase to 3.3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19229
ry: [4.0 regression] execute/921215-1.c fails with -fpic at
-O3 -g
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: debug
AssignedTo: unassigned at gcc dot gnu dot or
--- Additional Comments From ghazi at gcc dot gnu dot org 2005-01-05 16:38
---
Patch submitted here.
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00284.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19226
--- Additional Comments From ghazi at gcc dot gnu dot org 2005-01-05 19:06
---
Patch submitted here:
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00296.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19228
clobbered in 'asm'
--
Summary: [3.4/4.0 regression] gcc.dg/20020919-1.c fails with -
fpic/-fPIC on i686-pc-linux-gnu
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Compone
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ghazi at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-
--- Additional Comments From ghazi at gcc dot gnu dot org 2005-01-05 21:42
---
Is it a bug that 3.3 compiles it without a problem?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19275
--- Additional Comments From ghazi at gcc dot gnu dot org 2005-01-06 02:37
---
Installed on mainline, waiting for dg-skip-if before propagating to branches.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19226
--- Additional Comments From ghazi at gcc dot gnu dot org 2005-01-06 02:37
---
Installed on mainline, waiting for dg-skip-if before propagating to branches.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19228
3.4] RTL checking failure in gcc.dg/titype-1.c
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ghazi at gcc dot
--- Additional Comments From ghazi at gcc dot gnu dot org 2005-02-06 18:08
---
If you want to compare how the memory footprint has affected performance, use
these flags in 3.3 and later:
--param ggc-min-expand=30 --param ggc-min-heapsize=4096
Those are the hardcoded values that 3.2
--- Comment #13 from ghazi at gcc dot gnu dot org 2006-10-23 20:25 ---
Subject: Bug 29335
Author: ghazi
Date: Mon Oct 23 20:24:55 2006
New Revision: 117983
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117983
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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
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 #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
tedBy: ghazi at gcc dot gnu dot org
BugsThisDependsOn: 29335
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30251
--- 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
--- 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 #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 #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
501 - 600 of 633 matches
Mail list logo
