--- 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|Re
--- 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
--- 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 p
--- 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 fragmen
--- 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_exten
--- 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 |
--- 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 |
--- 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:
W
--- 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 m
--- 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/2
--- 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 this
--- 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 fro
--- 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 #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 there
--- 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
--- 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 in
--- 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 fai
--- 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 middl
--- 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 is that it is
--- 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 #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 de
--- Comment #13 from roger at eyesopen dot com 2005-12-04 18:06 ---
This bug has been fixed, and not just hidden. Jeff Law's proposed solution to
this problem http://gcc.gnu.org/ml/gcc/2002-01/msg01872.html which was proposed
in January 2002, was contained as part of Jeff/HP'
--- Comment #14 from roger at eyesopen dot com 2005-12-06 15:39 ---
Fixed for gcc v4.2
--
roger at eyesopen dot com changed:
What|Removed |Added
Status|NEW
--- Comment #3 from roger at eyesopen dot com 2005-12-06 15:43 ---
Fixed. I've checked all other uses of TREE_OVERFLOW in cp/decl.c and c-decl.c
to confirm that the C front-end isn't affected by a similar issue there.
Sorry for any inconvenience.
--
roger at eyesop
--- Comment #8 from roger at eyesopen dot com 2005-12-22 16:05 ---
Alan's patch has already been approved by Ian here:
http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01397.html
I think it would also be good idea to add the original bugzilla test
case, from comment #1, to the testsuit
--- Comment #2 from roger at eyesopen dot com 2005-12-29 19:42 ---
Investigating further, PR25213 looks like a duplicate of PR23098.
In that bugzilla trail, Andrew correctly identified it as a
regression from gcc 3.2.3 when using -fpic/-fPIC on x86, but the
PR was closed once the fix
--- 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 #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
--- 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 i
--- 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;
:
t.0 = (int) &t;
D.1520 = (int) &t[1];
D.1522 = (int) &t[2];
D.1524 = (int) &am
--- 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.
--- 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:
--- 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-linu
--- 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 dow
--- 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
--- 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 #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 at
--- 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->
--- 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
ion's frame.
I'm happy to test (and approve) patches for folks who don't have access to this
hardware.
--
Summary: [4.3 regression] Bootstrap failure/broken exceptions on
alpha/Tru64
Product: gcc
Version: 4.3.0
Status: UNCONFI
--- 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
--- 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
: minor
Priority: P3
Component: bootstrap
AssignedTo: 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
--- 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-ss
--- 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 test
--- 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
--- 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 but the
--- 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
--- 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 with
--- 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
--- 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 are that
--- 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
> bo
--- 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:
>
> > ++ /
--- 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,
--- 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
--- 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
--- 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 cl
--- 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
--- 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;
w
--- Additional Comments From roger at eyesopen dot com 2005-08-11 14:56
---
I'll take a look, but on first inspection this looks more like a register
allocation issue than a reg-stack problem. In the first (4.0) case, the
accumulator "result" is assigned a hard regis
--- Additional Comments From roger at eyesopen dot com 2005-08-14 19:17
---
Hi James,
Unfortunately, there are a few mistakes in your proposed patch for PR21137.
Firstly Kazu's proposed transformation is only valid when the results of the
bitwise-AND are being tested for equali
--- Additional Comments From roger at eyesopen dot com 2005-08-20 15:27
---
My apologies for adding a comment to an already resolved PR, but I've some
follow-up thoughts on Diego's recent solution to this regression. From a
high-level perspective, it would probably be more ef
--- 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 wron
--- 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=14471&action=view)
Default libgcc.a objects on mips-sgi-irix6.5
I'll respond to Jakub's latest comments before trying
--- 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 th
--- 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'
--- 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 impl
--- 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 "--ena
--- Comment #5 from roger at eyesopen dot com 2006-01-25 01:05 ---
I'm testing the following patch...
Index: combine.c
===
*** combine.c (revision 109912)
--- combine.c (working copy)
*** try_combine
--- Comment #11 from roger at eyesopen dot com 2006-01-25 19:52 ---
Created an attachment (id=10729)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10729&action=view)
patch v2
Here's a revised version of the patch that also handles the STRICT_LOW_PART
case.
My apologie
on behavior change in 4.1
(regression?)
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: roger at eyesopen dot com
on behavior change in 4.1
(regression?)
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: roger at eyesopen dot com
--- Comment #1 from roger at eyesopen dot com 2006-02-02 18:43 ---
*** This bug has been marked as a duplicate of 26079 ***
--
roger at eyesopen dot com changed:
What|Removed |Added
--- Comment #1 from roger at eyesopen dot com 2006-02-02 18:43 ---
*** Bug 26080 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26079
Status: 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/
--- 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 t
--- 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
1 - 100 of 181 matches
Mail list logo
