--- Comment #10 from ubizjak at gmail dot com 2007-09-12 13:41 ---
(In reply to comment #9)
> This still happens with GCC 4.3 when trying to bootstrap with BOOT_CFLAGS='-O2
> -g -fomit-frame-pointer -masm=intel' and it blocks me from working on bug
> 29493.
>
--- Comment #2 from ubizjak at gmail dot com 2007-09-13 06:32 ---
(In reply to comment #0)
> $ g++ -c -O2 -g -fPIC -c libkformulalib_la.all_cc.iiIn file included from
> libkformulalib_la.all_cc.cc:45:/scratch/packages/lpia/tmp/koffice-1.6.3/./lib/kformula/formulacursor.cc:
>
--- Comment #4 from ubizjak at gmail dot com 2007-09-13 09:26 ---
(In reply to comment #3)
> the compiler is configure with --with-arch=i686 --with-tune=i586 i686-linux
> I can reproduce it with -march=i686, not with -march=i486.
Still no luck there to reproduce segfault. Thes
--- Comment #5 from ubizjak at gmail dot com 2007-09-13 09:28 ---
(In reply to comment #4)
> 1. Configured latest SVN gcc in _clean_ build dir (on i686-pc-linux-gnu) using
> ../gcc-svn/trunk/configure --with-mpfr=/usr/local --enable-languages=c,c++
> --with-march=i686 --with-
--- Comment #6 from ubizjak at gmail dot com 2007-09-13 12:26 ---
(In reply to comment #5)
> > 1. Configured latest SVN gcc in _clean_ build dir (on i686-pc-linux-gnu)
> > using
> > ../gcc-svn/trunk/configure --with-mpfr=/usr/local --enable-languages=c,c++
> >
--- Comment #18 from ubizjak at gmail dot com 2007-09-14 05:41 ---
*** Bug 33428 has been marked as a duplicate of this bug. ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #1 from ubizjak at gmail dot com 2007-09-14 05:41 ---
*** This bug has been marked as a duplicate of 26449 ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #19 from ubizjak at gmail dot com 2007-09-14 05:49 ---
Zdenek, the fix in Comment #5 is wrong (please look at Comment #11 why), as
cofirmed by a couple of dupes. From PR 33428:
gcc.c-torture/execute/loop-15.c fails with -O1 -ftree-vectorize (x86_64):
loop-15.c: In function
--- Comment #2 from ubizjak at gmail dot com 2007-09-14 19:27 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
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
--- Comment #22 from ubizjak at gmail dot com 2007-09-17 16:43 ---
Fixed in mainline, still (latent) present on 4.2.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #3 from ubizjak at gmail dot com 2007-09-18 13:48 ---
Insn constraint for following insn should be fixed:
(define_insn "*floatdi2_i387"
[(set (match_operand:MODEF 0 "register_operand" "=f,f")
(float:MODEF
(match_operand:DI
--- Comment #2 from ubizjak at gmail dot com 2007-09-18 13:40 ---
Caused by X86_USE_VECTOR_CONVERTS or X86_TUNE_INTER_UNIT_CONVERSIONS patch.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #4 from ubizjak at gmail dot com 2007-09-18 14:03 ---
Sorry, this is already fixed in latest SVN.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #1 from ubizjak at gmail dot com 2007-09-19 06:20 ---
I'll backport http://gcc.gnu.org/viewcvs?view=rev&revision=128328 from PR
target/33369 to fix this issue.
*** This bug has been marked as a duplicate of 33369 ***
--
ubizjak at gmail dot com changed:
--- Comment #7 from ubizjak at gmail dot com 2007-09-19 06:20 ---
*** Bug 33482 has been marked as a duplicate of this bug. ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #8 from ubizjak at gmail dot com 2007-09-20 06:49 ---
I can't confirm the failure (make check from zlib works OK for me), but there
is some suspicious code in inflate_fast(). When compiling (to be attached)
preprocessed testcase (using -O2 -msse2 -ftree-vectorize on i68
--- Comment #9 from ubizjak at gmail dot com 2007-09-20 06:51 ---
Created an attachment (id=14226)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14226&action=view)
Preprocessed inffast.c. Compile with -O2 -msse2 -ftree-vectorize
--
http://gcc.gnu.org/bugzilla/show_bug
--- Comment #11 from ubizjak at gmail dot com 2007-09-20 11:58 ---
I hope that following testcase can be of some use to somebody...
--cut here--
void __attribute__((noinline))
inflate_fast (unsigned char *from, unsigned char *out, unsigned int len)
{
while (len >
--- Comment #12 from ubizjak at gmail dot com 2007-09-22 10:26 ---
(In reply to comment #10)
> Created an attachment (id=14228)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14228&action=view) [edit]
> zlib testcase(zlib's inftrees.c)
Sorry, I can't repr
--- Comment #7 from ubizjak at gmail dot com 2007-09-24 12:39 ---
Fixed by http://gcc.gnu.org/viewcvs?view=rev&revision=128710:
2007-09-24 Kai Tietz <[EMAIL PROTECTED]>
PR middle-end/33472
* config/i386/i386.c (return_in_memory_ms_64): Handle return
--- Comment #5 from ubizjak at gmail dot com 2007-09-25 13:58 ---
(In reply to comment #1)
> #define add_ss(sh, sl, ah, al, bh, bl) \
> __asm__ ("addq %5,%q1\n\tadcq %3,%q0" \
>: &
--- Comment #7 from ubizjak at gmail dot com 2007-09-25 14:29 ---
(In reply to comment #6)
> I think that both version ought to work.
There is a comment in the '%' documentation:
GCC can only handle one commutative pair in an asm; if you use
more, the comp
--- Comment #10 from ubizjak at gmail dot com 2007-09-25 17:53 ---
(In reply to comment #8)
> Right, but then it is gmp (the subject of this PR) who's right and gcc
> who's wrong. You said the other way round. :-)
;)
My conclusion is based on the generated code, whe
--- Comment #11 from ubizjak at gmail dot com 2007-09-25 18:48 ---
The fact that "%0" version produces correct code is simply due to strtoul in
match_asm_constraints_1, where "%0" is not recognized as a valid string for
conversion and further processing of input c
--- Comment #12 from ubizjak at gmail dot com 2007-09-25 18:57 ---
(In reply to comment #1)
> marking %0 early-clobbered fixes the problem.
Please look at comment #7.
Confirmed as a 4.3 regression, something is wrong in match_asm_constraints_1.
--
ubizjak at gmail dot
--- Comment #13 from ubizjak at gmail dot com 2007-09-25 19:29 ---
(In reply to comment #12)
> > marking %0 early-clobbered fixes the problem.
> Please look at comment #7.
I think I need some sleep. I was thinking of comment #11.
--
http://gcc.gnu.org/bugzilla/show_b
--- Comment #2 from ubizjak at gmail dot com 2007-09-26 08:53 ---
The testcase from comment #1 is fixed:
test_c:
subl$16, %esp
movl24(%esp), %eax
mull20(%esp)
movl%eax, 8(%esp)
movl%edx, 12(%esp)
addl$16, %esp
--- Comment #1 from ubizjak at gmail dot com 2007-09-26 12:00 ---
(In reply to comment #0)
> (Notice the extra lines between the call to _sinf and the leave.)
-O2 will remove these lines (as well as the lines above _sinf):
BTW: Could you check if _sinf returns values in %xmm0
--- Comment #21 from ubizjak at gmail dot com 2007-09-27 19:59 ---
(In reply to comment #19)
> Have a patch on http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01968.html .
> Fixes also the reload failure on x86 -O2 -fPIC on this testcase (which hits
> glibc):
Do we need a sol
--- Comment #4 from ubizjak at gmail dot com 2007-09-30 10:03 ---
segfaults with -ftree-vectorize in SLP.
reduced testcase:
--cut here--
typedef unsigned char uint8_t;
typedef unsigned short uint16_t;
void
rgb15to24_C (const uint8_t * src, uint8_t * dst, long src_size)
{
const
--- Comment #5 from ubizjak at gmail dot com 2007-09-30 10:28 ---
Patch in testing:
--cut here--
Index: tree-vect-analyze.c
===
--- tree-vect-analyze.c (revision 128890)
+++ tree-vect-analyze.c (working copy)
@@ -2696,6
--- Comment #9 from ubizjak at gmail dot com 2007-09-30 12:47 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
URL
--- Comment #4 from ubizjak at gmail dot com 2007-10-03 15:43 ---
Please provide enough sources to create an _executable_ that shows the failure.
We are dealing with runtime failure here.
A _short_ testcase (<30 lines) is nice to have, so all non-related parts should
be remo
--- Comment #6 from ubizjak at gmail dot com 2007-10-04 06:48 ---
> And as I told in the bug report, inserting or deleting code suddenly
> let the issue vanish. I already tried to reduce this code with the
> result that removing dead code fixed the miscompilation.
If this is
--- Comment #1 from ubizjak at gmail dot com 2007-10-05 06:05 ---
Will be fixed on trunk by
http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00269.html
*** This bug has been marked as a duplicate of 11001 ***
--
ubizjak at gmail dot com changed:
What|Removed
--- Comment #12 from ubizjak at gmail dot com 2007-10-05 06:05 ---
*** Bug 33663 has been marked as a duplicate of this bug. ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #9 from ubizjak at gmail dot com 2007-10-05 10:47 ---
> Hope this helps.
Sure, I've got the problem. The problem is actually in RTL optimization, where
dse1 pass removes wrong insn.
Suprisingly, the problem is in line 61 of comunpack.f:
--> bscale = 2.0**real
--- Comment #10 from ubizjak at gmail dot com 2007-10-05 11:40 ---
(In reply to comment #9)
> This is wrong. dse1 pass should _not_ remove (insn 1312). (insn 1322) is
> storing to the same address as (insn 1312), but we have a call to powf in
> between, so new store insn doe
--- Comment #16 from ubizjak at gmail dot com 2007-10-06 06:49 ---
(In reply to comment #14)
> The testcase works for me, that is, it produces the expected output good.out.
Uh, you have to un-comment the line 315 of the comunpack.f test. The testcase,
as attached, produces good c
--- Comment #19 from ubizjak at gmail dot com 2007-10-06 19:58 ---
In dse.c, scan_insn(), we have:
if ((GET_CODE (PATTERN (insn)) == CLOBBER)
|| volatile_refs_p (PATTERN (insn))
|| (flag_non_call_exceptions && may_trap_p (PATTERN (insn)))
|| (RTX_FRAME_R
--- Comment #21 from ubizjak at gmail dot com 2007-10-08 08:56 ---
The problem is, that we don't have correct REG_DEP_TRUE expr of the call to
powf after we have pushed ebp+const into temp register.
I'm testing following patch to explow.c:
Index
--- Comment #22 from ubizjak at gmail dot com 2007-10-08 12:15 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00420.html
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #11 from ubizjak at gmail dot com 2007-10-10 07:59 ---
(In reply to comment #9)
> Revision 128957 causes this regression.
I can confirm that r128956 bootstraps OK when configured with
--build=i386-pc-linux-gnu. Also, r128956 compiles and runs testcase from
comment
function for same arguments
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ubizjak at gmail dot com
GCC
--- Comment #3 from ubizjak at gmail dot com 2007-10-10 20:58 ---
Revision 129215 does not fail anymore. I'll add a testcase to the testsuite.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33500
--- Comment #5 from ubizjak at gmail dot com 2007-10-11 05:20 ---
Closed as fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|NEW
--- Comment #26 from ubizjak at gmail dot com 2007-10-11 05:48 ---
Updated patch URL to http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00593.html
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #19 from ubizjak at gmail dot com 2007-10-11 05:58 ---
(In reply to comment #18)
> I'm appear to be seeing the same thing trying to build 445.gobmk from cpu2006
> on PowerPC.
Also fails on x86_64-pc-linux-gnu, Revision: 129224. Compiles OK for
i686-pc-linux
--- Comment #9 from ubizjak at gmail dot com 2007-10-11 10:32 ---
(In reply to comment #3)
> int bar (char *s)
> {
> return foo (strlen(s));
> }
The testcase above fails with AREG spill failure. The testcase below fails with
DIREG spill failure:
int bar (int x, long
--- Comment #1 from ubizjak at gmail dot com 2007-10-12 06:11 ---
Also fails on i686-*-*, "-O2 -ftree-vectorize" _without_ -msse2.
--
ubizjak at gmail dot com changed:
What|Removed
--- Comment #2 from ubizjak at gmail dot com 2007-10-12 06:25 ---
I'm testing this patch:
--cut here--
Index: tree-vect-transform.c
===
--- tree-vect-transform.c (revision 129251)
+++ tree-vect-transf
--- Comment #4 from ubizjak at gmail dot com 2007-10-12 09:08 ---
Fixed.
[Let's see if this patch also fixes 174.gcc PEAK failure at
http://vmakarov.fedorapeople.org/spec/index.html]
--
ubizjak at gmail dot com changed:
What|Removed |
--
ubizjak at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33742
--- Comment #3 from ubizjak at gmail dot com 2007-10-12 10:16 ---
*** Bug 31024 has been marked as a duplicate of this bug. ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #1 from ubizjak at gmail dot com 2007-10-12 10:16 ---
*** This bug has been marked as a duplicate of 23449 ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
: unassigned at gcc dot gnu dot org
ReportedBy: ubizjak at gmail dot com
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33761
--- Comment #14 from ubizjak at gmail dot com 2007-10-14 09:36 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|NEW
--- Comment #4 from ubizjak at gmail dot com 2007-10-17 07:08 ---
Patch in testing.
--
ubizjak at gmail dot com changed:
What|Removed |Added
AssignedTo
--- Comment #2 from ubizjak at gmail dot com 2007-10-17 09:10 ---
(In reply to comment #1)
> Since this is using -ffast-math, i suspect this is not a bug.
By adding a print before the condition (line 6372), it looks that something
goes seriously wrong:
gfortran -O2:
cpu time
--- Comment #3 from ubizjak at gmail dot com 2007-10-17 09:11 ---
Confirmed with plain -O2 -ffast-math on i686-pc-linux-gnu.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #4 from ubizjak at gmail dot com 2007-10-17 10:23 ---
Bisection points to r129350:
http://gcc.gnu.org/viewcvs?view=rev&revision=129350
PR tree-optimization/33619
* tree-ssa-ter.c (is_replaceable_p): Return false for all
calls.
* gc
--- Comment #8 from ubizjak at gmail dot com 2007-10-17 11:40 ---
(In reply to comment #6)
> Also what happens if you use -ffloat-store ?
-O2 -ffast-math -ffloat-store works OK...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33794
--- Comment #7 from ubizjak at gmail dot com 2007-10-17 11:38 ---
(In reply to comment #5)
There are (many!) changes of type:
- D.6241 = __builtin_sqrt (receive_coil_1.self_ind * transmit_coil.self_ind);
- coil_coil_mutuals[0] = coil_coil_mutuals[0] / D.6241;
+ coil_coil_mutuals[0
--- Comment #10 from ubizjak at gmail dot com 2007-10-17 12:28 ---
(In reply to comment #9)
I don't want to claim excess precision problems here. I was trying to debug
self_ind_cir_coil procedure, as it looks that the problem is in calculation of
self_r output.
The input to
--- Comment #11 from ubizjak at gmail dot com 2007-10-17 12:39 ---
The problem is somewhere around line 212 in induct.f90. Adding some debug code
at the end of the function:
...
!evaluate self-inductance
!
self_l = (mu * turns**2 * l**2 * 2.0_longreal * r)/3.0_longreal
--- Comment #12 from ubizjak at gmail dot com 2007-10-17 13:57 ---
Well, the problem here is that swap insn is not emitted before x87 fptan.
It is actually my fault (UNSPEC_TAN handling is a bit wrong), the problem is
only exposed by Jakub's patch.
So, mine.
--
ubizjak at gmai
--- Comment #13 from ubizjak at gmail dot com 2007-10-17 14:31 ---
Proposed patch in testing:
Index: reg-stack.c
===
--- reg-stack.c (revision 129402)
+++ reg-stack.c (working copy)
@@ -1085,11 +1085,13 @@
special
--- Comment #16 from ubizjak at gmail dot com 2007-10-17 17:11 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from ubizjak at gmail dot com 2007-10-18 05:26 ---
Testcase?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33804
--- Comment #9 from ubizjak at gmail dot com 2007-10-18 06:33 ---
(In reply to comment #8)
> > Icc generates:
> >0: 66 0f 6e cf movd %edi,%xmm1
> >4: 66 0f f2 c1 pslld %xmm1,%xmm0
>
> Right, that's what icc's
--- Comment #11 from ubizjak at gmail dot com 2007-10-18 09:14 ---
Fixed for 4.2.3 and 4.3.0.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status
--- Comment #1 from ubizjak at gmail dot com 2007-10-18 12:18 ---
What about -ffloat-store?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33809
--- Comment #7 from ubizjak at gmail dot com 2007-10-19 17:53 ---
(In reply to comment #6)
> It is little bit sick, but what about implying -mfpmath=sse when
> -ftree-vectorize is used and SSE is available?
Then you will hit Core2 Duo, that shows the opposite in 32bit and 64bi
--- Comment #2 from ubizjak at gmail dot com 2008-08-13 13:47 ---
(In reply to comment #0)
> Here, the code that initializes xmm1 (also the xmm1 in my pseudo-code above):
>
> 107e: 48 8b 44 24 38 mov0x38(%rsp),%rax
> 1083: 48 83 c0 08
--- Comment #6 from ubizjak at gmail dot com 2008-08-14 11:34 ---
(In reply to comment #5)
> Created an attachment (id=16068)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16068&action=view) [edit]
> Remove broken alternatives using movlps for vec_concatv2di(_rex) ins
--- Comment #11 from ubizjak at gmail dot com 2008-08-17 17:24 ---
Fixed for 4.3.2.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Severity|critical
--- Comment #1 from ubizjak at gmail dot com 2008-08-21 09:53 ---
Does following patch fix your original problem?
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 139372)
+++ config/i386/i386.c (working
--- Comment #2 from ubizjak at gmail dot com 2008-08-22 12:40 ---
Confirmed on 4.3, latent on 4.4.
Patch in testing.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #1 from ubizjak at gmail dot com 2008-08-22 12:42 ---
Confirmed, not a regression.
Patch in testing.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #4 from ubizjak at gmail dot com 2008-08-22 14:03 ---
Fixed for 4.4.
--
ubizjak at gmail dot com changed:
What|Removed |Added
URL
--- Comment #4 from ubizjak at gmail dot com 2008-08-22 14:03 ---
Fixed for 4.4.
--
ubizjak at gmail dot com changed:
What|Removed |Added
URL
--- Comment #3 from ubizjak at gmail dot com 2008-08-22 14:04 ---
Fixed for 4.4.
--
ubizjak at gmail dot com changed:
What|Removed |Added
URL
--- Comment #3 from ubizjak at gmail dot com 2008-08-23 07:21 ---
(In reply to comment #2)
> looks like a PR37191
No.
Register constraints in the testcase are just not what they look like.
"=rax" in fact specifies multiple constraints, and that includes:
"r"
--- Comment #14 from ubizjak at gmail dot com 2008-08-23 20:07 ---
Looking at http://users.physik.fu-berlin.de/~tburnus/gcc-trunk/benchmark/, it
looks that the problem was mysteriously fixed in recent mainline.
--
ubizjak at gmail dot com changed:
What|Removed
--- Comment #1 from ubizjak at gmail dot com 2008-08-24 11:26 ---
Please look at the asm dump (add -S to compile flags) for following lines:
.globl iint
.bss
.align 4
.type iint, @object
.size iint, 4
iint:
.zero 4
.comm iarr
--- Comment #5 from ubizjak at gmail dot com 2008-08-24 20:12 ---
Confirmed and added maintainer CC.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #7 from ubizjak at gmail dot com 2008-08-28 13:46 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from ubizjak at gmail dot com 2008-08-28 13:46 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from ubizjak at gmail dot com 2008-08-28 13:47 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #14 from ubizjak at gmail dot com 2008-08-29 09:44 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from ubizjak at gmail dot com 2008-08-30 14:05 ---
Confirmed, uninitialized register [st(2)] happens in bb-reorder pass:
before bb-reorder we have:
;; Start of basic block ( 10 3 9 6) -> 11
;; lr in7 [sp] 8 [st] 9 [st(1)] 10 [st(2)] 20 [frame]
;; lr
--- Comment #3 from ubizjak at gmail dot com 2008-08-30 14:16 ---
Adding -fno-reorder-blocks works OK.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37286
--- Comment #28 from ubizjak at gmail dot com 2008-09-06 15:26 ---
(In reply to comment #27)
> Also just noticed that offline copy of longest-match get extra move:
> .L15:
> movzbl 2(%eax), %edi #, tmp87
> leal2(%eax), %ecx #, scan.158
>
--- Comment #11 from ubizjak at gmail dot com 2008-09-06 15:57 ---
(In reply to comment #9)
> I am concerned about those "*Yi"/"*Ym" and "r" pairs:
> IRA is much more sensitive to "*" constraint. We can ignore "*Ym"/"r
--- Comment #30 from ubizjak at gmail dot com 2008-09-06 16:11 ---
Current mainline (4.4.0 20080906) produces:
pushl %ebx
movl8(%ebp), %eax
movl16(%ebp), %edx
movl20(%ebp), %ecx
movl12(%ebp), %ebx
imull %eax, %ecx
--- Comment #19 from ubizjak at gmail dot com 2008-09-06 16:18 ---
Exact duplicate of PR 17236. Mainline gcc (4.4.0 20080906, IRA) generates:
pushl %ebx
movl8(%esp), %eax
movl16(%esp), %edx
movl20(%esp), %ecx
movl12(%esp), %ebx
--- Comment #31 from ubizjak at gmail dot com 2008-09-06 16:18 ---
*** Bug 6585 has been marked as a duplicate of this bug. ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
--
ubizjak at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17236
--- Comment #12 from ubizjak at gmail dot com 2008-09-06 16:25 ---
(In reply to comment #11)
> of RA. Maybe this pass can even be enhanced a bit to fix PR 19389?
Eh, PR 19398.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37364
401 - 500 of 6742 matches
Mail list logo
