--- Comment #8 from ubizjak at gmail dot com 2009-06-29 08:47 ---
(In reply to comment #7)
> OTOH, doing integer arithmetics on 64bit _image_ of FP value has questionable
> usability, so the motivation to fix this PR is proportionally low...
So, wontfix.
--
ubizjak at gma
--- Comment #4 from ubizjak at gmail dot com 2009-06-29 14:36 ---
The test also fails with FSF 4.4.1 and 4.5.0, but not with 4.3.4, which makes
for 4.4 regression.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #17 from ubizjak at gmail dot com 2009-07-03 08:46 ---
(In reply to comment #16)
> One of the cases SCEV is confused about pointer-plus offsets being sizetype:
Do we have a solution for this problem...?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34163
--- Comment #4 from ubizjak at gmail dot com 2009-07-03 15:19 ---
For the interested reader: see [1].
[1]: http://ieng9.ucsd.edu/~cs30x/rt_lt.rule.html
Unfortunately:
--quote--
First, symbols. Read
* as "pointer to" - always on the
--- Comment #11 from ubizjak at gmail dot com 2009-07-04 08:39 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|NEW
ONFIRMED
Severity: normal
Priority: P3
Component: target
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:
--- Comment #4 from ubizjak at gmail dot com 2009-07-04 12:43 ---
(In reply to comment #1)
> Can you check numbers with vectorization disabled? I see the regression as
> well on a AMD Fam 10 machine which supposedly has unaligned moves as fast
> as aligned moves (if the data
--- Comment #5 from ubizjak at gmail dot com 2009-07-04 13:40 ---
(In reply to comment #4)
> and in regressed case:
... in NON-regressed case. The regressed code is the first dump.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40648
--- Comment #2 from ubizjak at gmail dot com 2009-07-07 17:32 ---
Please add (minimized) testcase and all other info, as explained in [1].
Also, please post /proc/cpuid.
[1] http://gcc.gnu.org/bugs.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40673
--- Comment #5 from ubizjak at gmail dot com 2009-07-07 18:57 ---
Unfortunately, it is nearly impossible to debug your problem without the
testcase, since the problem can not be analyzed.
Can you at least run the breaking case through a gdb? It will show invalid
instruction at the
--- Comment #4 from ubizjak at gmail dot com 2009-07-09 09:05 ---
For some reason IRA reloads argp using ebp-relative address as:
Reloads for insn # 22
Reload 0: reload_in (DI) = (mem/c/i:DI (plus:SI (reg/f:SI 6 bp)
(const_int 8
--
ubizjak at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40667
--- Comment #1 from ubizjak at gmail dot com 2009-07-15 08:19 ---
Confirmed on i686 (x86_64 with -m32):
Program received signal SIGSEGV, Segmentation fault.
useless_type_conversion_p (outer_type=0x2ac18624b240, inner_type=0x0)
at ../../gcc-svn/trunk/gcc/tree-ssa.c:1003
1003 if
--
ubizjak at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40759
--- Comment #3 from ubizjak at gmail dot com 2009-07-15 17:58 ---
(In reply to comment #1)
> if I call the functions(sin,cos,tan) from intel's libimf.so, then
> gfortran 1.f90 -limf
> 4.31716608E+09
>
> real6m39.177s
> user6m38.289s
> sys 0
--- Comment #10 from ubizjak at gmail dot com 2009-07-16 06:56 ---
(In reply to comment #6)
> Thus with the GLIBC (with AMD patches) or with the AMCL, one gets only a
> slowdown of 25%, which is still acceptable. Why the Intel routines are so slow
> on my AMD, I do not know
--- Comment #11 from ubizjak at gmail dot com 2009-07-16 07:16 ---
(In reply to comment #6)
> Thus the question is really: Why are neither vmlsSinCos4 nor vmlsTan4 - nor
> for
> ACML vrs4_sincosf/vrsa_sincosf (vrs*_tan* does not exist) called?
Because sincos returns _TWO_ v
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed
--
ubizjak at gmail dot com changed:
What|Removed |Added
BugsThisDependsOn||40770
Status|UNCONFIRMED |NEW
Ever
--- Comment #3 from ubizjak at gmail dot com 2009-07-19 15:14 ---
"i" is not correct constraint to immediate operand for sign-extending movq.
Use "e".
--
ubizjak at gmail dot com changed:
What|Removed
--- Comment #4 from ubizjak at gmail dot com 2009-07-19 15:47 ---
BTW: Constraints in arch/x86/include/asm/uaccess_64.h from linux-2.6.31 are
wrong for all cases where mov is suffixed with "q", i.e.:
int __copy_to_user(void __user *dst, const void *src, uns
--- Comment #5 from ubizjak at gmail dot com 2009-07-19 20:30 ---
FYI, patch for linux kernel is at [1].
[1] http://marc.info/?l=linux-kernel&m=124801961215396&w=2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40803
--- Comment #8 from ubizjak at gmail dot com 2009-07-20 12:30 ---
(In reply to comment #7)
> Does __builtin_cexpi have a vector implementation? If so, does it return two
> vectors?
No, only vectorized sincos is implemented (see also links at PR40766, Comment
#11).
--
--- Comment #3 from ubizjak at gmail dot com 2009-07-20 22:46 ---
PR 39943 ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40809
--- Comment #9 from ubizjak at gmail dot com 2009-07-20 23:12 ---
*** Bug 40809 has been marked as a duplicate of this bug. ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #5 from ubizjak at gmail dot com 2009-07-20 23:12 ---
(In reply to comment #4)
> (In reply to comment #3)
> > PR 39943 ?
> >
>
> Yes, it is. Gcc 4.5.0 revision 149104 works fine. Should the fix
> backported to 4.3/4.4 branches?
Yes, please reopen
--- Comment #1 from ubizjak at gmail dot com 2009-07-20 23:26 ---
What about unsigned int -> double?
--
ubizjak at gmail dot com changed:
What|Removed |Ad
--- Comment #3 from ubizjak at gmail dot com 2009-07-21 06:15 ---
(In reply to comment #2)
>
> We don't even support int -> double.
Yes, we do. Try:
#define N 16
extern int u4[N] __attribute__ ((aligned(16)));
extern double f4[N] __attribute__ ((aligned(16)));
--- Comment #7 from ubizjak at gmail dot com 2009-07-21 10:00 ---
Subject: Bug 40811
Author: uros
Date: Tue Jul 21 07:22:51 2009
New Revision: 149847
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149847
Log:
Backport from mainline:
2009-04-29 Richard
--- Comment #14 from ubizjak at gmail dot com 2009-07-21 10:02 ---
Fixed also on branches.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status
--- Comment #5 from ubizjak at gmail dot com 2009-07-21 10:04 ---
(In reply to comment #4)
> Subject: Bug 40811
>
> Author: uros
> Date: Tue Jul 21 07:22:51 2009
> New Revision: 149847
Sorry, wrong PR number.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40811
--- Comment #6 from ubizjak at gmail dot com 2009-07-21 10:04 ---
Taking a bug.
--
ubizjak at gmail dot com changed:
What|Removed |Added
AssignedTo|unassigned at
--- Comment #7 from ubizjak at gmail dot com 2009-07-21 11:32 ---
Created an attachment (id=18236)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18236&action=view)
implement vectorization of unsigned int -> float
This patch vectorizes unsigned int -> flo
--- Comment #9 from ubizjak at gmail dot com 2009-07-21 15:36 ---
Fixed.
BTW: The patch to vectorize unsigned int -> double is at [1].
[1] http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01170.html
--
ubizjak at gmail dot com changed:
What|Remo
--- Comment #6 from ubizjak at gmail dot com 2009-07-23 06:52 ---
This happens also with default settings on CentOS 5.3 x86_64 and F11 x86_64,
current mainline gcc-4.5.0.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #5 from ubizjak at gmail dot com 2009-07-23 07:03 ---
(In reply to comment #4)
> > What happens if you use gas instead of Sun's assembler?
>
> $HOME/gnu-x86/local/bin/gfortran -c site.f90 -march=k8 -m32 -S
> gas --32 site.s
> site.s:652: Error: i
--- Comment #6 from ubizjak at gmail dot com 2009-07-23 07:06 ---
(In reply to comment #5)
> The code that confuses gas is in fact ffreep insn. Since your gas is detected
> as not supporting ffreep mnemonic directly, gcc generates it with .word
> 0xc0df.
/s/gcc/sun as/,
--- Comment #7 from ubizjak at gmail dot com 2009-07-23 07:58 ---
We should use ASM_SHORT instead of .word.
I have a patch.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #11 from ubizjak at gmail dot com 2009-07-23 10:26 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
URL
--- Comment #3 from ubizjak at gmail dot com 2009-07-24 06:25 ---
Please also add the testcase from Comment #1 to gcc testsuite.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40209
--- Comment #3 from ubizjak at gmail dot com 2009-07-26 10:11 ---
Created an attachment (id=18254)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18254&action=view)
patch to fix the failure
This patch fixes the failure on x86_64 -> alpha crosscompiler. Since gcc30 of
co
--- Comment #5 from ubizjak at gmail dot com 2009-07-26 11:01 ---
-fsee was removed some time ago by:
2009-06-18 Sergei Dyshel
* see.c: Remove.
* Makefile.in (OBJS-common): Remove see.o.
(see.o): Remove.
* common.opt (fsee): Mark as preserved for
--- Comment #5 from ubizjak at gmail dot com 2009-07-26 11:07 ---
(In reply to comment #4)
> With -mieee they indeed pass.
>
> Was the default changed for 4.4?
No, but code generation is different, just use -mieee.
--
ubizjak at gmail dot com changed:
What
--- Comment #3 from ubizjak at gmail dot com 2009-07-28 20:01 ---
What about using ^ and $ throughout the testsuite instead of inventing regular
expressions involving \n and \r in all possible combinations (i.e. (\n|\r\n|\r)
)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40704
--- Comment #4 from ubizjak at gmail dot com 2009-08-01 22:04 ---
Confirmed as gcc-4.5 regression.
Reduced testcase:
--cut here--
extern struct
{
int demoplayback;
float movetype;
int cameramode;
float idealpitch;
float pitchvel;
int nodrift;
int paused;
int onground
--- Comment #5 from ubizjak at gmail dot com 2009-08-01 22:25 ---
The backtrace:
#0 fancy_abort (file=0xc59e30 "../../gcc-svn/trunk/gcc/reg-stack.c", line=741,
function=0xc5a5f0 "get_hard_regnum") at
../../gcc-svn/trunk/gcc/diagnostic.c:729
#1 0x00708a5
--- Comment #6 from ubizjak at gmail dot com 2009-08-01 22:38 ---
(In reply to comment #5)
> (jump_insn:TI 52 50 56 11 test.c:32 (parallel [
> (set (pc)
> (if_then_else (le (reg/v:SF 9 st(1) [orig:64 move ] [64])
> (reg
--- Comment #13 from ubizjak at gmail dot com 2009-08-02 09:59 ---
(In reply to comment #11)
> I'm not sure if there is another patch that can work. :-)
>
> Uros, do you think it's fine? I don't think that non-hot FP jumps are that
> common. Definitely in
--- Comment #1 from ubizjak at gmail dot com 2009-08-04 13:21 ---
We enter standard_sse_constant_opcode with:
(const_vector:V4DI [
(const_int -1 [0x])
(const_int -1 [0x])
(const_int -1 [0x])
(const_int -1
--- Comment #8 from ubizjak at gmail dot com 2009-08-04 19:27 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
URL
--- Comment #6 from ubizjak at gmail dot com 2009-08-05 21:19 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #3 from ubizjak at gmail dot com 2009-08-06 10:47 ---
Hm, we can fix this by teaching scheduler that every access to %mm registers
clobbers FP state. Since scheduler already depend all x87 instructions on
Top-Of-Stack (TOS) register, we can perhaps extend this requirement
--- Comment #5 from ubizjak at gmail dot com 2009-08-06 11:47 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|NEW
--- Comment #1 from ubizjak at gmail dot com 2009-08-06 12:27 ---
Please follow [1] on how to report bug.
[1] http://gcc.gnu.org/bugs.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40985
--- Comment #5 from ubizjak at gmail dot com 2009-08-10 08:05 ---
(In reply to comment #4)
> If you want to change it to be consistent with the documentation (not with
> existing implementation) and pass structures always on stack, I wouldn't
> object
> against it.
--- Comment #6 from ubizjak at gmail dot com 2009-08-10 08:06 ---
Adding H.J. to CC.
--
ubizjak at gmail dot com changed:
What|Removed |Added
CC
--- Comment #7 from ubizjak at gmail dot com 2009-08-11 06:46 ---
(In reply to comment #6)
> Please add to gcc-4.3.x and gcc-4.4.x.
OK, I will post the patch, thanks for the analysis.
--
ubizjak at gmail dot com changed:
What|Removed |Ad
--- Comment #1 from ubizjak at gmail dot com 2009-08-11 18:41 ---
(In reply to comment #0)
> Following code (written just for fun) leads to:
>
> Program received signal SIGSEGV, Segmentation fault.
> main () at main-general.cpp:95
> 95 printf("%d\n&q
--- Comment #1 from ubizjak at gmail dot com 2009-08-13 06:32 ---
No testcase, please see http://gcc.gnu.org/bugs.html on how to submit proper
bugreport.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41053
--- Comment #15 from ubizjak at gmail dot com 2009-08-13 13:02 ---
(In reply to comment #14)
> The vcond patterns are not properly reflecting the restrictions.
Are you sure?
(define_expand "vcond"
[(set (match_operand:SSEMODEI 0 "register_operand" ""
--- Comment #16 from ubizjak at gmail dot com 2009-08-13 13:04 ---
Looking into it...
--
ubizjak at gmail dot com changed:
What|Removed |Added
AssignedTo
--- Comment #18 from ubizjak at gmail dot com 2009-08-13 13:35 ---
(In reply to comment #17)
> It says TARGET_SSE2 but vcondv2di is only available with TARGET_SSE4+
Yes, but FAIL invalidates complete expansion.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41019
--- Comment #19 from ubizjak at gmail dot com 2009-08-13 13:39 ---
(In reply to comment #18)
> (In reply to comment #17)
>
> > It says TARGET_SSE2 but vcondv2di is only available with TARGET_SSE4+
>
> Yes, but FAIL invalidates complete expansion.
Oh, I see the p
--- Comment #21 from ubizjak at gmail dot com 2009-08-13 15:26 ---
Created an attachment (id=18353)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18353&action=view)
patch to fix the failure
I'm testing the attached patch.
There is a little complication w.r.t to V
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 triple
--- 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() [bu
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: i6
--- 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=12993&action=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=rev&revision=121767
Could you post exact steps how to r
--- 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 c
--- 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 is
--- 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=rev&revision=121767) as was found out in PR
30921.
The failure is due to slight register prefer
--- 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
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: 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)
unit size
align 32 symtab 0 alias set 16 canonical type 0x2edc0b40 precision
32 min max
values
--- 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
--- 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 ex
--- 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 stil
--- 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
--- 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 sid
--- 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
--- 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
3
Component: rtl-optimization
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
--- 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
--- 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
--- 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
201 - 300 of 6751 matches
Mail list logo
