--- 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
--- 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 #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 #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
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
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
--- 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
--- 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 #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 #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 #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 #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
--
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
--
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
--- 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
--- Comment #5 from gdr at integrable-solutions dot net 2006-08-11 01:20
---
Subject: Re: New: [4.2.0 regression] dynamic_cast disallowed too
rigorously with -fno-rtti
"benjamin at smedbergs dot us" <[EMAIL PROTECTED]> writes:
| Code compiled with -fno-rtti containing a dynamic_cast
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-08-10 23:25
---
(In reply to comment #9)
> http://gcc.gnu.org/viewcvs?view=rev&rev=83405
Not really, it was this part that caused it:
* name-lookup.c (pushdecl): When a local extern shadows a
file-scope decla
--- Comment #9 from janis at gcc dot gnu dot org 2006-08-10 23:15 ---
In case Jakub's patch can't be backported easily, this might be useful. A
regression hunt on powerpc-linux identified the following patch as the start of
failures for the testcase in comment #5:
http://gcc.gnu.or
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-08-10 22:02
---
Fixed on the mainline.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known
--- Comment #25 from Martin dot vGagern at gmx dot net 2006-08-10 21:48
---
(In reply to comment #8)
> 1. No way we can support clobbering both SP and FP.
You could in theory by storing one of them to some fixed memory location. But
here things get really ugly, so this is more of a phi
--- Comment #4 from bangerth at dealii dot org 2006-08-10 21:25 ---
I may not be the only one wondering whether this dynamic_cast(p) is
valid code at all. To this end, it may be worth noting section 5.2.7/1
of the standard:
1 The result of the expression dynamic_cast(v) is the res
--- Comment #2 from falk at debian dot org 2006-08-10 21:11 ---
Confirmed. This is a smaller test case:
int vformat(char *buffer) {
return buffer[32767];
}
This needs -mcpu=ev45. It is triggered by the synthetization
of the 8-bit load by 64-bit loads. ldb v0, x(a0) is done as
lda
--- Comment #8 from tbm at gcc dot gnu dot org 2006-08-10 20:51 ---
(In reply to comment #7)
> (In reply to comment #6)
> > I bet this was fixed by the patch which fixed PR 26757 finnally (comment
> > #28).
>
> I can confirm this.
Jakub, can you apply your patch for PR 26757 to 4.0 an
--- Comment #3 from benjamin at smedbergs dot us 2006-08-10 20:46 ---
This cast in particular doesn't need RTTI, because the offset to the most
derived class is in the vtable. Mozilla uses this cast to determine the
concrete type for logging purposes, without needing or wanting RTTI
info
--- Comment #7 from tbm at gcc dot gnu dot org 2006-08-10 20:44 ---
(In reply to comment #6)
> I bet this was fixed by the patch which fixed PR 26757 finnally (comment #28).
I can confirm this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28677
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.1.2 |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28641
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-10 20:32 ---
Why are you using dynamic_cast here?
dynamic_cast needs RTTI, otherwise you could get a crash.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from hjl at lucon dot org 2006-08-10 20:26 ---
Fixed by
http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00365.html
--
hjl at lucon dot org changed:
What|Removed |Added
---
--- Comment #17 from eedelman at gcc dot gnu dot org 2006-08-10 20:23
---
Created an attachment (id=12060)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12060&action=view)
New version.
Yup, the previous patch wasn't complete (it lacked
libgfortran/intrinsics/move_alloc.c); this o
--- Comment #1 from benjamin at smedbergs dot us 2006-08-10 20:22 ---
Created an attachment (id=12059)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12059&action=view)
preprocessed testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28687
gcc version 4.2.0 20060802 (experimental)
i686-pc-linux-gnu
Code compiled with -fno-rtti containing a dynamic_cast used to compile
and work properly on types with a vtable (the base class can be determined
entirely using the vtable without any RTTI information). Bug 10891 changed this
behavior to
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-08-10 20:19 ---
I bet this was fixed by the patch which fixed PR 26757 finnally (comment #28).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from tbm at gcc dot gnu dot org 2006-08-10 20:18 ---
Further reduced:
double fabs (double __x) { }
extern void exit (int __status);
void
nrerror (void)
{
exit(0);
}
float
betacf (float x)
{
void nrerror (void);
float d, h;
d = 1.0 - x;
if (fabs (d) < 1.0e-30)
--- Comment #29 from pinskia at gcc dot gnu dot org 2006-08-10 20:15
---
This has now been fixed in 4.2.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from Martin dot vGagern at gmx dot net 2006-08-10 19:49
---
Created an attachment (id=12058)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12058&action=view)
Test case including compilation result table
This is the above test case, and appended is a table matching
--- Comment #4 from tbm at gcc dot gnu dot org 2006-08-10 19:49 ---
{
__inline double fabs (double __x) throw ()
{
}
typedef struct
{
}
*__locale_t;
extern void exit (int __status) throw () __attribute__ ((__noreturn__));
}
void
nrerror (char error_text[])
{
exit (1);
#ifndef __PIC__
# define REG "ebx"
#else
# define REG "ebp"
#endif
#ifndef NBEFORE
void some_function_before(){
}
#endif
void test_function (){
long var = 42;
asm volatile(
"inc %0\n#DEBUG %%0=%0, clobber: %%"REG", ..."
:"+rm"(var)
:
:"%
--- Comment #3 from tbm at gcc dot gnu dot org 2006-08-10 19:42 ---
Fails with 4.0 and 4.1, works with 3.4 and 4.2.
--
tbm at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from tbm at gcc dot gnu dot org 2006-08-10 19:37 ---
(gdb) run -O2 tt.cc
Starting program: /usr/local/libexec/gcc/i686-pc-linux-gnu/4.2.0/cc1plus -O2
tt.cc
bar* testcase()
Analyzing compilation unitPerforming intraprocedural optimizations
Assembling functions:
bar* test
--- Comment #9 from aph at gcc dot gnu dot org 2006-08-10 19:35 ---
Subject: Bug 8923
Author: aph
Date: Thu Aug 10 19:35:07 2006
New Revision: 116069
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116069
Log:
2006-08-10 Simon Martin <[EMAIL PROTECTED]>
PR java/8923
--- Comment #14 from bjoern dot m dot haase at web dot de 2006-08-10 19:33
---
I had already a look at the code in the cp directory. Unfortunately the
documentation of the c++ front-end seems to be still worse than the docs on the
back-ends (i.e. RTL). Either it is virtually inexisting
--- Comment #4 from lmillward at gcc dot gnu dot org 2006-08-10 19:25
---
Fixed on the 4.1 branch by the reversal of the patch for PR 27668 so removing
the 4.1 regression marker.
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from lmillward at gcc dot gnu dot org 2006-08-10 19:24
---
Fixed on the 4.1 branch by the reversal of the patch for PR 27668.
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from lmillward at gcc dot gnu dot org 2006-08-10 19:24
---
Fixed on the 4.1 branch by the reversal of the patch for PR 27668 so removing
the 4.1 regression marker.
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from lmillward at gcc dot gnu dot org 2006-08-10 19:23
---
Fixed on the 4.1 branch by the reversal of the patch for PR 27668.
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from lmillward at gcc dot gnu dot org 2006-08-10 19:22
---
Fixed on the 4.1 branch by the reversal of the patch for PR 27668.
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from lmillward at gcc dot gnu dot org 2006-08-10 19:22
---
Fixed on the 4.1 branch by the reversal of the patch for PR 27668.
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #9 from lmillward at gcc dot gnu dot org 2006-08-10 19:21
---
The patch for this bug has been reverted on the 4.1 branch so re-adding the 4.1
regression marker.
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from lmillward at gcc dot gnu dot org 2006-08-10 19:20
---
Reopening bug and marking it as depending on PR 27668 as the patch for that bug
nas now been reverted on the 4.1 branch.
--
lmillward at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from lmillward at gcc dot gnu dot org 2006-08-10 19:19
---
Subject: Bug 28641
Author: lmillward
Date: Thu Aug 10 19:18:37 2006
New Revision: 116068
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116068
Log:
PR c++/28594
PR c++/28637
PR c++
--- Comment #3 from lmillward at gcc dot gnu dot org 2006-08-10 19:19
---
Subject: Bug 28639
Author: lmillward
Date: Thu Aug 10 19:18:37 2006
New Revision: 116068
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116068
Log:
PR c++/28594
PR c++/28637
PR c++
--- Comment #3 from lmillward at gcc dot gnu dot org 2006-08-10 19:19
---
Subject: Bug 28640
Author: lmillward
Date: Thu Aug 10 19:18:37 2006
New Revision: 116068
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116068
Log:
PR c++/28594
PR c++/28637
PR c++
--- Comment #8 from lmillward at gcc dot gnu dot org 2006-08-10 19:19
---
Subject: Bug 27668
Author: lmillward
Date: Thu Aug 10 19:18:37 2006
New Revision: 116068
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116068
Log:
PR c++/28594
PR c++/28637
PR c++
--- Comment #6 from lmillward at gcc dot gnu dot org 2006-08-10 19:19
---
Subject: Bug 27962
Author: lmillward
Date: Thu Aug 10 19:18:37 2006
New Revision: 116068
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116068
Log:
PR c++/28594
PR c++/28637
PR c++
--- Comment #3 from lmillward at gcc dot gnu dot org 2006-08-10 19:19
---
Subject: Bug 28638
Author: lmillward
Date: Thu Aug 10 19:18:37 2006
New Revision: 116068
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116068
Log:
PR c++/28594
PR c++/28637
PR c++
--- Comment #3 from lmillward at gcc dot gnu dot org 2006-08-10 19:19
---
Subject: Bug 28594
Author: lmillward
Date: Thu Aug 10 19:18:37 2006
New Revision: 116068
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116068
Log:
PR c++/28594
PR c++/28637
PR c++
--- Comment #4 from lmillward at gcc dot gnu dot org 2006-08-10 19:19
---
Subject: Bug 28637
Author: lmillward
Date: Thu Aug 10 19:18:37 2006
New Revision: 116068
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116068
Log:
PR c++/28594
PR c++/28637
PR c++
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-10 18:18 ---
This all comes down to a tree combiner.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
These two testcases should produce equivalent code:
int test(int a, int b)
{
int lt = a < b;
int eq = a == b;
return (lt || eq);
}
int test_(int a, int b)
{
return (a < b || a == b);
}
However, the optimized tree code is:
;; Function test (test)
Analyzing Edge Insertions.
test (a, b)
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-08-10 17:52
---
Here is a real reduced testcase:
struct f
{
f(int a) { t = a; }
int t;
}
const f(1);
-
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #12 from mrs at apple dot com 2006-08-10 16:54 ---
Trivially, one could use turing completeness at compile time to achieve the
desired result. :-) Not that I think that is better than `fixing' this bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4131
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-08-10 16:53
---
(In reply to comment #9)
> Here is a testcase which makes this a regression:
I forgot to say this testcase worked in 3.4.0 but failed in 4.0.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28651
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-08-10 16:44 ---
Here is a testcase which makes this a regression:
extern void abort (void);
int
foo (unsigned int u)
{
unsigned t;
for (t=0;t!=u;t++) ;
return (int)(t + 4) < (int)u;
}
int
main (int argc, char *argv[])
{
uns
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Component|c |middle-en
--- Comment #25 from hjl at lucon dot org 2006-08-10 16:40 ---
It is fixed in 4.2 now.
--
hjl at lucon dot org changed:
What|Removed |Added
Status|REOPENED
Hi,
I'm reporting a definitional problem with the -funsafe-math-optimization flag.
This problem was initially discussed in comments 55-63 of bugzilla 27827. I
will attempt to summarize that discussion here.
Here's the definition of -funsafe-math-optimizations from the manpage:
| -funsafe-m
--- Comment #22 from pinskia at gcc dot gnu dot org 2006-08-10 16:03
---
*** Bug 28681 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-10 16:03 ---
This was fixed in 4.1.0.
*** This bug has been marked as a duplicate of 7874 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
This bug applies to gcc 4.0 and 4.1.
The following code:
--- snip here ---
extern void Assert( const char *file, int linenum, const char *function,
const char *condition, int &ignoreflag);
#define ASSERT(ZZ) \
{ static int ignore = 0; \
if( !ignore && !(ZZ)
--- Comment #63 from paolo dot bonzini at lu dot unisi dot ch 2006-08-10
15:22 ---
Subject: Re: [4.0/4.1 Regression] gcc 4 produces worse
x87 code on all platforms than gcc 3
>> If you want a -freassociate-fp math, open an enhancement PR and somebody
>>
> Ah, you mean like I as
--- Comment #5 from hjl at lucon dot org 2006-08-10 15:21 ---
I can reproduce the hang with a cross compiler from Linux/i686 to Linux/ia64.
It looks like the compiler is miscompiled.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28672
--- Comment #62 from whaley at cs dot utsa dot edu 2006-08-10 15:15 ---
Paolo,
>The IEEE standard mandates particular rules for performing operations on
>infinities, NaNs, signed zeros, denormals, ... The C standard, by
>mandating no reassociation, ensures that you don't mess with NaNs
When I cross compile from Linux/i686 to Linux/ia64 with
--enable-languages=c,c++, Ada compiler is enabled. The problem is
BOOT_LANGUAGES = c ada
in gcc/Makefile. Apparently, it was overriden for native build, but not for
cross build.
--
Summary: --enable-languages=c,c++ for cross c
--- Comment #61 from paolo dot bonzini at lu dot unisi dot ch 2006-08-10
14:28 ---
Subject: Re: [4.0/4.1 Regression] gcc 4 produces worse
x87 code on all platforms than gcc 3
> Making vectorization depend on a flag that says it is allowed to violate IEEE
> is therefore a killer for
--- Comment #60 from whaley at cs dot utsa dot edu 2006-08-10 14:08 ---
Paolo,
Thanks for the explanation of what -funsafe is presently doing.
>You are also confusing -funsafe-math-optimizations with -ffast-math.
No, what I'm doing is reading the man page (the closest thing to a contr
--- Comment #16 from howarth at nitro dot med dot uc dot edu 2006-08-10
13:31 ---
My first attempt to build with this revised patch was unsuccessful...
/sw/src/fink.build/gcc4-4.1.999-20060809/darwin_objdir/./gcc/xgcc
-B/sw/src/fink.build/gcc4-4.1.999-20060809/darwin_objdir/./gcc/
-B/s
Under GCC 4.0.2
This code (friend_bug.cpp)
--
struct A {
friend void func() {}
};
int main() {
func();
}
--
Compiles without any diagnostic.
The system is (uname -a):
Linux andre.localdomain 2.6.11-1.1369_FC4 #1 Thu Jun 2 22:5
5.47.6 Structure-Packing Pragmas
3. #pragma pack(push[,n]) pushes the current alignment setting on an internal
stack and then optionally sets the new alignment.
t.c:
#pragma pack(1)
#pragma pack(push)
gcc t.c
t.c:2: warning: malformed '#pragma pack(push[, id], )' - ignored
It appears #pragma pa
--- Comment #2 from werner dot van dot belle at gmail dot com 2006-08-10
12:25 ---
The bug does not occur without the -g option.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28677
--- Comment #1 from werner dot van dot belle at gmail dot com 2006-08-10
12:20 ---
Created an attachment (id=12057)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12057&action=view)
The preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28677
[EMAIL PROTECTED]:~$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--- Comment #11 from bjoern dot haase at de dot bosch dot com 2006-08-10
12:11 ---
Hi,
here is a much simpler test case for this issue.
Bjoern.
#include
using namespace std;
const complex should_be_in_rodata (42,-42);
complex should_be_in_data (42,-42);
complex should_be_in_bss;
--- Comment #24 from paul dot richard dot thomas at cea dot fr 2006-08-10
12:11 ---
(In reply to comment #23)
> Tonto failed to build again.
HJ
Can we close this again? Steve's patch fixed the problem, as far as I know.
Regards
Paul Thomas
--
http://gcc.gnu.org/bugzilla/show_b
--- Comment #19 from dorit at gcc dot gnu dot org 2006-08-10 12:07 ---
Subject: Bug 26197
Author: dorit
Date: Thu Aug 10 12:07:22 2006
New Revision: 116060
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116060
Log:
PR tree-optimization/26197
* tree-ssa-alias.c (n
--- Comment #3 from tbm at gcc dot gnu dot org 2006-08-10 12:02 ---
I was on gcc 4.2 btw.
--
tbm at gcc dot gnu dot org changed:
What|Removed |Added
Summary|IC
--- Comment #2 from tbm at gcc dot gnu dot org 2006-08-10 12:00 ---
-O3 works here while -O2 fails - but, in any case, confirmed.
--
tbm at gcc dot gnu dot org changed:
What|Removed |Added
---
--
tbm at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |blocker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28672
--- Comment #4 from tbm at gcc dot gnu dot org 2006-08-10 11:53 ---
*** Bug 28676 has been marked as a duplicate of this bug. ***
--
tbm at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from tbm at gcc dot gnu dot org 2006-08-10 11:53 ---
*** This bug has been marked as a duplicate of 28672 ***
--
tbm at gcc dot gnu dot org changed:
What|Removed |Added
--
Since r116031 the compiler is running into an infinite loop in
vt_find_locations while compiling the C++ runtime.
/tmp/cvs/gcc-20060810/Build/./gcc/xgcc -shared-libgcc
-B/tmp/cvs/gcc-20060810/Build/./gcc -nostdinc++
-L/tmp/cvs/gcc-20060810/Build/ia64-suse-linux/libstdc++-v3/src
-L/tmp/cvs/gcc
--- Comment #5 from patchapp at dberlin dot org 2006-08-10 10:15 ---
Subject: Bug number PR28496
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00305.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #14 from pluto at agmk dot net 2006-08-10 09:58 ---
fixed on current 4.1 branch.
--
pluto at agmk dot net changed:
What|Removed |Added
Status|UNCO
--- Comment #13 from pluto at agmk dot net 2006-08-10 09:58 ---
in fact it was a gcc bug.
gcc version 4.1.2 20060530 gives wrong code.
gcc version 4.1.2 20060712 gives correct code.
tree dump shows that gcc-20060530 removes some parts [*] of vector_base
initialization and finally crash
--- Comment #2 from patchapp at dberlin dot org 2006-08-10 09:55 ---
Subject: Bug number PR20886
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00304.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #1 from mkl at pengutronix dot de 2006-08-10 09:10 ---
Created an attachment (id=12056)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12056&action=view)
small testcase to trigger the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28675
We get the following ICE when crosscompiling fbtest from i686-pc-linux-gnu to
arm-ep93xx-linux-gnueabi. -O3 breaks, -O2 works
[EMAIL PROTECTED]:~/pengutronix/ptxdist/bug]$ arm-ep93xx-linux-gnueabi-gcc -c
-Wall
-O3 -fomit-frame-pointer -o minimal.o minimal.c -save-temps -v
Using built-in specs.
T
--- Comment #13 from bonzini at gnu dot org 2006-08-10 08:32 ---
sure, but t1 and t2 die the moment they are assigned back. it would be just a
trick to return in memory, but not make s and c addressable all the way down to
RA.
though i don't remember how big a penalty is if your variab
--- Comment #4 from guohongwen at boco dot com dot cn 2006-08-10 08:28
---
(In reply to comment #3)
> Can you try a newer compiler like say 4.0.2?
i'v resolve it,the problem is i initialize a struct with a static struct,i'm
trying it...
--
guohongwen at boco dot com dot cn changed:
1 - 100 of 115 matches
Mail list logo
