--- Comment #11 from roger at eyesopen dot com 2006-09-06 15:27 ---
Hmm, yep I guess it was caused my change, most probably this part of it:
* tree.c (build_constructor_single): Mark a CONSTRUCTOR as constant,
if all of its elements/components are constant
--- Comment #12 from roger at eyesopen dot com 2006-09-06 15:36 ---
Here's the .102t.final_cleanup
;; Function f (f)
f ()
{
int D.1524;
int D.1522;
int D.1520;
int t.0;
bb 2:
t.0 = (int) t;
D.1520 = (int) t[1];
D.1522 = (int) t[2];
D.1524 = (int) t[3];
return {t.0
--- Comment #7 from roger at eyesopen dot com 2006-09-11 16:36 ---
Patch posted here: http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00406.html
--
roger at eyesopen dot com changed:
What|Removed |Added
--- Comment #6 from roger at eyesopen dot com 2006-09-11 16:52 ---
I believe I have a patch. I'm just waiting for the fix for PR28672 (which I've
just approved) to be applied, so I can complete bootstrap and regression test
to confirm there are no unexpected side-effects.
--
roger
--- Comment #1 from roger at eyesopen dot com 2006-09-18 21:27 ---
Hi David,
I was wondering if you have a MIPS tree handy, whether you could easily
test the following single line patch:
Index: dwarf2out.c
--- Comment #16 from roger at eyesopen dot com 2006-09-22 15:40 ---
Fixed everywhere. Eric even has an improved patch/fix for mainline, but the
backports of this change are sufficient to resolve the current PR. Thanks
to Steven for coming up with the solution.
--
roger at eyesopen
--- Comment #7 from roger at eyesopen dot com 2006-09-22 16:51 ---
Fixed on mainline (confirmed on mips-sgi-irix6.5). It'll take another day or
two to backport to the 4.1 branch, as bootstrap and regtest on MIPS takes a
while.
--
roger at eyesopen dot com changed:
What
--- Comment #9 from roger at eyesopen dot com 2006-11-10 18:33 ---
Thanks Paolo! Your machine must be faster than mine. My bootstrap and
regression test against the 4.2 branch has only just finished. :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29726
--- Comment #13 from roger at eyesopen dot com 2006-11-10 19:41 ---
Grr. Yep, Michael's BITS_BIG_ENDIAN test looks to be the correct thing. The
effect of BITS_BIG_ENDIAN on sign_extract and zero_extract is documented in
rtl.texi. Is anyone bootstrapping and regression testing
--- Comment #16 from roger at eyesopen dot com 2006-11-11 02:19 ---
A patch was posted by Jason, here
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00566.html
--
roger at eyesopen dot com changed:
What|Removed |Added
--- Additional Comments From roger at eyesopen dot com 2005-02-16 19:17
---
Hmm. I don't think the problem in this case is at the tree-level, where I think
keeping X-(Y*C) and -(Y*C) as a more canonical X + (Y*C') and Y*C' should help
with reassociation and other tree-ssa optimizations
--- Additional Comments From roger at eyesopen dot com 2005-02-19 05:41
---
Re: comment #5
For floating point expressions, -(A+B) is only transformed into (-A)-B or
(-B)-A when the user explicitly specifies -ffast-math, i.e. only when
flag_unsafe_math_optimizations is true.
Re: comment
--- Additional Comments From roger at eyesopen dot com 2005-02-19 19:56
---
This bug has now been fixed for gcc 4.0. For the testcase attached to the PR,
mainline now generates the following code on sparc-sun-solaris2.8 with -O2:
fun:ld [%sp+64], %o5
sll %o0, 2
--
Bug 19466 depends on bug 336, which changed state.
Bug 336 Summary: Superfluous instructions generated from bit-field operations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=336
What|Old Value |New Value
--- Additional Comments From roger at eyesopen dot com 2005-03-09 01:28
---
Subject: Re: [3.3/3.4/4.0/4.1 Regression] Wrong warning about
returning a reference to a temporary
On 8 Mar 2005, Alexandre Oliva wrote:
* fold-const.c (non_lvalue): Split tests
--- Additional Comments From roger at eyesopen dot com 2005-03-09 16:13
---
Subject: Re: [PR middle-end/18628] do not fold to label load from tablejump
to reg
On 9 Mar 2005, Alexandre Oliva wrote:
This patch is meant to implement suggestion #3 proposed to fix the bug
by Roger Sayle
--- Additional Comments From roger at eyesopen dot com 2005-03-17 05:06
---
Hmm, yep, probably caused by my change.
It looks like with my change fold_widened_comparison is now converting
(int)t == -1 into the equivalent t == (typeof(t))-1. Normally, this
would be reasonable
--- Additional Comments From roger at eyesopen dot com 2005-03-20 16:47
---
Patch here http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01871.html
--
What|Removed |Added
--- Additional Comments From roger at eyesopen dot com 2005-03-25 06:03
---
Splitting non_value into maybe_lvalue_p is a good thing, is totally safe and is
preapproved for both mainline and the 4.0 branch. The remaining change to
fold_ternary/fold_cond_expr_with_comparison are more
--- Additional Comments From roger at eyesopen dot com 2005-04-03 03:20
---
Excuse me for asking, but what is it that makes the latest patch I posted not
reasonable for the 4.0 timeframe?
The performance regression on C, Java, Ada and fortran code, that isn't affected
by this bug
--- Additional Comments From roger at eyesopen dot com 2005-04-04 16:02
---
Subject: Re: [Committed] PR c++/19199: Preserve COND_EXPR lvalueness in fold
Hi Alex,
My apologies yet again for not being more explicit about all of the
things that were wrong (and or I was unhappy
--- Additional Comments From roger at eyesopen dot com 2005-04-05 04:22
---
The stricter version is mostly OK, except for one correction and one suggestion.
The correction is that in the case where the replacement wasn't a register, you
shouldn't be calling
--- Additional Comments From roger at eyesopen dot com 2005-04-05 23:13
---
Now that a fix has been applied to both mainline and the 4.0 branch, I've been
investigating backporting the fix to 3.4. Unfortunately, a significant feature
of the fixes proposed by Alex and me
--- Additional Comments From roger at eyesopen dot com 2005-04-06 00:03
---
That's my interpretation of (Andrew Pinki's) comment #6 in the bugzilla PR
[n.b. I haven't reconfirmed his analysis personally]
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19199
--- Additional Comments From roger at eyesopen dot com 2005-04-08 17:03
---
Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail
Hi Alex,
On 8 Apr 2005, Alexandre Oliva wrote:
Roger suggested some changes in the patch. I've finally completed
bootstrap
--- Additional Comments From roger at eyesopen dot com 2005-04-10 03:18
---
Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail
On 9 Apr 2005, Alexandre Oliva wrote:
On Apr 8, 2005, Roger Sayle [EMAIL PROTECTED] wrote:
++ /* If there isn't a volatile
--- Additional Comments From roger at eyesopen dot com 2005-04-12 14:38
---
Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail
Hi Alexandre,
On 12 Apr 2005, Alexandre Oliva wrote:
Does any expert in rtl loop care to chime in?
I'm not sure I qualify
--- Additional Comments From roger at eyesopen dot com 2005-04-14 17:19
---
Thanks Alex! This is OK for mainline.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20739
--- Additional Comments From roger at eyesopen dot com 2005-04-14 17:37
---
You'll notice in loop.c that everywhere that we currently set all_reduced to
zero, we also set ignore to true. This change is to avoid wasting CPU cycles,
if we know that an IV can't be eliminated, there's
--- Additional Comments From roger at eyesopen dot com 2005-04-15 14:52
---
Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail
On 15 Apr 2005, Alexandre Oliva wrote:
On Apr 12, 2005, Roger Sayle [EMAIL PROTECTED] wrote:
I still like your fallbacks
--- Additional Comments From roger at eyesopen dot com 2005-04-17 00:21
---
Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail
Hi Alex,
On 16 Apr 2005, Alexandre Oliva wrote:
On Apr 15, 2005, Roger Sayle [EMAIL PROTECTED] wrote:
I agree with your proposed
--- Additional Comments From roger at eyesopen dot com 2005-04-17 03:06
---
Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail
On 16 Apr 2005, Alexandre Oliva wrote:
On Apr 16, 2005, Roger Sayle [EMAIL PROTECTED] wrote:
Does this clear things up? Do you
--- Additional Comments From roger at eyesopen dot com 2005-04-18 20:47
---
Wow, that was fast. I'd just started bootstrap and regression test on an
*identical* patch, and pulled up the PR to assign it to myself. You win!
I'll preapprove yours, together with the testcase from the PR
--- Additional Comments From roger at eyesopen dot com 2005-04-23 14:49
---
The list of exceptions, in addition to those mentioned in the e-mail above, also
needs to include compare, if_then_else and all binary comparison operators; eq,
ne, lt, gt, le, ge.
I'm not opposed to adding
--- Additional Comments From roger at eyesopen dot com 2005-04-23 16:24
---
This is actually a C++ front-end bug. It looks like on the 3.4 branch
ocp_convert is calling fold instead of fold_if_not_in_template (which
is what happens on mainline). This call to fold triggers a chain
--- Additional Comments From roger at eyesopen dot com 2005-04-23 16:56
---
Doh, fold_if_not_in_template is not on the gcc 3.4 branch. It was introduced
to fix (workaround?) PR c++/17642, which looks too intrusive for the 3.4 branch.
Instead, the C++ mistake on the 3.4 branch, that's
--- Additional Comments From roger at eyesopen dot com 2005-04-23 16:57
---
Don't know what happened there; this should be component c++!
--
What|Removed |Added
-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: roger at eyesopen dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: powerpc-ibm-aix5.2.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21305
--- Additional Comments From roger at eyesopen dot com 2005-04-30 21:18
---
Apparently the behaviour of this code is undefined in the C/C++ language
standards, though this transformation is performed in front-end independent
code. Perhaps its only a quality of implementation issue
--- Additional Comments From roger at eyesopen dot com 2005-05-22 19:25
---
I posted a patch here: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01956.html
to implement this in the RTL optimizers. Better to get it linked to the PR,
than slip through the cracks. The proposed change
--- Additional Comments From roger at eyesopen dot com 2005-05-26 06:11
---
This should now be fixed on the gcc-3_4-branch (and the same patch has been
applied to mainline to prevent this ever causing problems in future).
--
What|Removed |Added
--- Additional Comments From roger at eyesopen dot com 2005-05-27 02:55
---
This optimization is now performed at the RTL-level, but it would be nice if
this (and several other of ifcvt.c's noce_try_foo optimizations) could be
caught earlier during tree-ssa.
--
What
--- Additional Comments From roger at eyesopen dot com 2005-05-30 20:05
---
This should now be fixed on mainline.
--
What|Removed |Added
Status|NEW
--- Additional Comments From roger at eyesopen dot com 2005-06-06 15:06
---
C front-end patch here: http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00369.html
--
What|Removed |Added
--- Additional Comments From roger at eyesopen dot com 2005-06-17 17:22
---
Unfortunately, the AIX 5.1 machine that was loaned to OpenEye by IBM has had to
be returned since this patch was submitted/applied in 2003. So my only guess is
that this may have been a patch level issue
--- Additional Comments From roger at eyesopen dot com 2005-06-18 23:26
---
My apologies for not knowing this had a PR. Here's the proposed solution
that I sent to Fariborz and Dale for testing.
Index: combine.c
===
RCS
--- Additional Comments From roger at eyesopen dot com 2005-06-19 01:49
---
A revised patch, allowing equality and inequality comparisons against NULL, yet
retaining warnings for things like 'if (foo 0)' and 'if (foo == bar)'
was posted here: http://gcc.gnu.org/ml/gcc-patches/2005-06
: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: roger at eyesopen dot com
GCC host triplet: alpha*-*-osf*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26161
--- Comment #2 from roger at eyesopen dot com 2006-02-07 21:15 ---
I've discovered your bootstrap failure is PR16787. It'll take a while for me
to try out your XCFLAGS fix on my slow machine. I'll also propose a fix for
PR16787.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #3 from roger at eyesopen dot com 2006-02-08 04:04 ---
Subject: Re: Configure tests for pthread.h sometimes
need to use -pthread
On 7 Feb 2006, fxcoudert at gcc dot gnu dot org wrote:
I tried to give it a look on alphaev68-dec-osf5.1b, but I couldn't
get to the point
--- Comment #4 from roger at eyesopen dot com 2006-02-08 17:46 ---
This problem affects both hppa*-hp-hpux* and ia64-hp-hpux*. It appears that
the required sem_init, sem_wait, sem_post, etc... symbols are defined both in
the -lrt libraries on HPUX and in the -lc_r libraries. The fix
--- Comment #10 from roger at eyesopen dot com 2006-02-09 14:41 ---
Hi David, nm $objdir/gcc/libgcc.a contains both __ctzdi2 and __ctzti2 for me.
grasp% nm libgcc.a | grep ctz
_ctzsi2.o:
T __ctzdi2
_ctzdi2.o:
T __ctzti2
The post-commit bootstrap and regression test
--- Comment #11 from roger at eyesopen dot com 2006-02-09 14:54 ---
p.s. I can also confirm that this patch fixes the test case in PR25028 for me
on mips-sgi-irix6.5. This failed previously with undefined references to
__floattisf and __floattidf, but now not only compiles and links
--- Comment #4 from roger at eyesopen dot com 2006-02-09 15:00 ---
My recent fix for PR target/22209 adding TImode support for MIPS, just fixed
this
PR's testcase for me on mips-sgi-irix6.5. The new fix*.c and float*.c source
files may be useful in resolving the remaining PR25028 issue
--- Comment #9 from roger at eyesopen dot com 2006-02-13 18:51 ---
This has now been fixed on mainline.
--
roger at eyesopen dot com changed:
What|Removed |Added
--- Comment #7 from roger at eyesopen dot com 2006-02-13 19:02 ---
This has now been fixed on mainline.
--
roger at eyesopen dot com changed:
What|Removed |Added
--- Comment #4 from roger at eyesopen dot com 2006-02-14 03:07 ---
This has now been fixed on mainline.
--
roger at eyesopen dot com changed:
What|Removed |Added
--- Comment #10 from roger at eyesopen dot com 2006-02-20 03:11 ---
Analyzing the code in comment #5, this looks like a bad interaction between
ivopts and vrp. Either of -fno-ivopts or -fno-tree-vrp cures the problem.
But it looks like the output of .084t.ivopts is reasonable
--- Comment #11 from roger at eyesopen dot com 2006-02-20 03:52 ---
Hmmm. Looks like the problem is in .088t.vrp2
We have
unsigned int D.1981;
unsigned int D.1982;
D.1982_9 = -D.1981_1;
D.1981_1: [0, +INF] EQUIVALENCES: { } (0 elements)
D.1982_9: [0, 1] EQUIVALENCES: { } (0
--- Comment #13 from roger at eyesopen dot com 2006-02-20 04:10 ---
Many thanks to Mark, Richard and David! This is now fixed on both mainline and
the gcc-4_1-branch in time for the 4.1 release. On mips-sgi-irix6.5, for the
4.1 branch I now see the following (which is much better than
--- Comment #3 from roger at eyesopen dot com 2006-02-20 15:05 ---
Fixed on mainline.
--
roger at eyesopen dot com changed:
What|Removed |Added
Status
--- Comment #21 from roger at eyesopen dot com 2006-02-20 21:07 ---
Created an attachment (id=10881)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10881action=view)
patch
I believe the following patch should resolve the problem. Bootstrap and
regression test in progress
--- Comment #22 from roger at eyesopen dot com 2006-02-20 21:33 ---
Created an attachment (id=10882)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10882action=view)
revised patch
Doh! Although the previous attachment contained the necessary logic, it had
a few typos which
--- Comment #23 from roger at eyesopen dot com 2006-02-20 21:37 ---
Created an attachment (id=10883)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10883action=view)
really revised patch
Grrr! The previous attachment was identical to the original. Third times a
charm (or I'll
--- Comment #3 from roger at eyesopen dot com 2006-02-24 19:37 ---
This has now been fixed on mainline.
--
roger at eyesopen dot com changed:
What|Removed |Added
--- Comment #7 from roger at eyesopen dot com 2006-02-25 23:36 ---
Fixed on mainline.
--
roger at eyesopen dot com changed:
What|Removed |Added
Status|NEW
--- Comment #2 from roger at eyesopen dot com 2006-02-26 15:00 ---
I've posted a proposed solution to gcc-patches:
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01909.html
--
roger at eyesopen dot com changed:
What|Removed |Added
--- Comment #8 from roger at eyesopen dot com 2006-02-26 18:39 ---
Fixed on mainline. I'm still investiating some related optimizations.
--
roger at eyesopen dot com changed:
What|Removed |Added
--- Comment #9 from roger at eyesopen dot com 2006-02-28 02:07 ---
Created an attachment (id=10932)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10932action=view)
patch
I think this untested patch might fix things.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26489
--- Comment #11 from roger at eyesopen dot com 2006-02-28 03:23 ---
Created an attachment (id=10934)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10934action=view)
mainline patch v2
Here is a revised and slightly more tested version of the proposed patch for
mainline. The 4.1
--- Comment #12 from roger at eyesopen dot com 2006-02-28 03:30 ---
Hi moof, the way that you can test this patch is to run make -k check from
the top-level after bootstrapping the tree. You'll notice that even before
my change (with RC1 for example), there'll be several thousand
--- Comment #8 from roger at eyesopen dot com 2006-03-02 21:39 ---
I think I've found the problem. On mainline, its in tree-scalar-evolution.c
at around line 1652, where where handle NEGATE_EXPR in
interpret_rhs_modify_expr.
The code checks whether the type is SCALAR_FLOAT_TYPE_P
--- Comment #7 from roger at eyesopen dot com 2006-03-17 00:17 ---
I've now committed this patch (as approved by Mark) to the 4.0 branch for
Jakub, so this PR can be closed.
--
roger at eyesopen dot com changed:
What|Removed |Added
--- Comment #7 from roger at eyesopen dot com 2006-03-28 19:34 ---
This should now be fixed on mainline.
--
roger at eyesopen dot com changed:
What|Removed |Added
--- Comment #2 from roger at eyesopen dot com 2006-03-28 21:46 ---
I believe that this may not be a g++ bug. The wording of the standard is:
[conv.ptr] An null pointer constant is an *integral* constant expression
(_expr.const_) rvalue of integer type that evaluates to zero.
Ignoring
--- Comment #2 from roger at eyesopen dot com 2006-03-30 21:24 ---
This should now be fixed on mainline.
--
roger at eyesopen dot com changed:
What|Removed |Added
--- Comment #3 from roger at eyesopen dot com 2006-03-30 21:35 ---
This is now be fixed on mainline. With -mpowerpc64, we now generate:
_div16:
rldimi 3,4,0,32
srdi 4,3,4
srdi 3,3,36
blr
--
roger at eyesopen dot com changed:
What
--- Comment #3 from roger at eyesopen dot com 2006-03-30 23:01 ---
This has now been fixed on mainline, and I've also checked that the
extra load mentioned in comment #1 is now also resolved.
--
roger at eyesopen dot com changed:
What|Removed
--- Comment #1 from roger at eyesopen dot com 2006-04-02 03:07 ---
Damn. Unfortunately, although I have four different IA-64 boxes, one none
of them can I test Ada. Is it possible to attach the traceback of the
failure to the bugzilla PR? Clearly the fact that y is NULL_RTX
--- Comment #3 from roger at eyesopen dot com 2006-04-02 15:53 ---
Thanks Andreas. Well my prediction that the bogus call wouldn't come from
emit_group_store was wrong. There's now a trivial fix to resolve this PR
which is to add if (temp) tests around the emit_move_insn, done=true
--- Comment #3 from roger at eyesopen dot com 2006-04-07 05:30 ---
This appears to be a problem with instruction attributes in the x86 backend,
and looks to be still present (but latent?) on mainline.
The problem is that i386.c's memory define_attr tries to determine whether
an insn
--- Comment #6 from roger at eyesopen dot com 2006-04-23 21:19 ---
This should now be fixed on mainline. I've confirmed that a cross-compiler
to fr30-elf currently builds newlib without problems.
--
roger at eyesopen dot com changed:
What|Removed
--- Comment #4 from roger at eyesopen dot com 2006-04-23 21:27 ---
This has now been fixed on mainline. I've confirmed that a cross-compiler
to fr30-elf can currently compile all of newlib without problems. If anyone
has an fr30 board or a simulator to check the testsuite that would
--- Comment #6 from roger at eyesopen dot com 2006-04-25 14:09 ---
Paolo's fix looks good to me. The bugzilla PR shows that this is a 4.2
regression, probably due to the more aggressive RTL optimizations on mainline.
So I'll preapprove Paolo's fix for mainline (please post the version
--- Comment #8 from roger at eyesopen dot com 2006-04-25 15:41 ---
Grr. David's patch is also good. Perhaps better if we follow the usual
protocol of posting patches to gcc-patches *after* bootstrap and regression
testing, for review and approval. Posting untested patch fragments
--- Comment #6 from roger at eyesopen dot com 2006-04-26 18:59 ---
This has now been fixed on the 4.1 branch. Unfortunately, its difficult to
determine whether this patch is still needed on the 4.0 branch, or if other
backports are also required, as libiberty and top-level configure
--- Comment #9 from roger at eyesopen dot com 2006-04-30 19:52 ---
This bug is a duplicate of PR17104 which was fixed by Nathan Sidwell in
November 2004. If you read comment #4, you'll notice that the failure of
CSE to handle the rs6000's rs6000_emit_move's zero_extends is identical
--- Comment #9 from roger at eyesopen dot com 2006-04-30 19:52 ---
*** Bug 13335 has been marked as a duplicate of this bug. ***
--
roger at eyesopen dot com changed:
What|Removed |Added
--- Comment #5 from roger at eyesopen dot com 2006-05-02 14:24 ---
This should now be fixed on mainline, thanks to Paul's patch.
--
roger at eyesopen dot com changed:
What|Removed |Added
--- Comment #4 from roger at eyesopen dot com 2006-05-02 14:26 ---
This should now be fixed on mainline by Paul's patch. Thanks.
--
roger at eyesopen dot com changed:
What|Removed |Added
--- Comment #10 from roger at eyesopen dot com 2006-05-04 00:14 ---
This should now be fixed on mainline and all active branches.
--
roger at eyesopen dot com changed:
What|Removed |Added
--- Comment #8 from roger at eyesopen dot com 2006-05-08 15:29 ---
I've now reconfirmed that this has been fixed on the gcc-4_1-branch by
Jakub's backport of Zdenek's patch. Thanks to you both.
--
roger at eyesopen dot com changed:
What|Removed
--- Comment #8 from roger at eyesopen dot com 2006-05-11 17:22 ---
Patch posted here: http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00472.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26600
--- Comment #2 from roger at eyesopen dot com 2006-05-13 18:59 ---
This is the correct documented behaviour. See the section entitled
USE_SELECT_SECTION_FOR_FUNCTIONS in doc/tm.texi, which reads:
@defmac USE_SELECT_SECTION_FOR_FUNCTIONS
Define this macro if you wish
--- Comment #20 from roger at eyesopen dot com 2006-05-14 17:39 ---
Hi APL,
Re: comment #18. It was actually stevenb that changed the known to work
line,
and assigned this PR to me, after I'd committed a fix to the gcc-4_1-branch.
See http://gcc.gnu.org/ml/gcc-bugs/2006-05/msg01351
--- Comment #5 from roger at eyesopen dot com 2006-05-15 17:37 ---
This should now be fixed on both mainline and the 4.1 branch. Thanks Andreas.
--
roger at eyesopen dot com changed:
What|Removed |Added
--- Comment #22 from roger at eyesopen dot com 2006-05-15 17:41 ---
This should now be fixed on all open branches.
--
roger at eyesopen dot com changed:
What|Removed |Added
--- Comment #12 from roger at eyesopen dot com 2006-05-18 01:50 ---
This is now fixed on both mainline and the 4.1 branch.
--
roger at eyesopen dot com changed:
What|Removed |Added
--- Comment #4 from roger at eyesopen dot com 2006-05-20 15:14 ---
This problem is fixed by specifying the -frounding-math command line option,
which informs the compiler that non-default rounding modes may be used.
With gcc-3.4, specifying this command line option disables
--- Comment #3 from roger at eyesopen dot com 2006-06-01 02:41 ---
This is now fixed on mainline provided the user specifies -ffast-math.
There are some complications where imagpart(z*~z) can be non-zero, if
imagpart(z) is non-finite, such as an Inf or a NaN. It's unclear from
1 - 100 of 181 matches
Mail list logo
