--- Comment #9 from ubizjak at gmail dot com 2006-11-02 07:37 ---
Does this fix also fixes PR bootstrap/10626?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28400
--- Comment #8 from ubizjak at gmail dot com 2006-11-02 07:57 ---
Fixed everywhere.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #14 from ubizjak at gmail dot com 2006-11-04 10:53 ---
According to PR 29705 (testcase is included in the PR) this is a wrong code bug
on 4.2 (and possibly others) branch.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #7 from ubizjak at gmail dot com 2006-11-04 23:15 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
URL
--- Comment #4 from ubizjak at gmail dot com 2006-11-05 14:52 ---
(In reply to comment #3)
I had a slightly deeper look. The ceilf builtin is defined only
for C99 targets in builtins.def:
DEF_C99_C90RES_BUILTIN (BUILT_IN_CEILF, ceilf, BT_FN_FLOAT_FLOAT,
ATTR_CONST_NOTHROW_LIST
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 host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla
--- Comment #1 from ubizjak at gmail dot com 2006-11-09 15:36 ---
The testcases that failed (on assembler error) are two of tests that require
vect_widen_mult_hi_to_si:
testsuite/gcc.dg/vect/vect-reduc-dot-s16a.c
testsuite/gcc.dg/vect/vect-widen-mult-s16.c
testsuite/gcc.dg/vect
--- Comment #2 from ubizjak at gmail dot com 2006-11-10 10:54 ---
(In reply to comment #0)
The Test instruction applied to the rCX register followed by a Jump if Zero
with an 8-bit displacement can be replaced by a single JCXZ/JECXZ/JRCXZ
The problem is in with an 8-bit displacement
--- Comment #3 from ubizjak at gmail dot com 2006-11-10 11:18 ---
Following asm illustrates the problem:
.file jcx.c
.text
.p2align 4,,15
.globl blah
.type blah, @function
blah:
pushl %ebp
movl%esp, %ebp
subl$8, %esp
--- Comment #4 from ubizjak at gmail dot com 2006-11-12 18:44 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED
)
Product: gcc
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
--- Comment #4 from ubizjak at gmail dot com 2006-11-29 15:58 ---
(In reply to comment #3)
So another possibility is to adjust the 387 patterns to be enabled even
without
TARGET_MIX_SSE_I387.
Considering the fact that even solaris x86_64 libm [1] uses these functions for
DFmode
--- Comment #6 from ubizjak at gmail dot com 2006-11-29 18:18 ---
(In reply to comment #5)
Can we make sure to always emit proper truncation to SF/DFmode if not
TARGET_MIX_SSE_I387? Just in case two fprem instructions follow each other
and so we don't truncate by moving to memory
--- Comment #7 from ubizjak at gmail dot com 2006-11-29 18:20 ---
Created an attachment (id=12707)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12707action=view)
Patch to enable x87 fprem and fprem1 for SSE math
I know that I've forgotten something ;)
--
ubizjak at gmail dot
--- Comment #9 from ubizjak at gmail dot com 2006-11-29 21:05 ---
(In reply to comment #8)
The patch doesn't like me ;)
[EMAIL PROTECTED]:~/src/trunk/gcc/config/i386$ patch -p0 /tmp/p
patching file i386.md
Hunk #1 succeeded at 3892 (offset -49 lines).
Hunk #2 succeeded at 3919
--- Comment #11 from ubizjak at gmail dot com 2006-11-30 07:17 ---
Fixed, by intriducing x87 helpers.
Let's see those benchmarks fly again ;)
--
ubizjak at gmail dot com changed:
What|Removed |Added
--
ubizjak at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29852
--- Comment #1 from ubizjak at gmail dot com 2006-12-01 10:14 ---
Depends on PR tree_optimization/17687. I guess it is a time to finally resolve
that one...
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #9 from ubizjak at gmail dot com 2006-12-01 20:54 ---
(In reply to comment #8)
I wonder whether this is bug is not identically to
PR 21466 sqrt()function not vectorized
Have you tried patch at
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01819.html?
The VLA - normal
--- Comment #3 from ubizjak at gmail dot com 2006-12-02 20:22 ---
(In reply to comment #2)
This also fails on x86_64:
http://gcc.gnu.org/ml/gcc-testresults/2006-12/msg00083.html
Assembling functions:
i386_cpuid_edx chk_pd {GC 5328k - 2784k} i386_cpuid_ecx main
Program received
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: x86_64-pc-linux-gnu
GCC host triplet
--- Comment #11 from ubizjak at gmail dot com 2006-12-06 20:31 ---
The VLA - normal array for C should be a different issue, where gcc could
improve.
Could you open a new bug for this problem?
Done: PR 30049.
Thanks!
I think that this bug can be closed as a duplicate
--- Comment #2 from ubizjak at gmail dot com 2006-12-06 20:31 ---
*** Bug 30032 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21466
--- Comment #1 from ubizjak at gmail dot com 2006-12-07 10:54 ---
Fixed by http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00462.html.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #2 from ubizjak at gmail dot com 2006-12-08 13:54 ---
(In reply to comment #1)
Confirmed. Reduced testcase:
We need straighten_stack() in convert_regs_entry() for the case where some
arguments are left unused.
--
ubizjak at gmail dot com changed:
What
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ubizjak at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30170
--- Comment #5 from ubizjak at gmail dot com 2006-12-12 14:41 ---
Fixed (by reverting x87 register-passing patch).
Look at http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00729.html for a
discussion.
--
ubizjak at gmail dot com changed:
What|Removed
)
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: major
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ubizjak at gmail dot com
GCC build
--- Comment #1 from ubizjak at gmail dot com 2006-12-14 19:57 ---
Created an attachment (id=12804)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12804action=view)
Testcase that crashes for -DSIZE=1 (but not for SIZE = 4)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30213
--- Comment #18 from ubizjak at gmail dot com 2006-12-23 21:24 ---
(In reply to comment #12)
As far as I can see, the i387 mode switching is already completely broken,
because it treats the different modes of a single mode-switchable entity
as separate entities.
NO, it is _NOT_
--- Comment #6 from ubizjak at gmail dot com 2007-01-06 17:47 ---
(In reply to comment #2)
vectorization of type conversions has recently been added to autovect-branch.
It requires modeling the respective unpack and pack optabs in the machine
description.
Hm
dot gnu dot org
ReportedBy: ubizjak at gmail dot com
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=30442
--- Comment #1 from ubizjak at gmail dot com 2007-01-13 23:27 ---
Addition (addl) operates in CCGOCmode and is not compatible with requested
CCZmode. Following that, test insn will be eliminated in this example:
int add_zf(int *x, int y, int a, int b)
{
if ((*x + y) 0
--- Comment #2 from ubizjak at gmail dot com 2007-01-13 23:43 ---
(In reply to comment #1)
Combine pass then creates:
(insn 15 14 16 2 (parallel [
(set (reg:SI 58 [ temp.27 ])
(plus:SI (reg/v:SI 62 [ y ])
(mem:SI (reg/v/f:DI 61
--- Comment #5 from ubizjak at gmail dot com 2007-01-14 11:32 ---
Although %zN is not documented, we advertise it in config/i386/i386.md:
;; The special asm out single letter directives following a '%' are:
;; 'z' mov%z1 would be movl, movw, or movb depending on the mode
--- Comment #6 from ubizjak at gmail dot com 2007-01-15 08:46 ---
(In reply to comment #2)
The fact that the index variable is chosen to start with 1 instead of zero is
more interesting. It does not really matter that much, since both
possibilities have exactly the same cost
--- Comment #4 from ubizjak at gmail dot com 2007-01-15 15:24 ---
Testcase compiles OK with gcc version 4.3.0 20070115 (experimental).
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #9 from ubizjak at gmail dot com 2007-01-17 06:58 ---
(In reply to comment #4)
Testcase compiles OK with gcc version 4.3.0 20070115 (experimental).
Uh, I was compiling in 32bit mode. For x86_64 compilation fails as documented
in comment #3.
--
ubizjak at gmail dot com
--- Comment #11 from ubizjak at gmail dot com 2007-01-17 12:39 ---
(In reply to comment #10)
What glibc version do you have? And what platform are you building on?
GNU C Library development release version 2.3.6
2.6.17-1.2142_FC4smp on i686-pc-linux-gnu and x86_64-pc-linux-gnu
--- Comment #1 from ubizjak at gmail dot com 2007-01-21 11:38 ---
(In reply to comment #0)
gcc with -Os -fno-PIC generates:
movb$38, (%ebx,%edx)# 45*movqi_1/7 [length = 4]
leal(%ebx,%edx), %eax # 122 *lea_1 [length = 3]
movb
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ssemmx
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ubizjak at gmail dot com
GCC build triplet: i686-pc
--- Comment #3 from ubizjak at gmail dot com 2007-02-01 08:16 ---
(In reply to comment #2)
The generic implementation, including for SSE, is
I don't think we want to be too generic there. We should not implement proposed
transformations as part of fold_builtin_classify() [builtins.c
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-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla
--- Comment #1 from ubizjak at gmail dot com 2007-02-01 13:59 ---
Created an attachment (id=12993)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12993action=view)
testcase
Testcase, compile with gcc -O2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30666
--- Comment #1 from ubizjak at gmail dot com 2007-02-02 14:43 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00153.html
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #2 from ubizjak at gmail dot com 2007-02-22 08:11 ---
(In reply to comment #0)
Bootstrap with vectorization enabled fails on i386 starting from revision
121767:
http://gcc.gnu.org/viewcvs?view=revrevision=121767
Could you post exact steps how to reproduce this failure
--- Comment #4 from ubizjak at gmail dot com 2007-02-22 09:54 ---
Confirmed, the bootstrap breaks with;
/home/uros/gcc-i386/./gcc/xgcc -B/home/uros/gcc-i386/./gcc/
-B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/
-isystem /usr/local/i686-pc-linux-gnu/include
--- Comment #3 from ubizjak at gmail dot com 2007-02-22 11:04 ---
These warnirngs disappear by commenting out TARGET_HAS_SINCOS in
config/linux.h.
These warnings indeed point to pov::create_ray, where we have quite some tree
sincos transformations:
int pov::create_ray(pov::RAY
--- Comment #2 from ubizjak at gmail dot com 2007-02-23 07:34 ---
It is -msse that breaks the bootstrap.
'gmake bootstrap BOOT_CFLAGS=-O2' bootstraps OK.
'gmake bootstrap BOOT_CFLAGS=-O2 -msse' crashes.
--
ubizjak at gmail dot com changed:
What|Removed
--- Comment #3 from ubizjak at gmail dot com 2007-02-23 10:22 ---
There is something wrong in combine_predictions_for_insn(). Perhaps stack gets
corrupted, but from the comment:
/* Use FP math to avoid overflows of 32bit integers. */
combined_probability variable
--- Comment #4 from ubizjak at gmail dot com 2007-02-23 13:54 ---
Got it.
This regression is indeed introduced by patch that fixes inter-unit moves
(http://gcc.gnu.org/viewcvs?view=revrevision=121767) as was found out in PR
30921.
The failure is due to slight register preference
--- Comment #7 from ubizjak at gmail dot com 2007-02-23 18:20 ---
Fixed on mainline.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|NEW
-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=30938
--- Comment #1 from ubizjak at gmail dot com 2007-02-23 20:16 ---
This is the operand that is not liked by vect_is_simple_use():
(gdb) p debug_tree (operand)
ssa_name 0x2aaab01533c0
type enumeral_type 0x2edc0b40 x86_64_reg_class sizes-gimplified
unsigned type_0 SI
size
--- Comment #5 from ubizjak at gmail dot com 2007-02-23 20:21 ---
(In reply to comment #4)
I'm still getting an ICE when trying to bootstrap on x86_64:
/var/tmp/portage/dev-java/gcj-4.3.0_alpha20070216/work/gcc-4.3-20070216/libgcc/../gcc/libgcc2.c:
In function '__multi3':
Try
--- Comment #2 from ubizjak at gmail dot com 2007-02-24 08:53 ---
The problem here is in ix86_expand_set_or_movmem_via_loop().
In mtune=k8 case, we choose unrolled_loop as the algorithm, where main loop is
expanded as
expand_set_or_movmem_via_loop (dst, NULL, destreg, NULL
--- Comment #3 from ubizjak at gmail dot com 2007-02-24 10:59 ---
I'm currently testing this patch:
2007-02-24 Uros Bizjak [EMAIL PROTECTED]
* config/i386/i386.md (expand_set_or_movmem_via_loop): Return if
GET_MODE_SIZE (mode) * unroll is less than expected_size
--- Comment #5 from ubizjak at gmail dot com 2007-02-24 19:09 ---
(In reply to comment #2)
I have verified that revision 119252:
http://gcc.gnu.org/ml/gcc-cvs/2006-11/msg00907.html
breaks -mtune=nocona. Jan, can you take a look? Thanks.
Something is still wrong with unrolled_loop
--- Comment #6 from ubizjak at gmail dot com 2007-02-24 22:54 ---
It was a typo in expand_movmem_epilogue() and expand_setmem_epilogue().
Following patch, fixes this bug and together with patch for PR target/30778
(http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01937.html) enables
--
ubizjak at gmail dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com
|dot org
--- Comment #5 from ubizjak at gmail dot com 2007-02-24 23:24 ---
(In reply to comment #4)
Hi,
testing for expected_size is wrong here - with profile feedback, expected_size
is average size of the block and thus can be smaller than actual size of the
block being copied.
In general
--- Comment #7 from ubizjak at gmail dot com 2007-02-25 07:54 ---
(In reply to comment #6)
This patch however fixes one extra pasto and makes the prologue test
unconditional - I was a bit overagressive minimizing amount of RTL produced
that only leads to bugs in side corners
--- Comment #2 from ubizjak at gmail dot com 2007-02-25 18:29 ---
Fixed by http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01979.html.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #3 from ubizjak at gmail dot com 2007-02-25 21:57 ---
Sorry, I was too quick. Please ignore comment #2, bootstrap with
BOOT_CFLAGS=-Os -g -ftree-vectorize still fails with the same error.
--
ubizjak at gmail dot com changed:
What|Removed
--- Comment #5 from ubizjak at gmail dot com 2007-02-25 23:19 ---
Fixed on SVN for real.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status
--- Comment #9 from ubizjak at gmail dot com 2007-02-26 07:04 ---
Fixed in SVN.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|NEW
--- Comment #8 from ubizjak at gmail dot com 2007-02-26 07:05 ---
Fixed in SVN.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ubizjak at gmail dot com
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30970
--- Comment #1 from ubizjak at gmail dot com 2007-02-26 15:48 ---
It is a target issue. Working on a fix.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #3 from ubizjak at gmail dot com 2007-02-26 19:51 ---
(In reply to comment #2)
Shouldn't rtl invariant motion catch this?
It would be nice, but the problem is again in the fact that we lie to the
compiler about supported instructions. This one is not a valid x86 insn
--- Comment #1 from ubizjak at gmail dot com 2007-03-01 07:10 ---
(In reply to comment #0)
I bootstrap trunk every night. Last night's run gave 86 new g++ testsuite
failures from the previous night. Here's the diff. Let me know if you need
more information to figure out what
--- Comment #4 from ubizjak at gmail dot com 2007-03-01 13:47 ---
Current mainline produces really horrible code:
.L4:
movl(%edx), %ebx
addl$1, %eax
movl4(%edx), %esi
addl$8, %edx
movl%ebx, 8(%esp)
movl%esi, 12
--- Comment #1 from ubizjak at gmail dot com 2007-03-02 07:31 ---
IMO there is no need for a bugreport in this case as there is no failure, bad
code or similar problems. You could just post a patch to gcc-patches.
--
ubizjak at gmail dot com changed:
What|Removed
--- Comment #2 from ubizjak at gmail dot com 2007-03-02 10:12 ---
Mine, I have a patch in testing.
And this is _definitelly_ not a microoptimization. I'll post the patch shortly
to gcc-patches, please look at some suprising numbers below...
size cc1
textdata bss dec
--- Comment #3 from ubizjak at gmail dot com 2007-03-02 11:03 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00115.html
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #5 from ubizjak at gmail dot com 2007-03-02 14:51 ---
Patch committed, with somehow smaller code-size saves as per
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00122.html.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- 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 about
something called fixincludes
--- 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 |Added
--- 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 of SPEC2006
--- 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.gnu.org/bugzilla/show_bug.cgi
--- 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-03
--- 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_operand
--- 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] predicate
--- 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=13205action=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: suffix or operands
--- 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
fnstsw %ax
sahf
--- 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 all
--- 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.cc
--- 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.
0x00afa307 in __qs_resp__resp_fit
--- 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 : AMD Opteron(tm) Processor 840
1 - 100 of 6570 matches
Mail list logo
