--- Comment #31 from dave at hiauly1 dot hia dot nrc dot ca 2009-04-29
01:03 ---
Subject: Re: [4.2/4.3 regression] symbol __signb...@glibcxx_3.4 in libstdc++
exported
Also, libstdc++.so is definitely not the right home for __signbitl symbol, so
we definitely shouldn't allow any
--- Comment #14 from dave at hiauly1 dot hia dot nrc dot ca 2009-04-22
13:45 ---
Subject: Re: [4.4/4.5 regression] symbol __signb...@glibcxx_3.4 in libstdc++
not exported anymore
--- Comment #13 from jakub at gcc dot gnu dot org 2009-04-22 09:12
---
If hppa-linux has
--- Comment #17 from dave at hiauly1 dot hia dot nrc dot ca 2009-04-22
19:32 ---
Subject: Re: [4.4/4.5 regression] symbol __signb...@glibcxx_3.4 in libstdc++
not exported anymore
* Original submitter is incorrect, there has never been a
__signb...@glibcxx_3.4 symbol
--- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca 2009-04-21
17:28 ---
Subject: Re: [4.4/4.5 regression] symbol __signb...@glibcxx_3.4 in libstdc++
not exported anymore
I believe the problem is the symbol was exported when it shouldn't have
been.
How
--- Comment #12 from dave at hiauly1 dot hia dot nrc dot ca 2009-04-21
21:01 ---
Subject: Re: [4.4/4.5 regression] symbol __signb...@glibcxx_3.4 in libstdc++
not exported anymore
At present glibc does not create an long double alias for the double __signbit
function
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2009-04-17
00:20 ---
Subject: Re: [4.4/4.5 regression] symbol __signb...@glibcxx_3.4 in libstdc++
not exported anymore
Bloody hack but will probably work
Long double on hppa-linux is the same as double (64 bits).
Dave
--- Comment #18 from dave at hiauly1 dot hia dot nrc dot ca 2008-02-24
01:41 ---
Subject: Re: [4.2 Regression] ICE in delete_output_reload, at reload1.c:7926
--- Comment #16 from eager at eagercon dot com 2008-02-23 21:18 ---
Attached is a patch to reload.c which addresses
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2008-01-27
00:24 ---
Subject: Re: libjava fails to build on hppa-linux-gnu (ICE in simplify_subreg)
works for me with kyles patch for the kernel.
It's in 2.6.24.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2008-01-21
00:27 ---
Subject: Re: ICE: output_operand: invalid expression
as operand on hppa
(gdb) p debug_rtx (insn)
(code_label/s 1897 4221 1898 13722 (*.LJpc=819954) [0 uses])
We are losing usage counts
--- Comment #29 from dave at hiauly1 dot hia dot nrc dot ca 2008-01-11
21:29 ---
Subject: Re: [4.1/4.2/4.3 Regression] Endless loop while building a 64-bit
2.6.20 kernel
Eric,
More precisely the QTY is changed after the reg has been entered with a hash.
This is expected
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2008-01-06
21:59 ---
Subject: Re: ICE: output_operand: invalid expression as
operand on hppa
This bug is present on 4.2 branch but head doesn't fail for me. The problem
is a deleted label.
The label is deleted
--- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca 2007-12-15
23:17 ---
Subject: Re: [4.1/4.2/4.3 Regression] Endless
loop while building a 64-bit 2.6.20 kernel
What does the full cse1 dump look like at that point (don't forget to call
fflush(dump_file) from gdb
--- Comment #19 from dave at hiauly1 dot hia dot nrc dot ca 2007-12-09
20:39 ---
Subject: Re: [4.2/4.3 Regression] ICE in reload_cse_simplify_operands, at
postreload.c:392
Can this be closed now? Should the testcase (e.g. the #c3 one) go into the
testsuite?
I'm still pondering
--- Comment #16 from dave at hiauly1 dot hia dot nrc dot ca 2007-12-05
19:01 ---
Subject: Re: [4.2/4.3 Regression] ICE in reload_cse_simplify_operands, at
postreload.c:392
You should request a secondary reload when you need one, like on the SPARC.
Currently the only return value
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2007-11-24
19:27 ---
Subject: Re: [4.2/4.3 Regression] ICE in
reload_cse_simplify_operands, at postreload.c:392
The attached patch seems to fix the problem on the trunk. However,
it doesn't work on 4.2. It makes
--- Comment #12 from dave at hiauly1 dot hia dot nrc dot ca 2007-11-24
21:58 ---
Subject: Re: [4.2 Regression] ICE in delete_output_reload, at reload1.c:7926
This seems to help:
Index: reload1.c
===
--- reload1.c
--- Comment #12 from dave at hiauly1 dot hia dot nrc dot ca 2007-11-24
22:14 ---
Subject: Re: [4.2/4.3 Regression] ICE in reload_cse_simplify_operands, at
postreload.c:392
I haven't seen the paradoxical subreg in a float/fix conversion
insns with the current patch. I did see
--- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca 2007-11-24
21:31 ---
Subject: Re: [4.2/4.3 Regression] ICE in reload_cse_simplify_operands, at
postreload.c:392
We need a temporary when loading/storing a HImode/QImode value
between memory and the FPU registers
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2007-11-22
03:12 ---
Subject: Re: New: [4.2/4.3 Regression] ICE in reload_cse_simplify_operands,
at postreload.c:392
paer% gcc-4.2 -c -O s_texfilter.i
swrast/s_texfilter.c: In function âsample_lambda_2dâ:
swrast
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2007-11-14
15:57 ---
Subject: Re: New: [4.2/4.3 Regression] ICE in reload_cse_simplify_operands,
at postreload.c:392
gcc 4.1 can compile the attached source without any problems, but gcc-4.2
(at -O) and trunk (20070916
--- Comment #11 from dave at hiauly1 dot hia dot nrc dot ca 2007-11-07
02:48 ---
Subject: Re: ICE optimizing passing long double to abstract method while in
other abstract's impl
--- Comment #10 from tbm at cyrius dot com 2007-10-19 21:12 ---
I forgot to mention
--- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-19
22:16 ---
Subject: Re: [4.2 Regression] ICE in delete_output_reload, at reload1.c:7926
#1 0x00601eac in delete_output_reload (insn=0x2b78f71e4140, j=1,
last_reload_reg=21)
at gcc-4.2/gcc/reload1.c
--- Comment #11 from dave at hiauly1 dot hia dot nrc dot ca 2007-08-30
01:43 ---
Subject: Re: [4.3 Regression] libgcc2.c:1890: internal compiler error: in
local_cprop_pass, at gcse.c:3236
Any news on this bug?
I have been building with Steven's change for the past couple of weeks
--- Comment #44 from dave at hiauly1 dot hia dot nrc dot ca 2007-03-31
15:10 ---
Subject: Re: Bootstrap comparison error at revision 122821
Wouldn't it be slightly better to just call range_includes_zero_p (vr1)
and return at this point?
Forget that, I didn't notice the else added
--- Comment #46 from dave at hiauly1 dot hia dot nrc dot ca 2007-03-31
15:38 ---
Subject: Re: Bootstrap comparison error at revision 122821
--- Comment #45 from rguenth at gcc dot gnu dot org 2007-03-31 15:13
---
doh, me neither.
I just started a build with your patch
--- Comment #42 from dave at hiauly1 dot hia dot nrc dot ca 2007-03-31
01:17 ---
Subject: Re: Bootstrap comparison error at revision 122821
+ /* We know that the range of input values covers the entire
+shift space. Reduce to canonical [0,width-1
--- Comment #31 from dave at hiauly1 dot hia dot nrc dot ca 2007-03-28
00:58 ---
Subject: Re: Bootstrap comparison error at revision 122821
/* If we have a RSHIFT_EXPR with a possibly negative shift
count or an anti-range shift count drop to VR_VARYING.
We
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2007-02-03
14:47 ---
Subject: Re: ICE optimizing passing long double to abstract method while in
other abstract's impl
--- Comment #5 from tbm at cyrius dot com 2007-02-03 09:45 ---
I don't see this with Linux
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2007-02-03
15:16 ---
Subject: Re: ICE optimizing passing long double to abstract method while in
other abstract's impl
--- Comment #5 from tbm at cyrius dot com 2007-02-03 09:45 ---
I don't see this with Linux
--- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2007-02-04
01:50 ---
Subject: Re: ICE optimizing passing long double to abstract method while in
other abstract's impl
--- Comment #5 from tbm at cyrius dot com 2007-02-03 09:45 ---
I don't see this with Linux
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2006-11-06
21:09 ---
Subject: Re: [4.2/4.3 regression] gcj-dbtool segfaults
Ranjit's patch to enable prologue analysis on i386 changed the behavior for
other SJLJ targets. They used to call the no-op fallback_backtrace
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2006-09-28
20:53 ---
Subject: Re: [4.2 regression] gcj-dbtool segfaults
Starting program: /home/doko/gcc/4.2/install/usr/bin/gcj-dbtool-4.2 -n foo.db
64
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca
2004-07-08 23:00 ---
Subject: Re: libstdc++'s PCH built by profiledbootstrap doe
What|Removed |Added
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca
2004-03-22 04:55 ---
Subject: Re: [3.5 regression] bootstrap failure in libobjc
Could you try my updated patch at
http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01772.html
Thanks. Test in progress.
Dave
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca
2004-03-21 03:29 ---
Subject: Re: [3.5 regression] bootstrap failure in libobjc
This is the patch that caused the testsuite regression:
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED
35 matches
Mail list logo
