--- Comment #6 from benjamin at smedbergs dot us 2006-08-11 01:50 ---
Gabriel, can you explain how it worked correctly in all the previous releases?
Is my summary of how it is done using only the vtable inaccurate?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28687
--
Summary: Cross compile internal error.
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lee dot adam
emsdev1-ladamson [View: lee_3_view]:
/opt/gcc/cross-4.1.1-x86-solaris2.10/i386-pc-solaris2.10/bin/g++ -v
Using built-in specs.
Target: i386-pc-solaris2.10
Configured with: ../gcc-4.1.1/configure --target=i386-pc-solaris2.10
--prefix=/opt/gcc/cross-4.1.1-x86-solaris2.10 --enable-languages=c,c++
--en
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-11 02:40 ---
*** This bug has been marked as a duplicate of 28689 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-11 02:40 ---
*** Bug 28688 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28689
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-11 02:41 ---
Can you attach the preprocessed source?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #13 from atgraham at gmail dot com 2006-08-11 02:42 ---
The problem goes away (at least in this case) at optimization levels -O[s123]
(but remains at -O0) when compiling with -fstack-protector. Of course, that's
not really an acceptable workaround for most people affected by
--- Comment #3 from lee dot adamson at macquarie dot com 2006-08-11 02:52
---
Created an attachment (id=12061)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12061&action=view)
Preprocessed source.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28689
--- Comment #7 from gdr at integrable-solutions dot net 2006-08-11 04:48
---
Subject: Re: [4.2 regression] dynamic_cast disallowed too rigorously
with -fno-rtti
"benjamin at smedbergs dot us" <[EMAIL PROTECTED]> writes:
| Gabriel, can you explain how it worked correctly in all the pr
On some powerpc processors, it is very desirable for performance reasons, to
have the base pointer for an indexed load/store insn to be in the rA position
rather than the rB position (example insn shown below).
lwzx rD,rA,rB
For some test cases, we get this right, but for the following test c
Symptoms: gcc fails to notice flags already available and generates redundant
comparisons.
After tracking down a real world performance issue i couldn't rid of without
ressorting to inline asm, i've bugged Uros; he produced that reduced testcase.
int test(float a, float b)
{
int lt = a < b;
int
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-11 05:52 ---
The problem is obvious from the RTL:
(insn:TI 47 7 48 (set (reg:CCFP 17 flags)
(compare:CCFP (reg/v:SF 22 xmm1 [orig:59 a ] [59])
(reg/v:SF 21 xmm0 [orig:60 b ] [60]))) 23 {*cmpfp_i_sse}
(insn_lis
--- Comment #2 from tbptbp at gmail dot com 2006-08-11 06:07 ---
Subject: Re: missed optimization, redundant scalar SSE comparisons
On 11 Aug 2006 05:52:26 -, pinskia at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> Using unsigned char and a temp variable removes the problem of
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-11 06:25 ---
Hmm, now it is because the order int the compares are different:
418f01: comiss %xmm0,%xmm1
418f04: seta %al
418f07: comiss %xmm1,%xmm0
see how the first is xmm0, xmm1 While the second is x
--- Comment #4 from tbptbp at gmail dot com 2006-08-11 06:43 ---
Subject: Re: missed optimization, redundant scalar SSE comparisons
On 11 Aug 2006 06:25:09 -, pinskia at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> --- Comment #3 from pinskia at gcc dot gnu dot org 2006-08
101 - 115 of 115 matches
Mail list logo
