--
What|Removed |Added
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19704
--- Additional Comments From kgardas at objectsecurity dot com 2005-01-31
09:00 ---
Subject: Re: [4.0 Regression] 8% C++ compile-time
regression in comparison with 3.4.1 at -O1 optimization level
Hello,
new timings are here: http://gcc.gnu.org/ml/gcc/2005-01/msg01714.html
Actually
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-31
09:02 ---
Subject: Bug 19696
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-01-31 09:02:35
Modified files:
gcc: ChangeLog optabs.c
Log message:
--- Additional Comments From stephan dot bergmann at sun dot com
2005-01-31 09:09 ---
"I think you can get all the speed back by supplying -mbranch-cost=1 but I could
be wrong."
No, adding -mbranch-cost=1 leads to only a very minor performance improvement.
"Can you give the output of "
--- Additional Comments From charlet at adacore dot com 2005-01-31 09:21
---
Subject: Re: gnat tools not buildable cross
> Since it is clearly a regression (vs 3.2 cross RTEMS/Ada capabilities), would
> you mind proposing a patch to current 4.0 libada? I've included Arnaud in CC.
Ther
--- Additional Comments From kgardas at objectsecurity dot com 2005-01-31
09:31 ---
Hello,
new timings MICO ORB sources are here:
http://gcc.gnu.org/ml/gcc/2005-01/msg01714.html
Cheers,
Karel
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13776
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-31
09:54 ---
Proposed patch here: http://gcc.gnu.org/ml/gcc-patches/2005-01/
--
What|Removed |Added
--- Additional Comments From jkanze at cheuvreux dot com 2005-01-31 09:55
---
Subject: Re: exception not caught when passing through C code
> This is documented somewhere in the docs, I think. If you mix C
> codes with C++ and exceptions are raised (through callbacks) and
> you need
--- Additional Comments From pcarlini at suse dot de 2005-01-31 10:32
---
Ok, now I see the issue clearly:
http://gcc.gnu.org/ml/gcc-patches/2004-08/msg00114.html
In particular:
"I did not attempt to fix all of the V3 headers; I'm only concerned
with libsupc++ at the moment. How
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-01-31
10:54 ---
> I'll admit that I don't understand the problem, at least on
> Sparc. There is an ABI which defines what the C stack looks
> like; the C++ stack is, in fact, identical. Walking back the
> stack is trivi
--- Additional Comments From uros at kss-loka dot si 2005-01-31 11:14
---
This is .t69.final_cleanup:
;; Function long long int __vector__ not_eliminated_bis(const int&)
(_Z18not_eliminated_bisRKi)
long long int __vector__ not_eliminated_bis(const int&) (i)
{
int __q0;
:
__q0 = *i
--- Additional Comments From micis at gmx dot de 2005-01-31 12:06 ---
I have rechecked it at x86_64.
It occurs only with configure/make bootstrap, not with configure make.
Actual error is:
stage1/xgcc -Bstage1/ -B/usr/local/gcc40c/x86_64-unknown-linux-gnu/bin/ -c -
g -O2 -DIN_GCC -W
while compiling gcc-3.4.3 with itself(compiled by gcc-2.95),
got these error:
---
In file included from ../../gcc-3.4.3/gcc/unwind-dw2-fde-glibc.c:59:
../../gcc-3.4.3/gcc/unwind-dw2-fde.c:52: warning: missing braces around
initializ
--- Additional Comments From ca50015 at yahoo dot com 2005-01-31 12:19
---
can't find the string "__LOCK_INITIALIZER" through gcc source files.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19720
This is a meta bug for tracking what CSE still does and
other passes do not catch. After some SPEC runs with CSE
disabled completely or with at least CSE path following
disabled, it seems that we are very close to the point
where cse.c can be cleaned up significantly.
Please hang any known missed
--
What|Removed |Added
CC||kazu at cs dot umass dot
||edu, pinskia at gcc dot gnu
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-31
12:39 ---
To get something started, I have done SPECint and SPECfp runs on AMD64 with CVS
HEAD 20050130, unmodified vs. a cse.c with path following disabled (by setting
the max-cse-path-length to 1). The overall score
--
What|Removed |Added
BugsThisDependsOn||19659
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-31
12:42 ---
Created an attachment (id=8112)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8112&action=view)
gcov coverage testing of CVS HEAD 20050131 on AMD64
This is the coverage data of cse.c
--
What|Removed |Added
CC||law at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
--- Additional Comments From kazu at cs dot umass dot edu 2005-01-31 12:55
---
Now tree_verify_flow_info verifies that a nonlocal label does not appear
in the middle of a seuqnece of labels.
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01383.html
--
What|Removed
I am trying to install gcc 3.2.3 on an opteron machine (x86, 64 bit, redhat
enterprise Linux version 3.0). I am facing the a problem.
What i did is ...
configured using the following command...
srcdir/configure --prefix=destdir/gcc --enable-threads
Then in the object dir (objdir) did
--- Additional Comments From kazu at cs dot umass dot edu 2005-01-31 13:22
---
This has been fixed with Daniel Berlin's recent check-in.
--
What|Removed |Added
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-31
13:30 ---
Is this still a problem for you with more recent releases of GCC? I don't think
anyone is still interested in providing patches for GCC 3.2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19722
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-01-31
13:40 ---
> Is this still a problem for you with more recent releases of GCC? I don't
> think
> anyone is still interested in providing patches for GCC 3.2.
Moreover I'm not sure the FSF 3.2.x compiler is really r
Consider:
int
foo (int a)
{
int x = 0 % a++;
return a;
}
Here is what I get:
foo (a)
{
:
return a;
}
--
Summary: [4.0 Regression] A side effect is missed in 0 % a++.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: wrong-
--- Additional Comments From kazu at cs dot umass dot edu 2005-01-31 13:42
---
This has been fixed, but the fix isn't complete. See PR 19723.
--
What|Removed |Added
--
What|Removed |Added
Status|NEW |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12845
--- Additional Comments From bangerth at dealii dot org 2005-01-31 14:02
---
gcc 3.2.x was definitely not stable on opteron. As far as I remember,
opteron support was developed by SuSE on the hammer branch and by
redhat on top of their 3.2.x based compiler. I believe that both folded
--- Additional Comments From kazu at cs dot umass dot edu 2005-01-31 14:03
---
The first two cases are optimized as expected.
The third one is wrong. Here is mostly likely what Andrew Pinski meant to say.
void
t2 ()
{
int i;
int x;
for (i = 0; i < 1; i++)
{
int
--- Additional Comments From tbptbp at gmail dot com 2005-01-31 14:14
---
Yes, and i'm not asking for a GPR->SSE transfer. What i'm asking is why gcc
feels the urge to copy that memory reference to the stack before fooling around
with it.
The full sequence is:
401298: 8b 42 28
--- Additional Comments From kazu at cs dot umass dot edu 2005-01-31 14:28
---
*** This bug has been marked as a duplicate of 14483 ***
--
What|Removed |Added
--- Additional Comments From kazu at cs dot umass dot edu 2005-01-31 14:28
---
*** Bug 19702 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-31
14:38 ---
This is with the 20050130 snapshot on ia64-unknown-linux-gnu,
-O3 and with flag_complex_divide_method = 1. The files slasy2.f
and dlasy2.f are compiled with -O0, to get around PR 18977.
cgd.out: CGV dr
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-31
14:41 ---
Could this be a glibc bug?
--
What|Removed |Added
Component|c
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-31
14:44 ---
Confirmed via Roger on the mailing list.
--
What|Removed |Added
CC|
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-01-31
14:45 ---
Proposed patch here:
http://gcc.gnu.org/ml/java-patches/2005-q1/msg00245.html
--
What|Removed |Added
--- Additional Comments From kazu at cs dot umass dot edu 2005-01-31 14:46
---
Seems like what I feared in comment #2 is going on.
Specifically, for the original test case, I get:
foo (a)
{
_Bool D.1130;
_Bool D.1129;
int b;
int D.1120;
:
D.1129_5 = a_2 == 0;
D.1130_6 = !D.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-31
14:46 ---
No, the first one is not even optimizated on the mainline on ppc:
cmpw cr7,r30,r28
crnot 30,29
mfcr r3
rlwinm r3,r3,31,1
bl L_f$stub
--
What|Removed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-31
14:58 ---
Actually the code is invalid, see PR 6548 which this is a dup of.
*** This bug has been marked as a duplicate of 6548 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-31
14:58 ---
*** Bug 19474 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From wanderer at rsu dot ru 2005-01-31 15:04
---
gcc CVS mainline (2004-02-02 20:20 GMT) bootstraped using recent 4.0 accept
option "-finput-charset=ISO8859-1" without error.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19656
I am unable to build a m68hc11 cross-compiler on 64-bit architectures. xgcc
generates an internal compiler error during the build of libgcc2.
Here is a reduced testcase:
typedef struct
{
char a;
int b;
} foo;
void ice()
{
int c;
foo * bar;
// one of the two following instructions caus
--- Additional Comments From schwab at suse dot de 2005-01-31 15:08 ---
Most likely careless mixing of NPTL and Linuxthreads headers.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19720
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-31
15:09 ---
This looks more likel a glibc bug, could you attach the preprocessed source?
--
What|Removed |Added
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-31
15:14 ---
Are you sure that this is not a IA64 bug?
Can you check the cross compiler compiled at -O0 since this sounds like a IA64
bug, also try with a
newer ia64 compiler.
--
What|Removed
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-01-
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-31
15:18 ---
Confirmed, werid I think .cse should be renamed to cse1 and then cse2 might
work correct or
something like that.
There might have been a report of this to the mailing lists before.
--
What
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-01-31
15:23 ---
SPEC comparisons for i686 before/after kazu's patch to completely disable CSE.
The 20050127 compiler has CSE enabled. The 20050129 compiler has CSE disabled.
Compile times for SPECint were reduced by 9%.
--- Additional Comments From joel at oarcorp dot com 2005-01-31 15:23
---
Subject: Re: gnat tools not buildable cross
neroden at gcc dot gnu dot org wrote:
> --- Additional Comments From neroden at gcc dot gnu dot org 2005-01-29
> 22:19 ---
>
>>You may try adding a gnattools
--- Additional Comments From joel at oarcorp dot com 2005-01-31 15:24
---
Subject: Re: gnat tools not buildable cross
charlet at adacore dot com wrote:
> --- Additional Comments From charlet at adacore dot com 2005-01-31 09:21
> ---
> Subject: Re: gnat tools not buildable cr
--- Additional Comments From kazu at cs dot umass dot edu 2005-01-31 15:25
---
Subject: Re: Missed comparision optimization
(jump threading related)
Hi Andrew,
> No, the first one is not even optimizated on the mainline on ppc:
> cmpw cr7,r30,r28
> crnot 30,29
>
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-01-31
15:26 ---
Similarly for em64t.
Build times for SPECint were reduced by 9.2%.
Build times for SPECfp were reduced by 7.5%.
Compiler bootstrap times were reduced by 4.4%.
Comparison between 20050127/spec-20050127.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-31
15:33 ---
:;
f (i <= );
D.1141 = (unsigned int) i + 1;
i = (int) D.1141;
if (D.1141 != 1) goto ; else goto ;
But note on x86 I get the same and the extra compare:
.L2:
xorl%eax, %e
--- Additional Comments From kazu at cs dot umass dot edu 2005-01-31 15:42
---
On my x86 machine, I get f (1).
On Andrew's powerpc, he gets f (i < 100) regardless of whether he is
targetting x86 or powerpc.
So it might be the case that the host matters.
How strange!?
--
http:
--- Additional Comments From aurelien at aurel32 dot net 2005-01-31 15:47
---
Subject: Re: ICE when building a m68hc11 cross-compiler
on ia64
pinskia at gcc dot gnu dot org wrote:
> --- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-31
> 15:14 ---
> Are you
--- Additional Comments From schwab at suse dot de 2005-01-31 15:51 ---
Not a glibc bug, rather a packaging bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19720
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-01-31
15:55 ---
This is indeed a duplicate of PR16201
*** This bug has been marked as a duplicate of 16201 ***
--
What|Removed |Added
--
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-01-31
15:56 ---
> Such major addition is not suitable for stage 3 in my opinion (but very
> welcome for stage 1), we want a much more localized change, which is certainly
> possible here.
I don't think so. When you get in
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-01-31
15:56 ---
*** Bug 17209 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-01-31
15:59 ---
The problem is the arith_adjacent_mem pattern, which is sometimes expanding to
more than three instructions if the addressed objects are in the stack frame.
Patch in testing.
--
What|Remov
I want to compile c++ source that uses std::wstring but std::wstring is
undeclared. So I greped around an found that the specialization in stringfwd.h
needs to declare _GLIBCXX_USE_WCHAR_T. After this define, the compiler prints
out many errors about missing declarations to some w-functions.
The f
--- Additional Comments From ca50015 at yahoo dot com 2005-01-31 16:22
---
yes, i'm using nptl.
glibc was configured like this:
--prefix=/usr --with-tls --enable-add-ons=nptl --enable-kernel=2.6.10
--with-headers=/src/linux-2.6.10/include
i tried create a new
'/usr/include'
and co
1. code below compiles into many instructions like "movl $0, 16(%eax)", should
have been "stosw" since all initializations are zeros. Even if one or two are
skipped in the middle still bulk stosw should be used.
2. Even when class E with external constructor uncommented this shouldn't change
since
--- Additional Comments From charlet at adacore dot com 2005-01-31 16:38
---
Subject: Re: gnat tools not buildable cross
> I don't think so. When you get into the libada directory,
> CC="$(CC_FOR_TARGET)"
> and all hope is lost of having the tools work in a cross configuration.
That
--- Additional Comments From pcarlini at suse dot de 2005-01-31 16:39
---
*** This bug has been marked as a duplicate of 17005 ***
--
What|Removed |Added
Statu
--- Additional Comments From pcarlini at suse dot de 2005-01-31 16:39
---
*** Bug 19725 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From wanderer at rsu dot ru 2005-01-31 16:59
---
I found problem:
At FreeBSD intl.h placed in /usr/local/include
and gcc 3.4.* not search by default /usr/local/include for system headers
(I check this for system compiler gcc version 3.4.2 [FreeBSD] 20040728 and g
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-31
17:02 ---
This looks promising.
I'll do a full check later.
Thomas
--- transfer.c.orig 2005-01-31 18:03:12.0 +0100
+++ transfer.c 2005-01-31 18:04:00.0 +0100
@@ -150,6 +150,14 @@
--- Additional Comments From sitaram dot banda at gmail dot com 2005-01-31
17:23 ---
(In reply to comment #3)
> gcc 3.2.x was definitely not stable on opteron. As far as I remember,
> opteron support was developed by SuSE on the hammer branch and by
> redhat on top of their 3.2.x based
--- Additional Comments From law at redhat dot com 2005-01-31 17:30 ---
Subject: Re: [4.0 Regression] A side effect
is missed in 0 % a++.
On Mon, 2005-01-31 at 14:44 +, pinskia at gcc dot gnu dot org wrote:
> --- Additional Comments From pinskia at gcc dot gnu dot org 2
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |law at redhat dot com
|dot org |
Status|NEW
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-31
18:01 ---
Subject: Bug 19650
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-01-31 18:00:52
Modified files:
gcc: ChangeLog fold-const.c
gcc/t
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-31
18:16 ---
Not a gcc bug so closing.
--
What|Removed |Added
Status|WAITING
--
What|Removed |Added
Component|tree-optimization |c++
Keywords||missed-optimization
http://gcc.gnu.org/bugzilla/show_bug.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-31
18:20 ---
I think it is time to check your memory and/or hardware, this works for so many
other people.
--
What|Removed |Added
--- Additional Comments From dalej at apple dot com 2005-01-31 18:27
---
Fixed by patch above.
--
What|Removed |Added
Status|ASSIGNED|RESOLV
A "gcc -Wall -c test.c" of the following compiles cleanly while it should
generate an error as incorrect code will be produced for function calls to foo()
via bar().
int foo(void) __attribute__((regparm(3)));
int (*bar)(void) __attribute__((regparm(0))) = foo;
--
Summary: i386 regparm
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-31
18:43 ---
Fixed in 3.4.0:
: Search converges between 2004-02-02-3.4 (#1) and 2004-03-01-3.4 (#2).
: Search converges between 2004-02-01-trunk (#445) and 2004-03-01-trunk (#446).
--
What|Removed
--- Additional Comments From wanderer at rsu dot ru 2005-01-31 18:44
---
And PR18360 indeed related to this bug report.
If gcc 3.4.3 bootstraped using installed gcc 4.0:
gcc/intl/configure test using gcc 4.0 and found /usr/local/include/libintl.h
and remember this
But stage1 gcc 3.4.3
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-31
18:49 ---
Confirmed, note this is either a front-end bug because the front-end produces
multiple stores or a
target bug for not combining those stores to one store string instruction.
Also if one initializer is mis
--- Additional Comments From pcarlini at suse dot de 2005-01-31 18:57
---
Adding pragma visibility push(default)/pop to the basic_string.h header (or to
the std_string.h header, for that matter) does *not* fix the issue for me. Is
anyone able to confirm this or viceversa? (binutils 2.15.
--- Additional Comments From sitaram dot banda at gmail dot com 2005-01-31
19:01 ---
(In reply to comment #5)
> I think it is time to check your memory and/or hardware, this works for so
many other people.
Yeah, can you help me insorting out the issue. I am providing some of the info
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-31 19:04
---
I think you'll also want to try using -fno-gcse. The gcse pass is hoisting
values out of your loop (as it is supposed to), except that we don't have
enough registers to hold it all, so the values get spilled
--- Additional Comments From bangerth at dealii dot org 2005-01-31 19:30
---
In general, you have to make sure that you have the required versions
of other packages. As for helping you to sort out hardware problems --
please look elsewhere on the web, this forum here is concerned with
--- Additional Comments From aurelien at aurel32 dot net 2005-01-31 19:56
---
Created an attachment (id=8117)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8117&action=view)
diff of debugging dumps between amd64 and ia64
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19724
--- Additional Comments From aurelien at aurel32 dot net 2005-01-31 19:59
---
I have just built a new gcc targeted for m68hc11 with gcc-3.4, and the problem
is still there, both with default optimizations and with -O2.
I have also run 'gcc -da' on the testcase on both amd64 and ia64 hos
--- Additional Comments From stevenb at suse dot de 2005-01-31 20:14
---
Subject: Re: [meta-bug] optimizations that CSE still catches
My numbers for not disabling CSE completely but disabling path following
are a lot less pessimistic. This was on an AMD Opteron at 1600MHz:
GCC was co
--- Additional Comments From tbptbp at gmail dot com 2005-01-31 20:18
---
-fno-gcse is a godsend, instant speedup and most of the sillyness when inlining
is gone.
Now i've applied both your patches, and while there's promising they also
triggers their own nastyness; gcc is so fond of me
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-31
20:22 ---
Isn't this the same as PR 16925?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19724
--- Additional Comments From aurelien at aurel32 dot net 2005-01-31 20:28
---
(In reply to comment #5)
> Isn't this the same as PR 16925?
No, this is different. The patch attached to PR 16925 fixes the problem on all
three hosts (amd64, ia64 and alpha). And the problem is on a different
--- Additional Comments From tbptbp at gmail dot com 2005-01-31 20:35
---
Hmm, there's something fishy with _mm_set1_epi32.
With your patches there's no stack copy anymore but, with
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19714 testcase, i get:
00401080 :
401080: 66 0f 6e 4
Index: Gnu.java
===
RCS file: /cvsroot/gcc/gcc/libjava/gnu/java/security/provider/Gnu.java,v
retrieving revision 1.7
diff -u -r1.7 Gnu.java
--- Gnu.java 15 Nov 2004 20:02:04 - 1.7
+++ Gnu.java 31 Jan 2005 20:47:01 -
@@ -129,
appRandom might be null in DSASignature (it is not initialized), yet in the
method "public byte[] engineSign()" appRandom is used which causes an NPE.
Casey Marshall sent me the attached replacement DSASignature.java file and it
works.
--
Summary: libgcj DSASignature.java null point
--- Additional Comments From ovidr at users dot sourceforge dot net
2005-01-31 21:02 ---
Created an attachment (id=8118)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8118&action=view)
The file.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19729
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-31 21:02
---
(In reply to comment #22)
No, it isn't. Look at your functions again. The assembly that you
pasted is 100% perfect. You cannot improve on that in any way.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
gcc version 3.4.2 [FreeBSD] 20040728
# c++filt _Z4test1AILZ2buEE
Segmentation fault (core dumped)
gcc version 3.2
# c++filt _Z4test1AILZ2buEE
test(A)
Quick workaround patch based on 3.2 libiberty sources.
(similar to be done over libiberty demangler)
Index: cp-demangle.c
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-31 21:12
---
(In reply to comment #21)
> 4010ce: 0f 29 6c 24 10 movaps %xmm5,0x10(%esp)
> 4010de: 0f 59 5c 24 10 mulps 0x10(%esp),%xmm3
> 4011a1: 0f 29 04 24 movaps %xmm
--- Additional Comments From pcarlini at suse dot de 2005-01-31 21:20
---
Ian, can you have a look? Mainline __cxa_demangle returns -2.
--
What|Removed |Added
--- Additional Comments From law at redhat dot com 2005-01-31 21:35 ---
Subject: Re: [meta-bug] optimizations that CSE still
catches
On Mon, 2005-01-31 at 20:14 +, stevenb at suse dot de wrote:
> --- Additional Comments From stevenb at suse dot de 2005-01-31 20:14
> --
1 - 100 of 163 matches
Mail list logo
