--- Comment #3 from uros at kss-loka dot si 2006-10-28 09:43 ---
Fixed on 4.3 mainline
--
uros at kss-loka dot si changed:
What|Removed |Added
AssignedTo
--- Comment #5 from uros at kss-loka dot si 2006-10-28 10:04 ---
Fixed for 4.1.2.
--
uros at kss-loka dot si changed:
What|Removed |Added
Known to work|4.3.0
--- Comment #13 from uros at kss-loka dot si 2006-10-26 22:22 ---
Just some performance numbers (sorry for the C testcase...) on x86_64:
--cut here--
#include math.h
#include stdio.h
int main()
{
double x;
double t = 0.0;
for (x = 1000.0; x 0.0; x -= 1.0)
t += fmod (x
--- Comment #6 from uros at kss-loka dot si 2006-10-25 07:33 ---
Revision 118024 clears the way for MOD and MODULO implementation:
http://gcc.gnu.org/ml/gcc-cvs/2006-10/msg00703.html
BTW: I don't know fortran requirements, but built-in functions produce faster
code if errno
--- Comment #8 from uros at kss-loka dot si 2006-10-25 11:48 ---
(In reply to comment #7)
Just to be sure I understand: we are garanteed that BUILT_IN_REMAINDER{F,,L}
and BUILT_IN_FMOD{F,,L} are always available, right?
Yes. The expansion does not depend on -ffast-math anymore
--- Comment #6 from uros at kss-loka dot si 2006-10-25 12:04 ---
(In reply to comment #5)
With more registers (x86_64) the stack moves are gone, but: (!)
(testing done on AMD Athlon fam 15 model 35 stepping 2)
On Xeon 3.6, SSE is now faster:
gcc -O2 -march=pentium4 -mfpmath=387
--- Comment #7 from uros at kss-loka dot si 2006-10-25 12:18 ---
(In reply to comment #6)
On Xeon 3.6, SSE is now faster:
... but for -ffast-math:
SSE: user0m0.756s
x87: user0m0.612s
Yes, x87 is faster for -ffast-math by some 20%.
--
http://gcc.gnu.org/bugzilla
--- Comment #10 from uros at kss-loka dot si 2006-10-25 14:16 ---
(In reply to comment #9)
In the later case, expansion will fall-back to normal library call.
OK. So on system where the math library doesn't have remainderl, for example,
we shouldn't use BUILT_IN_REMAINDERL
--- Comment #7 from uros at kss-loka dot si 2006-10-10 14:48 ---
(In reply to comment #6)
Confirmed (as in comment #1). With -Os instead of -O2 we even produce
.L3:
movl%ebx, -4(%edx)
The -4(...) part comes from PR 24669.
--
http://gcc.gnu.org/bugzilla
--- Comment #8 from uros at kss-loka dot si 2006-10-07 06:12 ---
Testcase was commited to trunk and 4.1 branch, and now passes everywhere.
--
uros at kss-loka dot si changed:
What|Removed |Added
Status: UNCONFIRMED
Keywords: build
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uros at kss-loka dot si
GCC build triplet: x86_64-pc-linux-gnu
GCC host triplet: x86_64-pc-linux-gnu
--- Comment #1 from uros at kss-loka dot si 2006-10-07 07:51 ---
Propsoed patch at http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00337.html
--
uros at kss-loka dot si changed:
What|Removed |Added
--- Comment #4 from uros at kss-loka dot si 2006-10-06 08:27 ---
Please note, that in addition to
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00250.html,
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00244.html is also needed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28924
--- Comment #8 from uros at kss-loka dot si 2006-10-05 07:08 ---
try -O2 -msse2, you get:
_Z8todoubledd:
subl$12, %esp
fldl24(%esp)
faddl 16(%esp)
fstpl (%esp)
movsd (%esp), %xmm0
addl$12, %esp
cvttsd2si
--- Comment #2 from uros at kss-loka dot si 2006-10-05 07:51 ---
(In reply to comment #0)
The mode switching for floating point rounding that the i386 backend does
does not actually place mode switches, but rather the calculation of values
used for mode switches. Not only does
--- Comment #3 from uros at kss-loka dot si 2006-10-04 06:46 ---
I'm afraid you're missing my point.
The problem is that for 64-bit and 32-bit floating-point to integer
conversion,
x86 (32bit) target uses fistp* whereas x86_64 (64-bit) target uses cvt* WHEN
-mfpmath=387
--- Comment #1 from uros at kss-loka dot si 2006-10-03 07:04 ---
Similar problems were recently fixed for solaris and glibc-2.3.5. It looks that
hpux needs a fixinclude hack that would cure these errors/warnings, somehing
like:
http://gcc.gnu.org/ml/gcc-patches/2006-09/msg01317.html
--
uros at kss-loka dot si changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |uros at kss-loka dot si
|dot org
--- Comment #4 from uros at kss-loka dot si 2006-09-23 14:41 ---
Fixed.
--
uros at kss-loka dot si changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #14 from uros at kss-loka dot si 2006-09-19 11:31 ---
Fixed everywhere.
--
uros at kss-loka dot si changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from uros at kss-loka dot si 2006-09-07 06:58 ---
I have built and run a testsuite of HDF5 library on i686-pc-linux-gnu with:
gcc version 4.2.0 20060906 (experimental)
hdf5-1.6.5 (production):
(CFLAGS=-fno-strict-aliasing is needed before configure)
All tests PASS
--- Comment #3 from uros at kss-loka dot si 2006-09-08 05:47 ---
I have been playing with following patch to optabs.c that forces operands in
functions expand_sync_operation(), expand_sync_fetch_operation() and
expand_sync_lock_test_and_set() into registers through subregs of word-mode
--- Comment #9 from uros at kss-loka dot si 2006-09-06 11:33 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00162.html implements
missing i386.md RTL patterns. This is i386 target-specific fix for this bug.
The patch was bootstrapped on i686-pc-linux-gnu and x86_64-pc-linux
--- Comment #4 from uros at kss-loka dot si 2006-09-05 06:20 ---
(In reply to comment #2)
It is entirely coincident. For some processors, it is an optimization to avoid
partial flag register stall. When it is fixed, it should be reenabled with a
new flag, something like
--- Comment #5 from uros at kss-loka dot si 2006-09-05 09:35 ---
The problem here is following:
We already have the patterns, that would satisfy combined instruction
(*lshrsi3_cmp) in above testcase. However, combiner rejects combined
instruction because the register that holds shifted
--- Comment #6 from uros at kss-loka dot si 2006-09-05 11:45 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00137.html
BTW: This patch eliminates 869 test instructions in povray-3.6.1 compile.
(And my test raytraced pictures are still correct.)
--
uros at kss-loka dot si
--- Comment #7 from uros at kss-loka dot si 2006-09-05 13:43 ---
Hm, proposed patch now generates worse code for following test:
extern int fnc1(void);
extern int fnc2(void);
int test(int x)
{
if (x 0x02)
return fnc1();
else if (x 0x01)
return fnc2
--- Comment #1 from uros at kss-loka dot si 2006-09-04 05:49 ---
The problem is that RH8.0 defines SYS_gettid and SYS_futex in headers although
futex syscall is not really supported in the kernel. The build process detects
this and issues a warning to configure with --disable-linux
--- Comment #2 from uros at kss-loka dot si 2006-09-01 10:18 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00010.html
--
uros at kss-loka dot si changed:
What|Removed |Added
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uros at kss-loka dot si
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28924
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uros at kss-loka dot si
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28926
--- Comment #3 from uros at kss-loka dot si 2006-08-31 19:15 ---
Confirmed on x86_64.
Backtrace:
(gdb) bt
#0 build_vector (type=0x2db3e6e0, vals=0x2db37cc0) at
../../gcc-svn/trunk/gcc/tree.c:973
#1 0x007b829d in force_const_mem (mode=V2DImode, x=0x2da089e0
--- Comment #10 from uros at kss-loka dot si 2006-08-29 06:12 ---
(In reply to comment #9)
Fixed on the mainline by:
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg01036.html
Not really, the above patch fixed only one of three problems. The other two
remains, that is:
- ivopts problem
--- Comment #7 from uros at kss-loka dot si 2006-08-17 07:21 ---
(In reply to comment #6)
I think that remaining time difference is due to strange loop above innermost:
... due to strange _header_ above innermost loop ...
The problem is that we load zero in both arms
--- Comment #8 from uros at kss-loka dot si 2006-08-17 07:45 ---
Also interesting is, that -march=pentium4 produces following de-optimized
code, adding a couple more instructions and wasting %eax register:
.L8:
leal(%ebx,%ebx), %eax
movl40(%esp), %edx
--- Comment #6 from uros at kss-loka dot si 2006-08-16 12:15 ---
IMO the problem here is in IVopts. Using gcc-3.x, the innermost loop compiles
to:
.L15:
movl(%edi,%edx,4), %eax
fldl(%ebp,%edx,8)
addl$1, %edx
fmull (%esi,%eax,8)
cmpl
--- Comment #64 from uros at kss-loka dot si 2006-08-11 09:18 ---
Slightly offtopic, but to put some numbers to comment #8 and comment #11,
equivalent SSE code now reaches only 50% of x87 single performance and 60% of
x87 double performance on AMD x86_64:
ALGORITHM NB REPS
: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uros at kss-loka dot si
GCC build triplet: x86_64-pc-linux-gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc
--- Comment #4 from uros at kss-loka dot si 2006-07-18 07:29 ---
This is the backtrace for the testcase in comment #3:
#1 0x0827ae67 in fold_binary_to_constant (code=TRUNC_MOD_EXPR,
type=0x402473f4, op0=0x402d9438, op1=0x0) at
../../gcc-svn/trunk/gcc/fold-const.c:12314
#2 0x08174b25
--- Comment #5 from uros at kss-loka dot si 2006-07-18 08:06 ---
This error can be tracked down to fold_negate_expr() returning NULL_TREE via
this path:
(a) constant_multiple_of() calls fold_unary_to_constant():
/* If BOT seems to be negative, try dividing by -BOT instead
--- Comment #1 from uros at kss-loka dot si 2006-07-06 08:23 ---
This problem appears to be fixed in gcc version 4.2.0 20060705 (experimental).
The generated asm for the loop is now:
-O2 -march=pentium4 -fno-tree-ch:
jmp .L2
.L3:
movl%esi, -4(%edx)
addl
--- Comment #2 from uros at kss-loka dot si 2006-07-06 08:24 ---
Closing it for real...
--
uros at kss-loka dot si changed:
What|Removed |Added
Status
--- Comment #2 from uros at kss-loka dot si 2006-07-05 08:25 ---
Created an attachment (id=11824)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11824action=view)
Patch to implement pow(x,1.0/3.0) = cbrt(x) optimization
I have the patch that implements the optimization ready, just
--
uros at kss-loka dot si changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |uros at kss-loka dot si
|dot org
--- Comment #4 from uros at kss-loka dot si 2006-07-05 10:10 ---
This still fails with current mainline gcc.
--
uros at kss-loka dot si changed:
What|Removed |Added
--- Comment #5 from uros at kss-loka dot si 2006-06-27 10:12 ---
(In reply to comment #4)
which may be optimal.
movzbl 18(%esp), %eax
could be used in this particular case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24929
--- Comment #20 from uros at kss-loka dot si 2006-06-26 06:31 ---
(In reply to comment #15)
Can someone tell me if anyone is looking into this problem with the hopes of
fixing it? I just noticed that despite the posted code demonstrating the
problem, and verification on: Pentium
--- Comment #22 from uros at kss-loka dot si 2006-06-27 05:49 ---
(In reply to comment #21)
Note that you are running the opposite of my test case: SSE vs SSE rather than
x87 vs x87. This whole bug report is about x87 performance. You can get more
detail on why I want x87 in my
--- Comment #1 from uros at kss-loka dot si 2006-06-19 08:56 ---
Works OK with gcc version 4.2.0 20060619 (experimental).
--
uros at kss-loka dot si changed:
What|Removed |Added
: [gomp] ICE in g++.dg/gomp/atomic-[4,5,9].C
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uros at kss-loka dot si
GCC
--- Comment #5 from uros at kss-loka dot si 2006-06-13 07:44 ---
Similar problem was solved for gcc-4.1 in PR target/22480.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28007
--- Comment #9 from uros at kss-loka dot si 2006-06-07 07:05 ---
Fixed on 4.1 branch.
--
uros at kss-loka dot si changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from uros at kss-loka dot si 2006-06-02 10:04 ---
(In reply to comment #1)
There is nothing special about reassociation at all. In fact what you are
seeing is register allocator going funky. This what you get with x87.
This is also what you get with SSE.
--
http
--- Comment #9 from uros at kss-loka dot si 2006-06-01 08:43 ---
The benchmark run on a Pentium4 3.2G/800MHz FSB (32bit):
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Pentium(R) 4 CPU 3.20GHz
stepping: 9
cpu MHz
: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uros at kss-loka dot si
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC
--- Comment #7 from uros at kss-loka dot si 2006-05-31 10:56 ---
IMO the fact that gcc 3.x beats 4.x on this code could be attributed to pure
luck.
Looking into 3.x RTL, these things can be observed:
Instruction that multiplies pA0 and rB0 is described as:
__.20.combine:
(insn 75 73
--- Comment #3 from uros at kss-loka dot si 2006-05-29 10:29 ---
I'm testing a patch.
--
uros at kss-loka dot si changed:
What|Removed |Added
AssignedTo
--- Comment #5 from uros at kss-loka dot si 2006-05-29 11:52 ---
(In reply to comment #4)
pr27790.patch
This seems to work for me.
In V4SImode case above, there is
emit_insn (gen_subv4si3 (t1, cop0, cop1));
subv4si insn also needs cop0 in the register
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uros at kss-loka dot si
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
--- Comment #14 from uros at kss-loka dot si 2006-05-13 08:46 ---
(In reply to comment #13)
This is now a target specific problem, on i?86 and x86_64 we are left with an
offset of -4B and so referencing a[5] in the exit condition.
This is PR target/24669.
--
uros at kss-loka dot
--- Comment #6 from uros at kss-loka dot si 2006-05-08 06:12 ---
Fixed.
--
uros at kss-loka dot si changed:
What|Removed |Added
Status|NEW
at gcc dot gnu dot org
ReportedBy: uros at kss-loka dot si
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27474
--- Comment #1 from uros at kss-loka dot si 2006-05-07 19:30 ---
Created an attachment (id=11396)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11396action=view)
Reduced cpp testcase
The testcase, reduced with Delta.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27474
: unassigned at gcc dot gnu dot org
ReportedBy: uros at kss-loka dot si
GCC target triplet: i386-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27277
--- Comment #7 from uros at kss-loka dot si 2006-04-16 11:22 ---
Fixed.
--
uros at kss-loka dot si changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from uros at kss-loka dot si 2006-04-14 07:18 ---
Fixed on SVN head.
--
uros at kss-loka dot si changed:
What|Removed |Added
Known to work
--- Comment #3 from uros at kss-loka dot si 2006-04-12 17:54 ---
There seems to be something wrong with -ffast-math and floor.
I have done some analysis on this. Start from expand_builtin_int_roundingfn()
in builtins.c source, where we fallback to FP rounding optab.
fallback_fndecl
: Optimize double INT-FP-INT conversions
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uros at kss-loka dot si
GCC
--- Comment #14 from uros at kss-loka dot si 2006-04-07 06:10 ---
This is a duplicate of PR 26869.
*** This bug has been marked as a duplicate of 26869 ***
--
uros at kss-loka dot si changed:
What|Removed |Added
--- Comment #3 from uros at kss-loka dot si 2006-04-07 06:10 ---
*** Bug 27069 has been marked as a duplicate of this bug. ***
--
uros at kss-loka dot si changed:
What|Removed |Added
--- Comment #12 from uros at kss-loka dot si 2006-03-29 14:08 ---
(In reply to comment #11)
it looks like 4.1.1 and 4.2.0 still produce unoptimal code.
test: pushl %ebp
movl%esp, %ebp
fldl8(%ebp)
fldz
fcomip %st(1), %st
jae
ReportedBy: uros at kss-loka dot si
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=26869
--- Comment #7 from uros at kss-loka dot si 2006-03-23 10:33 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01435.html
--
uros at kss-loka dot si changed:
What|Removed |Added
--- Comment #17 from uros at kss-loka dot si 2006-02-22 10:15 ---
Works OK with gcc-4.2 and -Os -msse -fomit-frame-pointer.
--
uros at kss-loka dot si changed:
What|Removed |Added
Severity: normal
Priority: P3
Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uros at kss-loka dot si
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org
--- Comment #8 from uros at kss-loka dot si 2006-01-18 09:50 ---
(In reply to comment #7)
Hmm, I get (but that looks like different branch predictions):
It looks that your default is -mtune=pentium.
_testf:
fldl4(%esp)
ftst
fnstsw %ax
testb
--- Comment #9 from uros at kss-loka dot si 2006-01-18 09:53 ---
Created an attachment (id=10666)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10666action=view)
patch to SVN GCC: (GNU) 4.2.0 20060117 (experimental)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17390
)))
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uros at kss-loka dot si
http://gcc.gnu.org/bugzilla
--- Comment #10 from uros at kss-loka dot si 2005-12-02 06:59 ---
Fixed on 4.1 and mainline.
--
uros at kss-loka dot si changed:
What|Removed |Added
Status
--- Comment #3 from uros at kss-loka dot si 2005-11-28 07:20 ---
Reopened to ...
--
uros at kss-loka dot si changed:
What|Removed |Added
Status|RESOLVED
--- Comment #5 from uros at kss-loka dot si 2005-11-28 07:32 ---
... close as FIXED.
--
uros at kss-loka dot si changed:
What|Removed |Added
Status|REOPENED
--- Comment #2 from uros at kss-loka dot si 2005-11-24 08:09 ---
The testsuite patch that fixes IA32 tests (and should also fix IA64 issues
reported here) is at http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01059.html.
Patch is still waiting for review, however I can't test it on IA64
--- Comment #2 from uros at kss-loka dot si 2005-11-24 10:19 ---
This also fails for i686-pc-linux-gnu with '-march=athlon'.
The patch at http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01648.html fixes
i86_64-pc-linux-gnu failure in original report and -march=athlon failure.
FWIW
--- Comment #5 from uros at kss-loka dot si 2005-11-24 10:19 ---
*** Bug 24995 has been marked as a duplicate of this bug. ***
--
uros at kss-loka dot si changed:
What|Removed |Added
--- Comment #6 from uros at kss-loka dot si 2005-11-24 10:24 ---
(In reply to comment #4)
I've proposed a patch to this PR in
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01648.html
Does it solve PR 24995?
Yes, both i86_64 and -march=athlon failures.
--
uros at kss-loka dot
--- Comment #9 from uros at kss-loka dot si 2005-11-24 14:40 ---
Critical, according to comment #7 and #8.
--
uros at kss-loka dot si changed:
What|Removed |Added
--- Comment #6 from uros at kss-loka dot si 2005-11-15 08:13 ---
Perhaps a runtime check should be added to target-supports.exp
( check_effective_target_tls-runtime perhaps) that would check if the system is
capable of running tls enabled binaries. Alternatively, my proposed patch
(http
--
uros at kss-loka dot si changed:
What|Removed |Added
CC|uros at kss-loka dot si |
AssignedTo|unassigned at gcc dot gnu |uros at kss-loka dot si
--- Comment #2 from uros at kss-loka dot si 2005-11-14 07:13 ---
Fixed by Jakub's patch.
--
uros at kss-loka dot si changed:
What|Removed |Added
Status
--- Comment #4 from uros at kss-loka dot si 2005-11-11 08:20 ---
This is in fact duplicate of PR 19340. Fixed in 3.4.5.
*** This bug has been marked as a duplicate of 19340 ***
--
uros at kss-loka dot si changed:
What|Removed |Added
--- Comment #10 from uros at kss-loka dot si 2005-11-11 08:20 ---
*** Bug 15439 has been marked as a duplicate of this bug. ***
--
uros at kss-loka dot si changed:
What|Removed |Added
ReportedBy: uros at kss-loka dot si
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24797
--- Comment #6 from uros at kss-loka dot si 2005-11-09 15:27 ---
The problem is caused by the combination of (1) x86_64 parameter passing
convention, (2) x86 instructions that _require_ parameters in specific
registers and (3) sched1 scheduling pass.
ad 1)
x86_64 passes function
--- Comment #17 from uros at kss-loka dot si 2005-11-10 07:31 ---
Fixed on 3.4 branch.
--
uros at kss-loka dot si changed:
What|Removed |Added
Status
--- Comment #9 from uros at kss-loka dot si 2005-11-10 07:33 ---
Fixed on 3.4 branch.
--
uros at kss-loka dot si changed:
What|Removed |Added
Known to work|4.0.3
--- Comment #7 from uros at kss-loka dot si 2005-11-08 08:12 ---
Fixed on mainline and 4.0 branch.
--
uros at kss-loka dot si changed:
What|Removed |Added
--- Comment #9 from uros at kss-loka dot si 2005-11-08 10:04 ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00498.html
--
uros at kss-loka dot si changed:
What|Removed |Added
--- Comment #7 from uros at kss-loka dot si 2005-11-08 12:40 ---
Created an attachment (id=10173)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10173action=view)
Patch to fix the ice
This patch fixes the failure for me, but...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #8 from uros at kss-loka dot si 2005-11-08 12:53 ---
This patch fixes the failure for me, but...
... we actually gain nothing here.
From .loop2_done, we have following sequence, where mem-reg load is pushed out
of the loop:
(insn 21 16 39 0 (set (reg:DF 64)
(mem
--- Comment #9 from uros at kss-loka dot si 2005-11-08 13:23 ---
Bah... set_unique_reg_note is needed:
/* If new move insn is invalid (i.e. move of const_double to
387 stack register), force constant into memory. */
if (recog_memoized (inv-insn) == -1)
{
rtx src
1 - 100 of 320 matches
Mail list logo
