--- Comment #20 from roger at eyesopen dot com 2008-06-12 21:31 ---
Hi Ralf,
Thanks for your patch.
Sorry for the delay in replying, I needed to check out mainline on my IRIX
box and rebuild a baseline, and once that had completed make -k check,
I tried with --enable-fixed-point first
--- Comment #5 from roger at eyesopen dot com 2008-04-24 15:01 ---
Well, I've now had time to read the Barriato, Hofri et al. 2002 paper, and the
bad news is that such an approximate median selection algorithm can't be used
to guarantee an O(N) worst-case std::nth_element implementation
--- Comment #2 from roger at eyesopen dot com 2008-04-21 03:22 ---
Yep, now that we're back in stage1, it's about time I got around to submitting
the O(n) worst case nth_element implementation that I mentioned last year. For
Steven's benefit, the implementation I've already coded up
--- Comment #7 from roger at eyesopen dot com 2008-01-29 01:12 ---
I'm also seeing this same failure with make profiledbootstrap on
x86_64-unknown-linux-gnu. A make bootstrap on the same machine completes and
regression tests fine (14 unexpected failures in gcc). I suspect
--- Comment #8 from roger at eyesopen dot com 2007-11-02 16:41 ---
Created an attachment (id=14471)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14471action=view)
Default libgcc.a objects on mips-sgi-irix6.5
I'll respond to Jakub's latest comments before trying DJ's more recent
--- Comment #9 from roger at eyesopen dot com 2007-11-02 17:12 ---
Doh! DJ's patch gets us a little further, but it things are still broken.
However, it's an excellent debugging tool which shows that its the invocation
with libgcc-objects-15 that's broken. Applying the same trick
--- Comment #4 from roger at eyesopen dot com 2007-11-01 17:15 ---
Thanks to both Jakub and DJ for their help. I just tried out the suggested
patch on my IRIX box, and was surprised that it didn't resolve the error.
My apologies that my initial analysis might have been wrong
: unassigned at gcc dot gnu dot org
ReportedBy: roger at eyesopen dot com
GCC host triplet: mips-sgi-irix6.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781
--- Comment #1 from roger at eyesopen dot com 2007-10-13 04:14 ---
Many thanks to Eric Botcazou! It turns out that this bug was a duplicate
of PR target/32325. I can confirm that with Eric's fix, and once I'd committed
my libstdc++ patch for the EOVERFLOW issue (mentioned by Eric
--- Comment #7 from roger at eyesopen dot com 2007-10-13 04:14 ---
*** Bug 33545 has been marked as a duplicate of this bug. ***
--
roger at eyesopen dot com changed:
What|Removed |Added
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: roger at eyesopen dot com
GCC target triplet: alphaev67-dec-osf5.1
http
--- Comment #10 from roger at eyesopen dot com 2007-04-27 18:20 ---
Paul's fix looks correct to me. It appears that when the #if 0 was added
to disable broken loop shifting at some point in the distant past, the critical
functionality.
if (nDepend)
break;
was accidentally
--- Comment #10 from roger at eyesopen dot com 2007-04-23 20:54 ---
Many thanks to Paul for fixing this, and my apologies for being overloaded at
work and not being available to investigate it fully myself.
I believe that Paul's fix of explicitly checking expr1-ref-next is the
correct
--- Comment #11 from roger at eyesopen dot com 2007-04-23 21:05 ---
Duh! I am missing something obvious! The ref-u.ar.type == AR_FULL test on
line 1120 returns true. The test for ref-next needs to be moved earlier.
Sorry again for the inconvenience. Clearly, my brain isn't working
--- Comment #6 from roger at eyesopen dot com 2007-03-08 01:55 ---
I suspect this problem is now fully resolved. The patch for PR24427 has been
backported to the gcc-4_1-branch, and additionally on mainline, simplify-rtx.c
has been enhanced to also perform the missed-optimization
--- Comment #4 from roger at eyesopen dot com 2007-03-06 16:32 ---
This should now be fixed on both mainline and the 4.2 release branch.
--
roger at eyesopen dot com changed:
What|Removed |Added
--- Comment #10 from roger at eyesopen dot com 2007-02-18 18:10 ---
Hi Eric,
It's not PR24427 that's the motivation for this backport, but PR 28173.
In fact, it was *your* request in comment #2 of PR28173 to backport this!
I'm a little disappointed you'd even question my decision
--- Comment #5 from roger at eyesopen dot com 2007-02-02 00:17 ---
It looks like Ian's recent subreg lowering pass patch has improved code
generation on this testcase. Previously, we'd spill three integer registers to
the stack for LLM, we're now down to two. [A significant
--- Comment #2 from roger at eyesopen dot com 2007-01-28 02:58 ---
Hi Andrew, could you recheck whether you can reproduce this problem on
mainline?
Updating the MODIFY_EXPR patch in PR 22368 to check GIMPLE_MODIFY_STMT, I'm
unable to reproduce this failure on x86_64-unknown-linux-gnu
--- Comment #2 from roger at eyesopen dot com 2007-01-19 20:55 ---
It looks like the ivopts pass is creating dubious? array references.
The symbol.c.053t.vrp1
D.12252_12 = (long unsigned int) i_2;
D.12255_15 = ns_4-default_type[D.12252_12];
ts_16 = D.12255_15 + -2328B;
i.e. we
--- Comment #3 from roger at eyesopen dot com 2007-01-11 16:56 ---
Ok, I've now spent some time reading the code, I understand what's going wrong
and what needs to be done to fix it. The problem resolves around the
nest_flag argument to gfc_trans_nested_forall_loop. This argument only
--- Comment #5 from roger at eyesopen dot com 2007-01-04 22:34 ---
Can you reduce a test case for the loop, now that the code in the PR
description is fixed? One thing that looks a bit odd is that in the condition
you describe the constant term 1, isn't on the far right, which I
--- Comment #3 from roger at eyesopen dot com 2007-01-01 20:46 ---
Hi Richard (Happy New Year),
I was wondering whether you could confirm whether the patch I committed fixes
the loop termination conditions in tramp3d? It resolves the example code given
in the description which now
--- Comment #4 from roger at eyesopen dot com 2006-12-16 19:28 ---
Steve posted his fix at http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01012.html
and I came up with an improved version that correctly identifies the
equivalence
of z and z(:) here http://gcc.gnu.org/ml/gcc-patches/2006
--- Comment #3 from roger at eyesopen dot com 2006-12-01 03:25 ---
Hi Manual,
This needs to be handled in the front-ends, and in fact is already handled
by the front-ends. In c-typeck.c:build_binary_op, I see:
case TRUNC_DIV_EXPR:
case CEIL_DIV_EXPR:
case FLOOR_DIV_EXPR
--- Comment #5 from roger at eyesopen dot com 2006-12-01 04:04 ---
This needs to be handled in the front-ends...
^ should
^^ can only be
I was thinking of a slightly weaker form of need/must.
But there are two issues here. The division by zero is one
--- 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
--- 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 #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 #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 #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 #6 from roger at eyesopen dot com 2006-07-25 20:02 ---
Grr. I've just noticed richi has just assigned this patch to himself.
I also have a patch that been bootstrapped and has nearly finished
regression testing, that I was just about to post/commit. richi what
does your
--- Comment #7 from roger at eyesopen dot com 2006-07-25 20:08 ---
Ahh, I've just found the Richard's patch submission posting at
http://gcc.gnu.org/ml/gcc-patches/2006-07/msg01065.html
I agree with Andrew Pinski, I think my changes are the better fix.
We also need to investigate
--- Comment #39 from roger at eyesopen dot com 2006-07-24 00:45 ---
My latest analysis and a possible patch/workaround have been posted here:
http://gcc.gnu.org/ml/gcc-patches/2006-07/msg01015.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22313
--- Comment #37 from roger at eyesopen dot com 2006-07-17 22:15 ---
I've now tested make profiledbootstrap on both mainline and the
gcc-4_1-branch,
on both x86_64-unknown-linux-gnu and i686-pc-linux-gnu, and not only does the
profiled bootstrap build fine, but the dejagnu testsuite
--- Comment #3 from roger at eyesopen dot com 2006-07-08 14:31 ---
I tried fixing this bug, only to discover why things are exactly as they are.
The short answer is that GCC will warn about the example code if you
specify the -Wswitch-enum command line option. Specifying -Wall implies
--- Comment #2 from roger at eyesopen dot com 2006-07-06 19:17 ---
Investigating... I suspect that the SH backend's rtx_costs are parameterized
incorrectly, such that a 64-bit shift by the constant 32, looks to be at least
32 times more expensive than a 64-bit addition. The middle-end
--- Comment #5 from roger at eyesopen dot com 2006-07-06 19:47 ---
No the rtx_costs for a DImode shift really are wrong. The use of the constant
1 in sh.c:shift_costs instructs the middle-end to avoid using DImode
shifts at all costs. The semantics of rtx_costs
--- Comment #14 from roger at eyesopen dot com 2006-06-26 00:24 ---
The problem appears to be that DECL_COMPLEX_GIMPLE_REG_P is not getting set on
the declarations correctly. The VAR_DECLs that are operands to the additions
don't have DECL_COMPLEX_GIMPLE_REG_P set, so fail
--- Comment #5 from roger at eyesopen dot com 2006-06-22 00:37 ---
Doh! My apologies for the breakage! I think Dave's patch looks good, but the
one suggestion that I would make would be to test for MODE_INT first, then
call the type_for_mode langhook. This saves calling type_for_mode
--- Comment #10 from roger at eyesopen dot com 2006-06-22 04:46 ---
This should now be fixed on all active branches. Thanks to Martin for
confirming the fix bootstraps and regression tests fine on mipsel-linux-gnu.
And thanks, as always, to Andrew Pinski for maintaining the PR
--- Comment #14 from roger at eyesopen dot com 2006-06-19 23:50 ---
Unfortunately, I'm unable to reproduce this failure with a cross-compiler to
alphaev68-unknown-linux-gnu. However, examination of the tracebacks attached
to this PR and the relevant source code reveals
--- Comment #13 from roger at eyesopen dot com 2006-06-06 22:41 ---
This should now be fixed on all active branches.
--
roger at eyesopen dot com changed:
What|Removed |Added
--- 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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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-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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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-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 #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
: 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
1 - 100 of 181 matches
Mail list logo
