--- 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 #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 #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
#include
int main()
{
double x;
double t = 0.0;
for (x = 1000.0; x > 0.0; x -= 1.0)
t += fmod (x, 1.7
--- 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'
--- 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/bugzi
--- 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 -mfpma
--- 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 a
--- 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 i
--- 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.
--- 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
ion: 4.2.0
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
--- 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
--- 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 #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
--- 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
>
--- 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 cv
--- 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
--- 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
--
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 #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 #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-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
--- 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 #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)
--- 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 ks
--- 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 #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, somet
--- 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
libgomp
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
rity: P3
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
--- 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
--- 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) at
--- 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:
-
--- 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(%
--- 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 of "if
--- 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
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 build triplet: x86_64-pc-linux-gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86
--- 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, and
--- 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 #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 #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 #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
--
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 #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=11824&action=view)
Patch to implement pow(x,1.0/3.0) = cbrt(x) optimization
I have the patch that implements the optimizatio
--- 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 #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
--- 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
--- 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
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 build
--- 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 wi
Version: 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:
--- 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
--- 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 #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
--- 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
Assig
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27638
--- 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.
--
uro
--- 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
--- 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=11396&action=view)
Reduced cpp testcase
The testcase, reduced with Delta.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27474
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
get
AssignedTo: 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
: 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
--- 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_fnd
--- 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 #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 #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
> f
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-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
UNCONFIRMED
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:/
--- 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=10666&action=view)
patch to SVN GCC: (GNU) 4.2.0 20060117 (experimental)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17390
--- 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
>
fined symbol '_foo_b+2'
--
Summary: [4.0/4.1/4.2 Regression]: Handling of __attribute__
((alias ("foo+X")))
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regressi
--- 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 #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 #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 #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-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.
-
--- 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 #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 fail
--- 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
--
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 #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
--- 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
S
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 #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
--- 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 #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 #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 #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 #13 from uros at kss-loka dot si 2005-11-09 07:55 ---
Fixed everywhere.
--
uros at kss-loka dot si changed:
What|Removed |Added
Status|ASSIGNED
--- 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
--- 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 (
--- 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=10173&action=view)
Patch to fix the ice
This patch fixes the failure for me, but...
--
http://gcc.gnu.org/bugzilla/show_bug
--- 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
1 - 100 of 320 matches
Mail list logo
