--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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
--
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 #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 #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 #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 #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-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 #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 #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 #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 #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
--- Additional Comments From uros at kss-loka dot si 2005-02-18 06:45
---
FYI: gcc 4.0 doesn't generate any SSE instructions for testcase.cc:
gcc -Os -march=pentium4 -S testcase.cc
grep xmm testcase.s | wc -l
0
--
What|Removed |Added
--- Additional Comments From uros at kss-loka dot si 2005-02-22 10:49
---
The problem in mainline is that 'tree type' of RECORD_TYPE enters fold_convert()
and triggers gcc_unreachable() in line 2003.
However Borland C++ exits with error: Call to function 'g' with no prototype.
on line
--
Bug 19987 depends on bug 20219, which changed state.
Bug 20219 Summary: Missed optimisation sin / tan -- cos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20219
What|Old Value |New Value
--- Additional Comments From uros at kss-loka dot si 2005-02-26 09:50
---
Here is the patch to implement missing folds:
http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01024.html
And here is the explanation why this transformation is not suitable for GCC even
with -ffast-math:
http
--- Additional Comments From uros at kss-loka dot si 2005-03-08 06:29
---
Patch for mainline awaiting review:
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00644.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17688
--- Additional Comments From uros at kss-loka dot si 2005-03-10 11:01
---
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01009.html
--
What|Removed |Added
--- Additional Comments From uros at kss-loka dot si 2005-03-11 09:31
---
Updated patch (no need for FLAGS_REG clobber and some mode macro stuff) at
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01119.html
Regarding comment #4:
I have the same thought as Ferdinand. fisttp insn should
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uros at kss-loka dot si
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i386-pc-linux-gnu
GCC host triplet: i386-pc-linux-gnu
GCC target triplet: i386
--
What|Removed |Added
OtherBugsDependingO||20421
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12308
--- Additional Comments From uros at kss-loka dot si 2005-03-11 12:32
---
The problem is in *vec_dupv4hi pattern. However if constraint is changed to
(correct) TARGET_SSE || TARGET_3DNOW_A, testcase ICES with unrecognizable
insn.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20415
--- Additional Comments From uros at kss-loka dot si 2005-03-11 14:01
---
Just FYI: arith-3.c still fails for me on pentium4. The sistem is fairly
unpatched Red Hat Linux release 8.0 (Psyche):
Linux moron 2.4.18-14 #1 Wed Sep 4 13:35:50 EDT 2002 i686 i686 i386 GNU/Linux
Compiler
--- Additional Comments From uros at kss-loka dot si 2005-03-14 16:18
---
Patch installed on mainline after bootstrapping on --host=i386-pc-linux-gnu.
--
What|Removed |Added
--
Bug 17652 depends on bug 17688, which changed state.
Bug 17688 Summary: [4.1] x87 fops can handle HImodes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17688
What|Old Value |New Value
--- Additional Comments From uros at kss-loka dot si 2005-03-15 12:34
---
(In reply to comment #6)
But a peephole solution would fix a single backend, whilst I assume any kind
of
Also, every insn pattern that accepts memory input would need an appropriate
peephole2 pattern
--- Additional Comments From uros at kss-loka dot si 2005-03-15 14:53
---
Patch is comitted to 4.1 mainline. For the testcase in description '-O2
-march=prescott' now generates:
oof:
pushl %ebp
movl%esp, %ebp
subl$8, %esp
fldl8(%ebp
--- Additional Comments From uros at kss-loka dot si 2005-03-21 06:20
---
This is a duplicate of PR 14981. The fix is in a follow-up bug PR 19010.
*** This bug has been marked as a duplicate of 14981 ***
--
What|Removed |Added
--- Additional Comments From uros at kss-loka dot si 2005-03-21 06:21
---
*** Bug 20051 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From uros at kss-loka dot si 2005-03-21 13:15
---
(In reply to comment #4)
I'm sorry Uros, but PR1901 was fixed three months ago; I reduced this testcase
with the latest 3.4 snapshot (20050318). I checked the testcase in PR14981,
and
that one indeed doesn't
--- Additional Comments From uros at kss-loka dot si 2005-03-21 13:40
---
The original testcase from description fails again with GNU C version 3.4.4
20050321 (prerelease) (i686-pc-linux-gnu). It compiles OK with mainline.
PR 19010 compiles OK with both compilers.
Reopened as 3.4
--- Additional Comments From uros at kss-loka dot si 2005-03-22 08:42
---
3.4 patch, backported from mainline:
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02057.html
--
What|Removed |Added
--- Additional Comments From uros at kss-loka dot si 2005-03-22 16:00
---
Fixed also on 3.4 branch, finally.
--
What|Removed |Added
Status|REOPENED
-loka dot si
CC: gcc-bugs at gcc dot gnu dot org
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=20748
--- Additional Comments From uros at kss-loka dot si 2005-04-06 05:32
---
Fixed.
--
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
--- Additional Comments From uros at kss-loka dot si 2005-04-13 09:58
---
(In reply to comment #7)
Uros, what's the state of this bug? I don't understand if the patch linked in
comment #6 was committed, or which is its final version still pending
review/approval.
Another approach
--- Additional Comments From uros at kss-loka dot si 2005-04-14 05:52
---
Yes, this is duplicate of PR 21004:
20040209-1.c.t02.original:
;; Function foo (foo)
;; enabled by -tree-original
{
return (int) __builtin_lceilf (x);
}
These functions (lceil and lfloor) share the same
--- Additional Comments From uros at kss-loka dot si 2005-04-14 05:52
---
*** Bug 21009 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21004
--- Additional Comments From uros at kss-loka dot si 2005-04-14 05:55
---
I susupect the bug to be in expand_builtin_int_roundingfn(). It looks that
tmp = gen_reg_rtx(floatmode);
is needed before
tmp = expand_builtin_mathfn (exp, NULL_RTX, NULL_RTX);
It is somehow annoying fact
--- Additional Comments From uros at kss-loka dot si 2005-04-14 12:37
---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01568.html
--
What|Removed |Added
--- Additional Comments From uros at kss-loka dot si 2005-04-15 07:42
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From uros at kss-loka dot si 2005-04-29 18:56
---
Hm, this should be fixed by a fix for PR21004:
http://gcc.gnu.org/ml/gcc-cvs/2005-04/msg00794.html.
If I understand correctly, the problem is shown only with newlib. Does newlib
set TARGET_C99_FUNCTIONS
--- Additional Comments From uros at kss-loka dot si 2005-04-29 19:34
---
Hm, I would also suggest setting __NO_MATH_INLINES for -mfpmath=sse to prevent
the performance degradation for XMM-x87 registers when x87 ASM code is included
from mathinlines.h. x87 intrinsics are disabled
--- Additional Comments From uros at kss-loka dot si 2005-04-29 20:48
---
(In reply to comment #5)
Hmm, even though floor is C99, some libc (or in this case newlib) don't have
full
TARGET_C99_FUNCTIONS support.
Andrew, did you mean floorf in your comment?
The problem is that (int
--- Additional Comments From uros at kss-loka dot si 2005-04-30 07:59
---
I think that the best way to fix problems with missing floorf(), floorl(),
ceilf() and ceill() builtins is to completely disable all (int)floor() and
(int)ceil() optimizations for !TARGET_C99_FUNCTIONS.
I'll make
--- Additional Comments From uros at kss-loka dot si 2005-04-30 08:25
---
Could this be related to PR19398: secondary reloads don't consider m
alternatives?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21291
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uros at kss-loka dot si
CC: gcc-bugs at gcc dot gnu dot org
GCC build
--- Additional Comments From uros at kss-loka dot si 2005-05-13 10:07
---
I think there is another optimization opportunity regarding movzbl following
andl.
Consider this part:
movb(%eax), %alEAX = x...x
andl$1, %eax EAX = 0
--- Additional Comments From uros at kss-loka dot si 2005-06-03 08:13
---
It looks that REG_EQUAL notes gets lost between regmove and lreg pass. A
relevant part from compiling an example in description with '-O2' shows:
pr21508.c.19.regmove:
(note:HI 7 6 12 0 NOTE_INSN_FUNCTION_BEG
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |uros at kss-loka dot si
|dot org |
URL
: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uros at kss-loka dot si
CC: gcc-bugs at gcc dot gnu dot org
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
--- Additional Comments From uros at kss-loka dot si 2005-06-21 12:04
---
New testcase (everything is initialized this time):
--cut here--
#include mmintrin.h
__v8qi test ()
{
__v8qi mm0 = {1,2,3,4,5,6,7,8};
__v8qi mm1 = {11,22,33,44,55,66,77,88};
volatile __m64 x;
x
--- Additional Comments From uros at kss-loka dot si 2005-06-21 12:09
---
Fixed on mailine for 4.1.0, what about branches?
--
What|Removed |Added
Known to fail|3.2.3
--- Additional Comments From uros at kss-loka dot si 2005-06-22 06:08
---
Uh, it was a cut-n-pasto...
--
What|Removed |Added
URL
--- Additional Comments From uros at kss-loka dot si 2005-06-22 07:02
---
As this bug is getting a bit confused, I have summarised testcases below:
--cut here--
#include mmintrin.h
__m64 moo_1 (int i)
{
__m64 tmp = _mm_cvtsi32_si64 (i);
return tmp;
}
__m64 moo_2 (__m64 mmx1
--- Additional Comments From uros at kss-loka dot si 2005-06-22 10:14
---
Just for fun, I have compiled the testcase with MMX/x87 mode switching patch
included, to check MMX vector extensions. This little patch is needed to enable
MMX vector extensions (only MMX vector add expander
--- Additional Comments From uros at kss-loka dot si 2005-06-24 20:33
---
(in reply to comment #6)
../../gcc/unwind.inc: In function '_Unwind_ForcedUnwind':
../../gcc/unwind.inc:215: internal compiler error: in create_pre_exit
--- Additional Comments From uros at kss-loka dot si 2005-06-25 07:40
---
(In reply to comment #8)
This is a known problem, with a hack to mode-switching.c at
http://gcc.gnu.org/ml/gcc-patches/2005-06/msg01434.html.
Please, could you try to apply the mode-switching.c part
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 #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
--- 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
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 #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
--- 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 #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 #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 #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
: 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
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
--- 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 #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
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 #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
1 - 100 of 320 matches
Mail list logo
