--
What|Removed |Added
Known to fail||4.1.0
Known to work||2.95.4 3.3.5 3.4.5
http://gcc.gnu.org/bugzilla/show_bug
--- Additional Comments From lidaobing at gmail dot com 2005-09-20 07:04
---
See also Debian bug #328939
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=328939
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23975
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-20
07:09 ---
Subject: Bug 18463
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-20 07:09:22
Modified files:
gcc: ChangeLog tree-chrec.c tree-chrec.h
--- Additional Comments From Erwin dot Unruh at fujitsu-siemens dot com
2005-09-20 07:22 ---
Created an attachment (id=9780)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9780&action=view)
complete testcase (corrected)
My first try on the testcase depends on the endianess. S/390 i
enumendianness {littleEndian, hostEndianness, bigEndian};
template
class sBigEndian {
public:
T payload;
};
template
class asBigEndian : public sBigEndian {
public:
operator T() { return payload; }
};
gets you:
~/ootbc/members/src$ g++ foo.cc
foo.cc: In member fu
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org |
Status|NEW
template class foo {
public: foo(T t) {}
};
int main() {
foo(1);
foo(1);
}
gets you:
~/ootbc/members/src$ g++ foo.cc
foo.cc: In function `int main()':
foo.cc:7: error: missing template arguments before '(' token
--
Summary: fails to resolve templated constructor
Product:
The following program doesn't work. It does if I tie to a tuple. I suspect it
should work, but aren't sure
why. It's possible this isn't a bug and is in fact a bug in the TR1 standard,
but I know boost's
implementation of tie and tuple support it. Don't try debugging this unless you
enjoy digg
--- Additional Comments From giovannibajo at libero dot it 2005-09-20
12:34 ---
Yes, this is how C++ works. There is no template argument deduction from
constructors.
--
What|Removed |Added
--- Additional Comments From igodard at pacbell dot net 2005-09-20 12:43
---
Bummer. I wonder why? I suppose the workaround is an inline helper function
wrapping the constructor, plus a couple of calls on the copy constructor...
Ivan
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23
--- Additional Comments From falk at debian dot org 2005-09-20 12:45
---
Slightly simplified test case:
unsigned long f(unsigned long x) { return x * 5445825408751490200UL; }
(compile time 33.49s)
So it's just synth_mult running amok, and this has nothing to do with ivopts.
--
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org |
URL|
--- Additional Comments From falk at debian dot org 2005-09-20 13:01
---
This is also reproducible with 4.0.2 20050913, but not 3.4.5 20050821 (well, it
takes 0.5 seconds there, which also seems quite excessive).
--
What|Removed |Added
--
--- Additional Comments From langel at redhat dot com 2005-09-20 13:26
---
This patch is kind of a problem for tooltips. I am looking into it.
--
What|Removed |Added
--
What|Removed |Added
AssignedTo|abalkiss at redhat dot com |langel at redhat dot com
Status|REOPENED|ASSIGNED
Last reconfirmed|2005-06-1
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-09-20
13:33 ---
This one is reproducible everywhere:
long long f(long long x) { return x * 5445825408751490200ULL; }
--
What|Removed |Added
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-09-20
13:33 ---
k*stridev?[2] cannot be moved more at the moment. The loops looks like
for (k = ...)
for (j = ...)
{
if (i >= i1)
continue;
do
{
tmp = k * stridevx[2];
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-09-20
13:38 ---
no, it's not, sorry for the noise. it "only" does 210 synth_mult calls.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23971
--- Additional Comments From pluto at agmk dot net 2005-09-20 13:49 ---
gccc-3.3.6 builds fine the current 4.1 snapshot.
gcc-4.1.0-20050904 produces broken code during current 4.1 bootstrap.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23894
--- Additional Comments From debian-gcc at lists dot debian dot org
2005-09-20 14:22 ---
down to 475 test failures with 20050919
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00973.html
--
What|Removed |Added
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-20
14:33 ---
This is a dup of bug 21089. But note this is allowed by the C++ standard.
*** This bug has been marked as a duplicate of 21089 ***
--
What|Removed |Added
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-20
14:33 ---
*** Bug 23975 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-20
14:35 ---
Read http://gcc.gnu.org/gcc-3.4/changes.html
In a template definition, unqualified names will no longer find members of a
dependent base (as
specified by [temp.dep]/3 in the C++ standard). For example,
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-20
14:38 ---
Subject: Bug 23663
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-20 14:37:45
Modified files:
gcc/fortran: ChangeLog
gcc/testsuite : C
--- Additional Comments From marcus at jet dot franken dot de 2005-09-20
14:48 ---
any progress here?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22438
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-09-20
14:49 ---
I have pinged the patch today.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22438
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-20
14:50 ---
(In reply to comment #6)
> any progress here?
The patch was just pinged today:
http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01239.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22438
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-20
14:54 ---
Fixed in 4.1.0.
--
What|Removed |Added
Status|ASSIGNED|RESOL
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-20
14:55 ---
CCing Roger since he understands synth_mult.
--
What|Removed |Added
CC|
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-09-20
14:56 ---
Random break stops things typically somewhere inside 140 nested calls in scev
(follow_ssa_edge and friends). I seem to recall there is some backtracking
involved, I will check.
--
What|Remov
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-20
15:06 ---
Subject: Bug 23420
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-20 15:05:33
Modified files:
gcc/fortran: ChangeLog io.c
gcc/testsuite
--- Additional Comments From law at redhat dot com 2005-09-20 15:11 ---
Subject: Re: [4.1 Regression] ICE with -O3
-ftree-vectorize on 4.1.x
On Sun, 2005-09-18 at 15:59 +, steven at gcc dot gnu dot org wrote:
> --- Additional Comments From steven at gcc dot gnu dot org
--- Additional Comments From tobi at gcc dot gnu dot org 2005-09-20 15:27
---
The segfault from numbers 4 and 5 remains.
--
What|Removed |Added
AssignedTo|tobi at gc
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-20
15:29 ---
Subject: Bug 23818
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-20 15:29:42
Modified files:
gcc: ChangeLog tree-stdarg.c
gcc/
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-20
15:41 ---
Subject: Bug 23947
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-20 15:40:58
Modified files:
gcc/cp : ChangeLog
gcc/testsuite : C
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-20
15:56 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-20
15:57 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From evandro at yahoo dot com 2005-09-20 16:06
---
It would be nice if -Wall, -Wstrict-aliasing or -Wstrict-aliasing=2 caught it...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23972
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-20
16:08 ---
>From the dup bug:
Also PR 14024 is the bug for C++ front-end not reporting possible aliasing
violations.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23972
Note, this problem only happens with -thumb and -O2 (eg. nothing, -O, -O1 and -
O3 work fine).
Here's the original snippet of code:
int
mmcsd_read(void * dst, void * src, unsigned int len)
{
int return_val = NETI_OK;
int i = 0;
cyg_mutex_lock(&mmcsd.mutex);
if(!mmcsd.card_i
--
What|Removed |Added
Component|c |target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23980
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-20
16:21 ---
can you provide the preprocessed source?
And does -W -Wall give any warnings?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23980
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org |
Status|NEW
The following code works with previous versions of gcc (tried "3.3.5
20050117" and "4.0.2 20050901"), but fails to compile with "4.1.0
20050919". It works if Base and Derived aren't templates and it works
if I call this->func(t) (which is a simple workaround).
--8<-
int func(
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-20
16:43 ---
Yes the behavior in 4.1.0 is the correct behavior as defined by the C++
standard and its Defect reports.
This is a dup of bug 5660 which was fixed for 4.1.0.
>PS: Sorry if this isn't a bug, I'm not that e
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-20
16:43 ---
*** Bug 23982 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From evandro at yahoo dot com 2005-09-20 16:43
---
-fno-strict-aliasing still doesn't result in the correct code. I agree with
your assesment, but what am I missing?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23972
--- Additional Comments From evandro at yahoo dot com 2005-09-20 16:45
---
Ahem, never mind. My eyes are blury after looking at so much asm code...
Sorry.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23972
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-20
17:00 ---
Subject: Bug 23186
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-20 17:00:22
Modified files:
gcc/testsuite : ChangeLog
gcc/testsuite/g++.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-20
17:16 ---
The difference now is:
:;
sum = MEM[base: (int *) ivtmp.278] * MEM[base: (int *) ivtmp.280] + sum;
k = k + 1;
ivtmp.278 = ivtmp.278 + 4B;
ivtmp.280 = ivtmp.280 + 200B;
if (k != 50) goto ; else goto
--- Additional Comments From Woebbeking at web dot de 2005-09-20 17:21
---
Works for me. I hope VERIFIED is the same as CLOSED.
--
What|Removed |Added
Status|RE
--- Additional Comments From langel at redhat dot com 2005-09-20 17:22
---
Closing this bug. Issue mentioned earlier deals with ToolTipManager, fixed.
--
What|Removed |Added
--- Additional Comments From czimman at bloomberg dot com 2005-09-20 17:25
---
-Wall gives a warning about i not being used, but that's it. We normally
always build with -Wall enabled.
Here's the preprocessed output:
int
mmcsd_read(void * dst, void * src, unsigned int len)
{
int
# TMT.5_729 = V_MAY_DEF ;
# TMT.6_730 = V_MAY_DEF ;
y0_351 = __builtin_altivec_vrsqrtefp (B_350);
Almost all of the altivec builtins could be marked as pure/const and should
cause less VOPS to be
added for altivec code.
--
Summary: the altivec builtins should be marked as pu
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-20
17:26 ---
The other issue is that the altivec builtins are not marked so we think they
can clobber the what the
pointers point to.
--
What|Removed |Added
--
What|Removed |Added
OtherBugsDependingO||14455
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23983
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-20
17:44 ---
Oh, the issue here is that a, b, and ret all could point to the same array
because the type is (float[3])*
or arraryptr in:
typedef float array[3];
typedef array *arraryptr;
If we change ret, a, and b to
cc1plus crashes for the testcase I'll attach later. There is a PLUS_EXPR, the
second operand of which is NULL. setting a breakpoint cgraph_lower_function
shows that the crash happens after cgraph_lower_function is called a second
time;
moreover, the by probing the different addresses where the PL
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-20
17:47 ---
t.c:20: note: not vectorized: mixed data-types
t.c:20: note: can't determine vectorization factor.
Removing flags[i] = true;
we get:
t.c:20: note: not consecutive access
t.c:20: note: not vectorized: compli
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-09-20
17:48 ---
Created an attachment (id=9781)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9781&action=view)
test case
This testcase triggers the bug with mainline gcc from 2005-09-19 18:00 UTC
at optimization lev
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-20
17:51 ---
This is fixed with -funsafe-loop-optimizations but there are still some opions
needing if it should be
on by default at -O2/-O3 or not.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18527
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-20
17:53 ---
Confirmed, a regression from 3.4.0.
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-20
17:55 ---
It is in .t02.original:
((int (*__vtbl_ptr_type) (void) * *) __vtt_parm + )
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23984
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-20
18:04 ---
Here is a slightly reduced testcase:
struct b {
virtual int c (void) = 0;
};
struct d:virtual b {
d (void);
int c (void) ;
};
struct e {
e (b *f);
};
struct g : d, e {
g () : e (this) {}
};
g
--- Additional Comments From bangerth at dealii dot org 2005-09-20 18:28
---
In particular, template arguments are _never_ deduced for types, only for
functions.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23977
--- Additional Comments From bangerth at dealii dot org 2005-09-20 18:31
---
This looks like a duplicate of PR 23896 -- does the patch there help you?
I.e. if you update the compiler to the latest version, does the problem
go away?
W.
--
What|Removed
--- Additional Comments From igodard at pacbell dot net 2005-09-20 18:36
---
So a constructor counts as a type for deduction purposes? I'd always thought of
it as a function, albeit a peculiar kind of one. It's the parentheses I suppose
:-)
Ivan
--
http://gcc.gnu.org/bugzilla/show_
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-20
19:04 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23186
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-09-20
19:06 ---
Confirmed with gcc version 4.1.0 20050919 (experimental) on i686-pc-linux-gnu.
--
What|Removed |Added
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-20
19:10 ---
Subject: Bug 23929
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-20 19:10:45
Modified files:
gcc: ChangeLog tree-ssa-loop-niter.c
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-20
19:18 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From kazu at gcc dot gnu dot org 2005-09-20 19:28
---
On alpha-linux-gnu, synth_mult is called 20 million times.
I've got one idea that might or might not work.
Currently, synth_mult records successful cases in it hash/cache.
That is, if synth_mult determines th
GCC 3.4.3 and 3.4.4 generated wrong code at -O2 and -Os opt level for the
attached testcase. If I user -O1 the test case works fine.
Secondly it also works fine if I specify -O2 -fno-if-convertion2
Thirdly If I comment out
newinfo->fig->shape = *&shape;
line in the testcase it works fine agains
--- Additional Comments From raj dot khem at gmail dot com 2005-09-20
19:31 ---
Created an attachment (id=9782)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9782&action=view)
Failing testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23985
--
What|Removed |Added
Component|middle-end |rtl-optimization
Keywords||wrong-code
http://gcc.gnu.org/bugzilla/show_
--- Additional Comments From raj dot khem at gmail dot com 2005-09-20
19:37 ---
It fails on GCC 3.3.1 similarily.
--
What|Removed |Added
Component|rtl-optimization
--
What|Removed |Added
Component|middle-end |rtl-optimization
Keywords||wrong-code
Known to fail|
--- Additional Comments From joseph at codesourcery dot com 2005-09-20
20:05 ---
Subject: Re: -Wparentheses doesn't catch all assignments used
as truth value
On Mon, 19 Sep 2005, pinskia at gcc dot gnu dot org wrote:
> I could sware this was discussed before in a bug.
Yes. The exis
--- Additional Comments From bangerth at dealii dot org 2005-09-20 20:07
---
A constructor is a special function the name of which is that of the type
to which it belongs. The type's name is that that includes template arguments.
You could also say that the constructor is a function
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-20
20:12 ---
See the thread at
http://gcc.gnu.org/ml/gcc-patches/2004-08/msg01541.html
This is not a bug.
--
What|Removed |Added
-
--- Additional Comments From igodard at pacbell dot net 2005-09-20 20:35
---
Oh yeah - I've fallen into (and reported) that one before. How quickly we
forget!
You know, a "perhaps you meant 'this->foo'?" in the diagnostic ould cut down on
the redundant reports you guys get :-)
Ivan
-
--- Additional Comments From igodard at pacbell dot net 2005-09-20 20:38
---
Many thanks for taking the time for the lengthy explanation. It is deeply
appreciated.
Ivan
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23977
--- Additional Comments From glebius at FreeBSD dot org 2005-09-20 20:43
---
Subject: Re: -Wparentheses doesn't catch all assignments used as truth value
On Tue, Sep 20, 2005 at 08:12:25PM -, pinskia at gcc dot gnu dot org wrote:
p> See the thread at
p> http://gcc.gnu.org/ml/gcc-pa
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-09-20
20:52 ---
(In reply to comment #3)
> A regression hunt on i686-linux showed the failure starting with this patch
> from [EMAIL PROTECTED]:
>
> http://gcc.gnu.org/ml/gcc-cvs/2005-05/msg00640.html
The i386.md x86_sh
--- Additional Comments From janis187 at us dot ibm dot com 2005-09-20
21:28 ---
The ICE begins with these patches (the second adds a missing file for the first)
from bonzini:
http://gcc.gnu.org/ml/gcc-cvs/2005-05/msg00791.html
http://gcc.gnu.org/ml/gcc-cvs/2005-05/msg00792.html
--
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-20
21:48 ---
Subject: Bug 23898
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-20 21:48:37
Modified files:
gcc: ChangeLog bb-reorder.c final.c genatt
--- Additional Comments From pluto at agmk dot net 2005-09-20 21:53 ---
(In reply to comment #2)
> gccc-3.3.6 builds fine the current 4.1 snapshot.
> gcc-4.1.0-20050904 produces broken code during current 4.1 bootstrap.
>
gcc-4.1.0-20050915 bootstraped by gcc-3.3.6 produces
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-20
21:55 ---
Fixed then.
--
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-20
21:59 ---
Fixed in 4.1.0.
--
What|Removed |Added
Status|NEW |RESOL
--
Bug 16996 depends on bug 23898, which changed state.
Bug 23898 Summary: basic block reordering excessively increases code size;
get_uncond_jump_length pessimistic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23898
What|Old Value |New Value
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-20
22:08 ---
Still happens with the mainline: "4.1.0 20050919".
--
What|Removed |Added
Last reconfirmed
--- Additional Comments From kazu at gcc dot gnu dot org 2005-09-20 22:12
---
OK, with my idea I can cut down the number of calls to synth_mult to
1.4 million.
I may be able to improve further by recording the cost in successful cases.
--
What|Removed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-20
22:19 ---
Note at -O1 I cannot reproduce it but at -O2 I could.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19505
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-20
22:26 ---
Fixed on the mainline:
:;
fooc ();
i = i - 1;
if (i != 0) goto ; else goto ;
--
What|Removed |Added
--- Additional Comments From sam at zoy dot org 2005-09-20 22:28 ---
By the way, 4.1.0 fixes the bug on i486-linux-gnu, but on AMD64
(x86_64-linux-gnu) the problem is still present. Tested with a
20050904 snapshot.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23963
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-20
22:29 ---
Fixed on the mainline.
--
What|Removed |Added
Status|NEW
--- Additional Comments From chris at bubblescope dot net 2005-09-20 23:02
---
I'll have a closer look. I think not, as on my compiler boost::tie does work,
it's tr1::tie which doesn't.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23978
fbmmx.c: In function '_cairo_pixman_composite_src_add_8000x8000mmx':
fbmmx.c:2169: error: unable to find a register to spill in class 'MMX_REGS'
fbmmx.c:2169: error: this is the insn:
(insn:HI 168 167 171 12 (set (reg:V8QI 157)
(us_plus:V8QI (mem:V8QI (reg/v/f:SI 4 si [orig:109 src ] [1
--- Additional Comments From pluto at agmk dot net 2005-09-20 23:06 ---
Created an attachment (id=9785)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9785&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23988
1 - 100 of 113 matches
Mail list logo
