--- Comment #5 from ubizjak at gmail dot com 2007-03-02 14:53 ---
Fixed in mainline.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from ubizjak at gmail dot com 2007-03-02 14:54 ---
Fixed in mainline.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from ubizjak at gmail dot com 2007-03-02 15:02 ---
Fixed in mainline. IMO this is not worth to fix on branches due to comment #5.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #4 from ubizjak at gmail dot com 2007-03-02 15:09 ---
Still fails on 4.3.0 mainline.
IMO it would be OK if 'make install' exited with a message that 'make all'
should be run before 'make install' instead of uninformative error abou
--- Comment #2 from ubizjak at gmail dot com 2007-03-02 15:16 ---
Closed as WORKSFORME as RH 8.0 is kind of obsolete (I don't have this OS
anymore).
--
ubizjak at gmail dot com changed:
What|Removed |
--- Comment #13 from ubizjak at gmail dot com 2007-03-02 15:34 ---
Any news about this problem?
Current mainline still has severe problems:
-msse3 -O2 -mfpmath=sse -ffast-math
GCC 4.3 -ffast-math double performance:
ALGORITHM NB REPSTIME MFLOPS
--- Comment #7 from ubizjak at gmail dot com 2007-03-02 15:37 ---
(In reply to comment #6)
> This looks like a straightforward fix to build_common_tree_nodes2.
Is it possible to provide a patch for this? This warning is generated during
povray compilation, and povray is part
--- Comment #1 from ubizjak at gmail dot com 2007-03-02 17:45 ---
*** This bug has been marked as a duplicate of 31019 ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #6 from ubizjak at gmail dot com 2007-03-02 17:45 ---
*** Bug 31028 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31019
--- Comment #1 from ubizjak at gmail dot com 2007-03-09 10:22 ---
This problem is fixed in 4.3.0.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ubizjak at gmail dot com
GCC
--- Comment #10 from ubizjak at gmail dot com 2007-03-09 11:22 ---
(In reply to comment #8)
> Anyway, are there any other "warning" messages like this one? If so, I can
> search my log files.
Yes, the one reported in PR middle-end/30666.
--
http://gcc.
--- Comment #2 from ubizjak at gmail dot com 2007-03-09 18:21 ---
No, this is not a target problem. I have traced the problem down to
reload_cse_simplify(), where insn that loads flags (either test or sahf) gets
cleared. This is highly suspicious part of code (why value is set to 0
--- Comment #3 from ubizjak at gmail dot com 2007-03-10 13:04 ---
(In reply to comment #2)
> No, this is not a target problem. I have traced the problem down to
This _was_ a target problem after all...
Fixed by patch at http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00603.html:
2007
--- Comment #2 from ubizjak at gmail dot com 2007-03-14 13:13 ---
The problem is with TImode *addti3_1 splitter. An immediate is splitted from
TImode into double DImode values and these values are passed to add/addc pair:
(define_split
[(set (match_operand:TI 0 "nonimmediate_op
--- Comment #3 from ubizjak at gmail dot com 2007-03-14 13:42 ---
Prototype patch that fixes the failure:
2007-03-14 Uros Bizjak <[EMAIL PROTECTED]>
* config/i386/i386.md (*addti3_1, *addti3_1 splitter): Use
x86_64_general_operand as operand[2] pre
--- Comment #4 from ubizjak at gmail dot com 2007-03-14 13:43 ---
Created an attachment (id=13205)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13205&action=view)
Patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31167
--- Comment #78 from ubizjak at gmail dot com 2007-03-14 15:01 ---
(In reply to comment #77)
> gfortran -c -O3 -ftree-loop-linear -ftree-vectorize -ffast-math -march=opteron
> -msse2 fparser.f90
>
> /tmp/ccNk6D7G.s: Assembler messages:
> /tmp/ccNk6D7G.s:820: Error: suf
--- Comment #81 from ubizjak at gmail dot com 2007-03-14 15:30 ---
(In reply to comment #79)
> movsd %xmm2, (%rsp)
> fldl(%rsp)
> movsd %xmm1, (%rsp)
> fldl(%rsp)
> fxch%st(1)
> .L120:
> fprem
--- Comment #2 from ubizjak at gmail dot com 2007-03-14 17:38 ---
(In reply to comment #0)
> Examine the definition of isinf closely. It returns -1 for -inf.
But:
NOTE
Note that these functions are obsolete. C99 defines macros isfinite(),
isinf() and isnan() (for
--- Comment #5 from ubizjak at gmail dot com 2007-03-14 18:47 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00947.html.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #2 from ubizjak at gmail dot com 2007-03-15 13:13 ---
(In reply to comment #1)
> Seems to work for me. Any details on the architecture you tested on?
Target: i686-pc-linux-gnu
gcc version 4.3.0 20070315 (experimental)
g++ -O2 -S -ftree-loop-linear pr31183.cc
pr31183
--- Comment #84 from ubizjak at gmail dot com 2007-03-16 11:21 ---
(In reply to comment #83)
> I upgraded trunk, and now the code compiles again with -march=native, but
> crashes as follows:
>
> Program received signal SIGILL, Illegal instruction.
> 0x
--- Comment #87 from ubizjak at gmail dot com 2007-03-16 12:16 ---
(In reply to comment #86)
>
> sorry, the previous post was of the wrong machine... these are the correct
> flags and no (lahf_lm):
> cpu family : 15
> model : 5
> model name
--- Comment #88 from ubizjak at gmail dot com 2007-03-16 12:43 ---
(In reply to comment #83)
> I upgraded trunk, and now the code compiles again with -march=native, but
> crashes as follows:
>
> Program received signal SIGILL, Illegal instruction.
> 0x
--- Comment #17 from ubizjak at gmail dot com 2007-03-17 09:45 ---
(In reply to comment #16)
> As far as I can tell the problem is fixed, at least for Mac OSX 10.3. Thanks
> Richard for your
> patience.
>
> I have just noticed the following oddity with the code:
> [
ent: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ubizjak at gmail dot com
GCC build triplet: x86_64-pc-linux-gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31248
--- Comment #1 from ubizjak at gmail dot com 2007-03-28 12:45 ---
Confirmed on i686-pc-linux-gnu with -O2 -msse2 -ftree-vectorize.
Backtrace:
#0 fancy_abort (file=0x871dab0 "../../gcc-svn/trunk/gcc/tree-data-ref.c",
line=2072, function=0x871eed6 "affine_functi
--- Comment #9 from ubizjak at gmail dot com 2007-04-03 13:32 ---
(In reply to comment #8)
> what's the generated code for -ffast-math? in principle i don't see a reason
> why it should make any difference...
Trying to answer your question, I have played a bit with c
--- Comment #7 from ubizjak at gmail dot com 2007-04-04 08:05 ---
This is the minimal test case for this bug:
--cut here--
extern void foo(void);
double *data;
double test()
{
double sum = 123.321;
int i;
for (i=0; i<4; i++)
sum += data[i];
foo();
foo();
return
--- Comment #8 from ubizjak at gmail dot com 2007-04-04 09:21 ---
The difference is in CALLER_SAVE_PROFITALBLE condition. The pseudo that holds
sum is referenced 6 times. When only one foo() is called, default
CALLER_SAVE_PROFITABLE condition causes RA to allocate call-clobbered
--- Comment #3 from ubizjak at gmail dot com 2007-04-05 06:38 ---
Perhaps hppa64 needs the same change to libgomp.exp as in
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01497.html ?
These tests all fail because shared libgcc library is not found.
--
ubizjak at gmail dot com changed
--- Comment #1 from ubizjak at gmail dot com 2007-04-05 07:15 ---
(In reply to comment #0)
> 1. Is ix86_binary_operator_ok needed here?
Yes, it prevents expander and combiner to create two mem operands (please note
that reload can also resolve this case by itself, but some
--- Comment #3 from ubizjak at gmail dot com 2007-04-05 08:48 ---
> There is no corresponding define_expand for this pattern. Many define_insn
> patterns without define_expand don't call ix86_binary_operator_ok. Will that
> be a problem?
Those are sse builtins and ar
--- Comment #4 from ubizjak at gmail dot com 2007-04-05 09:13 ---
(In reply to comment #3)
> There is indeed a pattern without this check - sse2_pmaddwd.
> Due to %, it is commutative, so check for PLUS of V8HI mode would be OK.
Please also change operands 1 and 2 of sdot_pr
--- Comment #12 from ubizjak at gmail dot com 2007-04-05 11:00 ---
(In reply to comment #11)
> with -msse compile flag. Note different variable suffixes that create
> different
> sort order. This is (IMO) due to fact that -msse enables lots of additional
> __builtin func
--- Comment #11 from ubizjak at gmail dot com 2007-04-05 10:58 ---
(In reply to comment #10)
> I would look at the lreg output, which contains the results of regclass.
No, the difference is due to ssa pass that generates:
# v1z_10 = PHI
# v1y_9 = PHI
# v1x_8 = PHI
#
--- Comment #4 from ubizjak at gmail dot com 2007-04-05 12:21 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #4 from ubizjak at gmail dot com 2007-04-05 12:29 ---
(In reply to comment #2)
> To implement this optimization, some support from assembler is needed. When
> displacement overflows 8bit, assembler should substitute "jecxz" with
> equivalent "test/
--- Comment #7 from ubizjak at gmail dot com 2007-04-05 13:06 ---
Not marked as a regression on branches, so fixed.
(The patch from Comment #6 applies cleanly on all branches. It is up to RM to
decide if this can still go into 4.1.2 and 4.2.)
--
ubizjak at gmail dot com changed
--- Comment #6 from ubizjak at gmail dot com 2007-04-05 16:27 ---
(In reply to comment #5)
> Can we compute the displacement reliable enough to say that it is smaller than
> some other number (e.g. 64)?
Good idea!
The (untested) patch that handles SImode compares is a
--- Comment #18 from ubizjak at gmail dot com 2007-04-05 16:39 ---
(In reply to comment #17)
> Is the output from .optimized different? (once the ssa versions numbers have
> been stripped). Those PHIs should be irrelevant, the question is whether the
> different versionin
--- Comment #6 from ubizjak at gmail dot com 2007-04-05 16:48 ---
(In reply to comment #5)
> So anothe word is those patterns are used by ix86_expand_binop_builtin()
> and won't be generated automatically. Will be "sse2_umulv2siv2di3"
> generated automaticall
--- Comment #20 from ubizjak at gmail dot com 2007-04-05 19:39 ---
(In reply to comment #19)
> what are you using for a compiler? Im using a mainline from mid march, and
gcc version 4.3.0 20070404 (experimental) on i686-pc-linux-gnu
with
> it, my .optimized files diff exact
--- Comment #9 from ubizjak at gmail dot com 2007-04-05 19:50 ---
(In reply to comment #8)
> > Please also change operands 1 and 2 of sdot_prodv8hi expander to
> > register_operand to avoid further suprises.
> >
>
> I am not sure if there is an issue since op0
--- Comment #21 from ubizjak at gmail dot com 2007-04-06 07:37 ---
Strange things happen.
I have fully removed gcc build directory and bootstrapped gcc from scratch. To
my suprise, the difference with -msse and without -msse is now gone and
optimized dumps are now the same. For
--- Comment #2 from ubizjak at gmail dot com 2007-04-12 15:53 ---
(In reply to comment #0)
> The complex value is naively calculated as:
> sqrt( (_Real_ z)*(_Real_ z) + (_Imag_ z)*(_Imag_ z) )
>
> However, since the value is squared afterwards, the square root c
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ssemmx
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ubizjak at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triple
--- Comment #1 from ubizjak at gmail dot com 2007-04-16 08:02 ---
Proposed patch to macroize these functions in emmintrin.h
(http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00096.html).
Please note that some other intrinsic functions, such as _mm_shuffle_ps() are
defined as macro as well
--- Comment #8 from ubizjak at gmail dot com 2007-04-21 19:43 ---
Patch for double<->float conversions at
http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01346.html.
--
ubizjak at gmail dot com changed:
What|Removed
--- Comment #10 from ubizjak at gmail dot com 2007-04-22 20:08 ---
float->double and double->float conversions are new vectorized. For a slightly
different test:
--cut here--
void test_fp (float *a, double *b)
{
int i;
for (i = 0; i < 4; i++)
b[i] = (double) a[i]
--- Comment #11 from ubizjak at gmail dot com 2007-04-22 20:10 ---
(In reply to comment #10)
> float->double and double->float conversions are new vectorized. For a slightly
> different test:
The test is actually:
--cut here--
float a[16];
int b[16];
double c[16];
void t
--- Comment #1 from ubizjak at gmail dot com 2007-04-26 08:22 ---
(In reply to comment #0)
> __asm__ __volatile__("fptan; fdivp;fchs;": "=&t"(tmpB):"f"(r));
These constraints are wrong. You need:
__asm__ __volatile__ ("fptan; fdivp;fchs;&
--- Comment #2 from ubizjak at gmail dot com 2007-04-26 11:20 ---
This bug is due to my commit:
http://gcc.gnu.org/ml/gcc-cvs/2007-04/msg00657.html
This patch introduces "vec_unpacks_hi_v4sf" and "vec_unpacks_lo_v4sf" to sse.md
an these patterns trigger generi
--- Comment #3 from ubizjak at gmail dot com 2007-04-26 11:23 ---
(In reply to comment #1)
> Might be related to the similar PR 31699.
No, because PR 31699 is triggered by -ftree-vectorize.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31697
--- Comment #5 from ubizjak at gmail dot com 2007-04-27 11:35 ---
(In reply to comment #3)
> Created an attachment (id=13450)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13450&action=view) [edit]
This patch fixes the testcase from comment #2 and Polyhedron rnflow
--- Comment #6 from ubizjak at gmail dot com 2007-07-14 14:04 ---
(In reply to comment #5)
> > This is two more movdqa then the hand-written code in CallSumDeltas3.
>
> paddd %xmm1, %xmm0 (2)
> movdqa %xmm0, %xmm1 (2)
> m
--- Comment #14 from ubizjak at gmail dot com 2007-07-16 18:47 ---
(In reply to comment #13)
> revision 125920 works.
> Revision 125925 is bad:
17:06 r125925 - in /trunk/gcc: ChangeLog testsuite/gc... spop
16:25 r125924 - in /trunk/gcc: ChangeLog df-problems.czad
--- Comment #5 from ubizjak at gmail dot com 2007-07-18 12:05 ---
The problem is in cptrf2 function when both -mfpmath=387 and -ftree-vectorize
are used.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31897
--- Comment #3 from ubizjak at gmail dot com 2007-07-19 13:56 ---
(In reply to comment #1)
> It fails while trying to delete a basic-block that is unnecessary after
> tree-if-conversion (on the dump command before the deletion).
No, it ICEs when empty BB is to be pretty-prin
--- Comment #2 from ubizjak at gmail dot com 2007-08-16 06:50 ---
(In reply to comment #1)
> I saw it on both Linux/ia32 and Linux/x86-64.
-O2 is needed to reliably fold these testcases.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33082
--- Comment #3 from ubizjak at gmail dot com 2007-08-16 07:12 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2007-08/msg00982.html
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #5 from ubizjak at gmail dot com 2007-08-16 18:33 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #13 from ubizjak at gmail dot com 2007-08-19 18:03 ---
(In reply to comment #12)
> if (sum == 0) sum = 1;
>
> Additionally, the resulting asm seems to be a bit stupid:
>
> testl %edx, %edx
> movl$1, %eax
>
--- Comment #14 from ubizjak at gmail dot com 2007-08-23 08:33 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01513.html.
This is target-only patch that fakes fcomi instructions. It doesn't need to
rescan insn stream and creates the same output as in Comment #8. It
--- Comment #16 from ubizjak at gmail dot com 2007-08-23 14:26 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from ubizjak at gmail dot com 2007-08-23 14:28 ---
(In reply to comment #7)
> Created an attachment (id=13911)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13911&action=view) [edit]
> Updated patch with test case a bug fix.
>
> I've
--- Comment #2 from ubizjak at gmail dot com 2007-08-24 06:04 ---
This patch
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01634.html
causes gcc.target/i386/cmov4.c regression.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #7 from ubizjak at gmail dot com 2007-08-24 10:42 ---
Sometimes it is neccessary to check where you clear a structure.
Attached patch fixes this PR.
Index: ifcvt.c
===
--- ifcvt.c (revision 127761
--- Comment #9 from ubizjak at gmail dot com 2007-08-24 11:06 ---
(In reply to comment #6)
> Re. comment #4 -- as if it is constructive to annoy me by CC-ing me on
> gcc-patches and in this PR when I've made it pretty damn clear that I don't
> want to work on gcc a
--- Comment #1 from ubizjak at gmail dot com 2007-08-25 10:18 ---
>From r127766 it is evident that mentioned commit fixed obvious problem that has
re-enabled a lot of ifcvt functionality. The bug is in this re-enabled part of
ifcvt. But we need a testcase here.
--
h
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ubizjak at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-li
--- Comment #1 from ubizjak at gmail dot com 2007-08-25 12:39 ---
There is a small problem in combine. It tries to combine insn 17 and 18, but:
Failed to match this instruction:
(set (reg:DF 58 [ D.1658 ])
(const_double:DF -1.0e+0 [-0x0.8p+1]))
Failed to match this instruction
--- Comment #4 from ubizjak at gmail dot com 2007-08-26 10:56 ---
C testcase:
--cut here--
extern void abort (void);
enum Status
{
P_ON_LOWER = -4,
P_ON_UPPER = -2,
P_FREE = -1
};
void
foo (enum Status *stat, double newUpper, double lower, double max)
{
if (newUpper >=
--- Comment #5 from ubizjak at gmail dot com 2007-08-26 12:55 ---
The problem is in the way ifcvt handles IFs without ELSE blocks. Compiling c
testcase with -O2 -ffast-math (on x86_64 target), we hit check for else_bb in
noce_process_if_block(). We continue into line 2196 of ifcvt.c
--- Comment #3 from ubizjak at gmail dot com 2007-08-27 20:22 ---
Patch and the description of the problem at
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01880.html.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #10 from ubizjak at gmail dot com 2007-08-28 09:57 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--
ubizjak at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32661
--- Comment #7 from ubizjak at gmail dot com 2007-08-28 10:04 ---
This is fixed in current mainline, gcc version 4.3.0 20070827 produces:
foo:
pushl %ebx
movl8(%esp), %ebx
xorl%edx, %edx
movl12(%esp), %ecx
.p2align 4,,7
--- Comment #8 from ubizjak at gmail dot com 2007-08-28 10:08 ---
FIxed by http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00354.html
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #3 from ubizjak at gmail dot com 2007-08-28 12:02 ---
Current mainline [GCC: (GNU) 4.3.0 20070828] generates:
test:
.LFB2:
xorl%eax, %eax
xorl%edx, %edx
.align 16
.L2:
addbtable(%rdx), %al
addq$1, %rdx
cmpq
--- Comment #2 from ubizjak at gmail dot com 2007-09-03 20:07 ---
Confirmed on x86_64 (-O0), RECORD_TYPE is entering fold_convert() from
gfc_trans_scalar_assign():
(gdb) bt
#0 fancy_abort (file=0xb322f0 "../../gcc-svn/trunk/gcc/fold-const.c",
line=2626,
functio
--- Comment #5 from ubizjak at gmail dot com 2007-09-04 10:10 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from ubizjak at gmail dot com 2007-09-04 19:03 ---
(In reply to comment #3)
> Uros, do you think we could, in the fold_convert() switch on TREE_CODE(type),
> add a case for RECORD_TYPE similar to VECTOR_TYPE: assert that both
> RECORD_TYPEs have the same size,
--- Comment #2 from ubizjak at gmail dot com 2007-09-05 17:46 ---
Fixed by http://gcc.gnu.org/viewcvs?view=rev&revision=128141
--
ubizjak at gmail dot com changed:
What|Removed |A
--- Comment #5 from ubizjak at gmail dot com 2007-09-06 14:21 ---
I'll take this PR.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Assig
--- Comment #1 from ubizjak at gmail dot com 2007-09-06 16:34 ---
(In reply to comment #0)
> When the testcase gcc.dg/tree-ssa/predcom-3.c is compiled with vectorization
> it
> ICes when the dataref analysis called from vectorizer:
I can't get the compiler (curren
--- Comment #4 from ubizjak at gmail dot com 2007-09-07 10:42 ---
Similar to PR26449, which was _not_ fixed properly (so please don't mark this
one as a duplicate). The problem that was misteriously fixed for one testcase
just resurfaced again. Some info is also in PR32123.
Pro
--- Comment #7 from ubizjak at gmail dot com 2007-09-07 10:20 ---
Fixed on mainline.
--
ubizjak at gmail dot com changed:
What|Removed |Added
URL
--- Comment #2 from ubizjak at gmail dot com 2007-09-07 09:28 ---
Also ICEs on i686-pc-linux-gnu with -msse2.
The problem is again in:
--cut here--
rtx
expand_simple_binop (enum machine_mode mode, enum rtx_code code, rtx op0,
rtx op1, rtx target, int unsignedp
--- Comment #15 from ubizjak at gmail dot com 2007-09-08 11:35 ---
Reopened. Ther is really no magic here.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #17 from ubizjak at gmail dot com 2007-09-08 11:51 ---
The testcase from comment #11 was added to the testsuite, but let's keep this
PR resolved as WORKSFORME for now. Please note that force_operand() will still
ICE for optabs with no handler.
--
ubizjak at gmail do
--- Comment #6 from ubizjak at gmail dot com 2007-09-08 11:52 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
URL
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ubizjak at gmail dot com
GCC build triplet: x86_64-pc-linux-gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33353
--- Comment #2 from ubizjak at gmail dot com 2007-09-10 05:35 ---
Confirmed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #3 from ubizjak at gmail dot com 2007-09-10 06:32 ---
A 64-bit compiler is required. The problem is, that gcc creates a vector shift
constant for vector shift instruction, without checking if optab can take
vector argument.
This one will also create wrong operand for x86_64
--- Comment #5 from ubizjak at gmail dot com 2007-09-10 12:12 ---
Some additional discussion (with the fix to SLP vectorizer in a followup) at
http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00859.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33369
--- Comment #2 from ubizjak at gmail dot com 2007-09-11 14:45 ---
Could be fixed by http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00976.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33390
--- Comment #4 from ubizjak at gmail dot com 2007-09-12 06:50 ---
Fixed by http://gcc.gnu.org/ml/gcc-cvs/2007-09/msg00364.html
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #6 from ubizjak at gmail dot com 2007-09-12 06:52 ---
Middle-end was fixed by http://gcc.gnu.org/ml/gcc-cvs/2007-09/msg00406.html
--
ubizjak at gmail dot com changed:
What|Removed |Added
301 - 400 of 6742 matches
Mail list logo
