--- Comment #21 from ubizjak at gmail dot com 2008-09-06 16:29 ---
IMO, this enhancement request can be closed now that 4.3 is released.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #3 from ubizjak at gmail dot com 2008-09-06 16:33 ---
gcc (4.4.0 20080906) still generates:
cmpl%esi, %edi
sete%al
cmpl%esi, %edi
setl%dl
orl %edx, %eax
movzbl %al, %eax
ret
--
http
--- Comment #1 from ubizjak at gmail dot com 2008-09-08 06:50 ---
Confirmed:
Program received signal SIGSEGV, Segmentation fault.
0x082ac655 in optimize_function_for_speed_p (fun=0x0) at
../../gcc-svn/trunk/gcc/predict.c:205
/home/uros/gcc-svn/trunk/gcc/predict.c:205:6178:beg:0x82ac655
--- Comment #3 from ubizjak at gmail dot com 2008-09-08 09:02 ---
All tests work OK with a cross from linux to x86_64-pc-mingw32 as of version
GNU Fortran (GCC) version 4.4.0 20080908 (experimental) [trunk revision 140099]
(x86_64-pc-mingw32)
Please ask gfortran community to provide
--- Comment #16 from ubizjak at gmail dot com 2008-09-11 17:33 ---
(In reply to comment #15)
> Uros, does your comment #11 apply also to SSE registers (Yi), which could
> alleviate for PR 37437, or only to MMX (Ym)?
Comment #11 is also true for Yi SSE register
--- Comment #7 from ubizjak at gmail dot com 2008-09-11 17:57 ---
There is a runtime difference between -O1 and -O2:
g++ -O1 pr37096.cpp main.o
./a.out
nz: 3
g++ -O2 pr37096.cpp main.o
./a.out
nz: 3
98
Target: x86_64-unknown-linux-gnu
gcc version 4.4.0 20080911 (experimental) [trunk
--- Comment #8 from ubizjak at gmail dot com 2008-09-11 18:16 ---
Hm, with -O2 -fno-strict-aliasing, it works fine.
Is there an aliasing issue involved?
short Transform4x4(short *pMatrix)
{
__m128i r4, r5;
__m128i r0 = _mm_loadl_epi64((__m128i *)(pMatrix + 0 * 16
--- Comment #1 from ubizjak at gmail dot com 2008-09-12 14:13 ---
(In reply to comment #0)
> asm(
> " xorl %1, %1\n"
> " movl $0x12345678, %0\n"
> " bsrl %2, %0 ; setz %b1 "
> : "=r" (res), "=r" (resz)
>
--- Comment #10 from ubizjak at gmail dot com 2008-09-12 18:03 ---
This is in fact undefined code. When Transform4x4() gets inlined in fun(), you
are accessing pAR[0] (aliased to *pMatrix) as "short" and as __m128i. Since
-fstrict-aliasing (the default) assumes that "sho
--- Comment #1 from ubizjak at gmail dot com 2008-09-14 13:23 ---
Confirmed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Severity|normal
--- Comment #2 from ubizjak at gmail dot com 2008-09-14 13:29 ---
GCC now implements whole lot of vector conversions, including int<-->float and
int<-->double. See 24659.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31945
--- Comment #4 from ubizjak at gmail dot com 2008-09-15 09:01 ---
IMO, you need to define NO_DOLLAR_IN_LABEL in your configuration files.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37520
--- Comment #6 from ubizjak at gmail dot com 2008-09-17 08:14 ---
cprop_hardreg pass is propagating DImode ax register, wrongly bypassing DI-SI
conversion.
Before cprop_hardreg, we have:
(call_insn/u:HI 27 88 28 4 pr37544.c:9 (set (reg:DI 0 ax)
(call (mem:QI (symbol_ref:SI
--- Comment #7 from ubizjak at gmail dot com 2008-09-17 08:35 ---
(In reply to comment #5)
> Confirmed on i686-linux with -std=c99 -O -msse2 -mfpmath=387 -march=i386.
Does not fail for x86_64-linux target with -m32 on x86_64-linux _and_
i686-linux hosts.
--
http://gcc.gnu.
--- Comment #8 from ubizjak at gmail dot com 2008-09-17 10:39 ---
The problem is in regrename.c, function maybe_mode_change. We enter the
function with:
orig_mode = DImode
copy_mode = SImode
new_mode = DImode
At the beginning of maybe_mode_change() we have:
if (orig_mode
--- Comment #9 from ubizjak at gmail dot com 2008-09-17 11:48 ---
4.2 and 4.3 work OK.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Known to work
--- Comment #10 from ubizjak at gmail dot com 2008-09-17 12:01 ---
I'm testing following patch:
Index: regrename.c
===
--- regrename.c (revision 140409)
+++ regrename.c (working copy)
@@ -1314,6 +1
--- Comment #11 from ubizjak at gmail dot com 2008-09-17 16:13 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01221.html
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #13 from ubizjak at gmail dot com 2008-09-18 14:31 ---
Fixed for 4.4, latent on 4.3 and 4.2.
BTW: This problem was uncovered by the patch that fixed PR target/13958 [1].
[1] http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01295.html
--
ubizjak at gmail dot com changed
--- Comment #16 from ubizjak at gmail dot com 2008-09-19 11:11 ---
Fixed everywhere.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #12 from ubizjak at gmail dot com 2008-10-04 21:47 ---
(In reply to comment #10)
> Must be darwin specific then, can't reproduce on x86_64-linux and from quick
> skim of gcc-testresults nobody else that supplied test summary recently
> managed
> to reprod
--- Comment #3 from ubizjak at gmail dot com 2008-10-12 19:00 ---
Mine.
--
ubizjak at gmail dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot
--- Comment #3 from ubizjak at gmail dot com 2008-10-12 20:19 ---
Does this patch also solve PR 28685?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37795
--- Comment #1 from ubizjak at gmail dot com 2008-10-17 06:32 ---
Confirmed, gcc crashes in passes.c, around line 1288:
if (initializing_dump
&& dump_file
&& graph_dump_format != no_graph
==> && (cfun->curr_properties & (PROP_cfg |
--- Comment #5 from ubizjak at gmail dot com 2008-10-17 06:35 ---
(In reply to comment #4)
> Digging a bit, in combine.c, the ASHIFTRT case of force_to_mode() contains two
> calls to simplify_shift_const(). Disabling those for vector modes fixes the
> test case here (patch bel
--- Comment #2 from ubizjak at gmail dot com 2008-10-18 16:43 ---
(In reply to comment #1)
> So the 64bit version is fine, the 32bit version is still funny.
Default 32bit target doesn't have cmov insn.
-O3 -m32 -msse produces expected asm:
foo:
bsfl8(%es
--- Comment #3 from ubizjak at gmail dot com 2008-10-18 18:18 ---
(In reply to comment #2)
> > So the 64bit version is fine, the 32bit version is still funny.
> Default 32bit target doesn't have cmov insn.
> -O3 -m32 -msse produces expected asm:
This is further optim
--- Comment #8 from ubizjak at gmail dot com 2008-10-20 19:37 ---
Adding either -fno-reorder-blocks or -fno-ira works OK for orignal fortran
testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37286
--- Comment #1 from ubizjak at gmail dot com 2008-10-24 07:44 ---
Confirmed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Component|c
--- Comment #2 from ubizjak at gmail dot com 2008-10-24 07:44 ---
Patch in testing.
--
ubizjak at gmail dot com changed:
What|Removed |Added
AssignedTo
--- Comment #5 from ubizjak at gmail dot com 2008-10-24 16:47 ---
(In reply to comment #4)
> Okay, now I noticed the 'nand' comment on the documentation for atomic
> builtins, the code does implement the 'negate and AND' logic, which is named
> 'nand&#
--- Comment #2 from ubizjak at gmail dot com 2008-10-25 09:46 ---
Confirmed on x86_64-pc-linux-gnu:
Program received signal SIGSEGV, Segmentation fault.
0x004c6e04 in link_block (b=0x7fa2cf6fba20, after=0x7fa2cf6fb840) at
../../gcc-svn/trunk/gcc/cfg.c:153
/home/uros/gcc-svn
--- Comment #3 from ubizjak at gmail dot com 2008-10-25 10:14 ---
Minimized testcase:
--cut here--
void Perl_croak (void) __attribute__ ((noreturn));
static int __attribute__ ((noreturn))
not_here (void)
{
Perl_croak ();
}
void XS_IO__Handle_setvbuf (void)
{
int i = not_here
--- Comment #6 from ubizjak at gmail dot com 2008-10-29 07:10 ---
According to Intel [1]:
According to Dan, __sync_fetch_and_nand intrinsic should be implemented as
~(target & val). Uros's patch is correct.
[1] http://gcc.gnu.org/ml/gcc-patches/2008-10/msg01214.html
--
u
--- Comment #8 from ubizjak at gmail dot com 2008-10-29 10:55 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2008-10/msg01224.html
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #2 from ubizjak at gmail dot com 2008-11-01 21:04 ---
There was similar problem on x86 target with sun as and ffreep mnemonic. This
was fixed by a configure check and conditional generation of either "ffreep" or
".word\t0x".
Please grep for
--- Comment #9 from ubizjak at gmail dot com 2008-11-03 14:25 ---
Patch in testing.
--
ubizjak at gmail dot com changed:
What|Removed |Added
AssignedTo
--- Comment #10 from ubizjak at gmail dot com 2008-11-03 14:26 ---
Not a RA issue.
--
ubizjak at gmail dot com changed:
What|Removed |Added
CC|vmakarov
--- Comment #11 from ubizjak at gmail dot com 2008-11-03 15:19 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00067.html
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #3 from ubizjak at gmail dot com 2008-11-05 10:04 ---
I guess this issue can be fixed by following (untested) trivial patch:
--cut here--
Index: mips.md
===
--- mips.md (revision 141602)
+++ mips.md
--- Comment #10 from ubizjak at gmail dot com 2008-11-05 13:22 ---
Next revision of the patch (v3) at [1] generates a message when nand builtin is
encountered.
[1] http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00157.html
--
ubizjak at gmail dot com changed:
What
--- Comment #5 from ubizjak at gmail dot com 2008-11-05 16:20 ---
*** Bug 38023 has been marked as a duplicate of this bug. ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #1 from ubizjak at gmail dot com 2008-11-05 16:20 ---
NOTE
Note that these functions are obsolete. C99 defines macros isfinite(),
isinf() and isnan() (for all types) replacing them. Further note that
the C99 isinf() has weaker guarantees on the return
--- Comment #6 from ubizjak at gmail dot com 2008-11-06 21:38 ---
It fails on x86_64-pc-linux-gnu host with a cross to x86_64-pc-mingw32:
../gcc-svn/trunk/configure --target=x86_64-pc-mingw32 --enable-languages=c
--disable-bootstrap
Compiling sample2.c:
~/gcc-build-cyg/gcc/cc1 -O3
--- Comment #7 from ubizjak at gmail dot com 2008-11-06 22:11 ---
Reduced testcase, fails also on x86_64-pc-linux-gnu and i686-pc-linux-gnu/sse2,
gcc version 4.4.0 20081106 (experimental) [trunk revision 141649] (GCC)
--cut here--
typedef struct
{
enum { NotConnected = 0
--- Comment #11 from ubizjak at gmail dot com 2008-11-10 12:24 ---
Fixed everywhere.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|NEW
--- Comment #15 from ubizjak at gmail dot com 2008-11-10 12:24 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|NEW
--- Comment #12 from ubizjak at gmail dot com 2008-01-18 07:12 ---
Part of problems described here is caused by PR 23322.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #14 from ubizjak at gmail dot com 2008-01-18 08:05 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|NEW
--- Comment #3 from ubizjak at gmail dot com 2008-01-18 08:58 ---
(In reply to comment #1)
> I think dwarf2out_switch_text_section() is defined if DWARF2_DEBUGGING_INFO
> is defined. So, it appears the attached change will fix the problem.
No, dwarf2out_switch_text_section()
--- Comment #4 from ubizjak at gmail dot com 2008-01-18 11:53 ---
Author: uros
Date: Fri Jan 18 09:55:15 2008
New Revision: 131626
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131626
Log:
PR debug/34484
* dwarf2out.c (dwarf2out_switch_text_section)
--- Comment #7 from ubizjak at gmail dot com 2008-01-18 11:54 ---
Sorry, wrong PR number in the ChangeLog.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34484
--- Comment #10 from ubizjak at gmail dot com 2008-01-19 16:31 ---
(In reply to comment #9)
> Does the regression on C2 duo show even without vectorizing? It looks like
> generic SSE fpmath performance issue. There should be no reason why SSE math
> in combination
--- Comment #8 from ubizjak at gmail dot com 2008-01-20 15:21 ---
(In reply to comment #6)
> Confirmed on x86_64-unknown-linux-gnu.
It fails only with --enable-checkgin=assert, as is the case in
http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg00695.html
--
http://gcc.gnu.
--- Comment #4 from ubizjak at gmail dot com 2008-01-20 15:34 ---
(In reply to comment #3)
> There is the issue, the testcase should be not run on your computer as it is
> using SSE2. So this is a testsuite issue.
Please look at gcc.dg/vect/ how this should be done. Ther
--- Comment #4 from ubizjak at gmail dot com 2008-01-20 15:34 ---
(In reply to comment #3)
> Double checking patch, I don't see obvious mistakes. Since the patch should
> only affect register allocation decisions, either we see a latent bug, or
> another example of x86 e
--- Comment #23 from ubizjak at gmail dot com 2008-01-21 19:21 ---
It is not possible to create an executable from direct.i. My compilation fails:
(.text+0x20): undefined reference to `main'
/tmp/cc0VOLHm.o: In function `___H_direct_2d_fft_2d_recursive_2d_4':
_num.c:(
--- Comment #25 from ubizjak at gmail dot com 2008-01-22 12:03 ---
Created an attachment (id=14996)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14996&action=view)
Much shorter testcase.
This testcase was used to track down problems with fre pass. Stay tuned for an
a
--- Comment #27 from ubizjak at gmail dot com 2008-01-22 12:20 ---
As already noted by Richi in Comment #9, the difference is in usage of %rax.
gcc-4.2 generates:
...
addq$7, %rax
leaq(%rax,%rbp,2), %r10
leaq(%rax,%rdx,2), %rdx
leaq
--- Comment #30 from ubizjak at gmail dot com 2008-01-22 12:52 ---
Please note that for the original testcase (direct.i), even '-O2 --param
max-aliased-vops=10' doesn't generate expected code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
--- Comment #20 from ubizjak at gmail dot com 2008-01-24 13:48 ---
(In reply to comment #19)
> Uros, can you handle x86?
Sometimes CONSTANT_P is just too broad to construct correct RTX. This patch
creates most sensible asm (i.e. using movd instead of movdqa):
--cut here--
Index: i
--- Comment #24 from ubizjak at gmail dot com 2008-01-24 17:12 ---
x86 part is fixed by http://gcc.gnu.org/ml/gcc-patches/2008-01/msg01146.html.
This patch also added a testcase that will ATM fail for RS6000 and SPU.
--
ubizjak at gmail dot com changed:
What|Removed
--- Comment #3 from ubizjak at gmail dot com 2008-01-25 10:46 ---
Confirmed & CC maintainer of fixincludes.
--
ubizjak at gmail dot com changed:
What|Removed |A
--- Comment #13 from ubizjak at gmail dot com 2008-01-25 18:36 ---
A 4.3 Regression that is known to work on 4.3.0?
Could someone please fix this inconsistency.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29215
--- Comment #19 from ubizjak at gmail dot com 2008-01-27 17:52 ---
The problem in comment #13 is fixed for 4.3.0 by the fix for PR 34771.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #20 from ubizjak at gmail dot com 2008-01-27 17:53 ---
(In reply to comment #19)
> The problem in comment #13 is fixed for 4.3.0 by the fix for PR 34771.
Oops, PR 34711.
--
ubizjak at gmail dot com changed:
What|Removed |Ad
--- Comment #26 from ubizjak at gmail dot com 2008-01-28 12:04 ---
*** Bug 34995 has been marked as a duplicate of this bug. ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #2 from ubizjak at gmail dot com 2008-01-28 12:04 ---
*** This bug has been marked as a duplicate of 34856 ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #24 from ubizjak at gmail dot com 2008-01-31 08:21 ---
Author: hubicka
Date: Wed Jan 30 23:25:35 2008
New Revision: 131969
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131969
Log:
* gcc.c-torture/execute/pr34982.c: Add forgotten return 0.
--- Comment #2 from ubizjak at gmail dot com 2008-02-01 08:49 ---
Have a patch for the testsuite. gen-vect-X.c vectorizer testcases should
probably be moved into gcc.dg/vect, at least those that scan for vectorized
loops.
--
ubizjak at gmail dot com changed:
What
--- Comment #28 from ubizjak at gmail dot com 2008-02-03 11:28 ---
(In reply to comment #27)
> On i686-apple-darwin9, rev. 132071, gcc.dg/pr35045.c gives an ICE in 32 bit
> mode :
Probably a -fpic issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35045
--- Comment #14 from ubizjak at gmail dot com 2008-02-03 17:35 ---
(In reply to comment #13)
> Uros, would be possible to give it a try on Core? That would help to figure
> out if it is code layout problem of K8.
Hm, the patch doesn't seem to help:
-m32 -O2: 32.434
-m32 -
--- Comment #6 from ubizjak at gmail dot com 2008-02-04 06:50 ---
The vectorizer failures are due to "target vect_cmdline_needed". We want to
vectorize with generic vectorization (i.e. no SSE), but using --with-arch, SSE
is implied in command line even without -msse2.
gcc.dg
--- Comment #9 from ubizjak at gmail dot com 2008-02-04 18:31 ---
(In reply to comment #8)
> and with -m64:
> FAIL: gcc.target/i386/pr32661-1.c scan-assembler-times mov 2
Does darwin need -fomit-frame-pointer for this test?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35047
--- Comment #2 from ubizjak at gmail dot com 2008-02-05 07:33 ---
Confirmed.
The testcase:
float test(unsigned int x)
{
return (float)x;
}
gcc -O2 -mno-80387
t.c: In function âtestâ:
t.c:4: error: unrecognizable insn:
(insn 20 19 21 5 t.c:2 (set (reg:SF 60)
(plus:SF
--- Comment #3 from ubizjak at gmail dot com 2008-02-05 08:26 ---
Mine.
--
ubizjak at gmail dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot
--- Comment #5 from ubizjak at gmail dot com 2008-02-05 09:45 ---
optabs.c, line 5150:
--cut here--
/* Unsigned integer, and no way to convert directly. Convert as signed,
then unconditionally adjust the result. For decimal float values we
do this only if we have already
--- Comment #4 from ubizjak at gmail dot com 2008-02-05 09:36 ---
Following patch fixes ICE (and avoids nasty runtime/code-size regression for
x87 math where we don't use fildll):
--cut here--
Index: config/i386/i3
--- Comment #7 from ubizjak at gmail dot com 2008-02-05 13:58 ---
This is the diff of expand_float() between gcc-4.2 and gcc-4.3. The relevant
part is logic at the top of the diff that has changed substantially:
--- 222 2008-02-05 14:52:52.0 +0100
+++ 111 2008-02-05 14:52
--- Comment #19 from ubizjak at gmail dot com 2008-02-05 18:25 ---
There was a discussion on IRC some time ago, and it was suggested that there
was a LR-splitting patch in cygnus local tree. maybe someone would like to post
this patch on gcc-patches@ ML?
--
http://gcc.gnu.org
--- Comment #22 from ubizjak at gmail dot com 2008-02-06 06:52 ---
(In reply to comment #21)
> Obviously this heuristic is misbehaving in such a simple cases where no other
> registers are carried over loop. One obvious problem is also that it is in
> effect for SSE codegen t
--- Comment #9 from ubizjak at gmail dot com 2008-02-06 11:11 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|NEW
--- Comment #14 from ubizjak at gmail dot com 2008-02-06 11:05 ---
We still generate:
.L8:
movl(%ebx), %eax
addl$1, %edx
addl$4, %ebx
fldl(%edi,%eax,8)
fmull (%ecx)
addl$8, %ecx
cmpl%edx, %esi
--- Comment #2 from ubizjak at gmail dot com 2008-02-06 12:09 ---
Please find "movb" insn (or similar that operates on 8bit reg) in your source
and change its constraint from "r" to "q".
--
ubizjak at gmail dot com changed:
What|Remo
--- Comment #10 from ubizjak at gmail dot com 2008-02-06 13:32 ---
I have noticed, that following text is missing from your vect dump:
Dependence tester statistics:
Number of dependence tests: 0
Number of dependence tests classified dependent: 0
Number of dependence tests classified
--- Comment #12 from ubizjak at gmail dot com 2008-02-06 14:02 ---
(In reply to comment #11)
> (In reply to comment #10)
> > I have noticed, that following text is missing from your vect dump:
>
> I don't why but I didn't modify the vector dump :/
Eh, my dump
--- Comment #13 from ubizjak at gmail dot com 2008-02-06 14:11 ---
I think that following difference is the key:
In case vectorizer is able to vecotrize, we enter vectorizer pass with:
:
# ivtmp.17_1 = PHI
# i_18 = PHI
# s_17 = PHI
D.2002_7 = a[i_18];
D.2003_8 = i_18 + D
--- Comment #20 from ubizjak at gmail dot com 2008-02-06 18:42 ---
Whoa, adding -fomit-frame-pointer brings us from
(gcc -O3 -m32)
user0m41.031s
to
(gcc -O3 -m32 -fomit-frame-pointer)
user0m30.006s
Since -fo-f-p adds another free reg, it looks that since inlining increases
--- Comment #21 from ubizjak at gmail dot com 2008-02-06 19:10 ---
(In reply to comment #20)
> Since -fo-f-p adds another free reg, it looks that since inlining increases
> register pressure some unlucky heavy-used variable gets allocated to the stack
> slot.
It is "
--- Comment #20 from ubizjak at gmail dot com 2008-02-07 09:01 ---
>From the logs:
tree-reassoc in failed case transforms:
D.2020_7 = a[i_17];
D.2021_8 = D.2020_7 + i_17;
s_9 = D.2021_8 + s_18;
to:
D.2020_7 = a[i_17];
D.2021_8 = s_18 + i_17;
s_9 = D.2021_8 + D.202
--- Comment #22 from ubizjak at gmail dot com 2008-02-07 09:37 ---
(In reply to comment #21)
> -fno-tree-reassoc fixes the problem here,
So, what happens to reassociation that sometimes produce (working case):
Rank for D.2002_7 is 327681
Transforming D.2002_7 + i_18 into i_18
--- Comment #24 from ubizjak at gmail dot com 2008-02-07 12:39 ---
It happens that we already have specialization to detect reduction in
rewrite_expr_tree:
--cut here--
The alternative we try is to see if this is a destructive
update style statement, which is like:
b
--- Comment #26 from ubizjak at gmail dot com 2008-02-07 12:56 ---
Testing the patch.
--
ubizjak at gmail dot com changed:
What|Removed |Added
AssignedTo
--- Comment #28 from ubizjak at gmail dot com 2008-02-07 14:15 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
URL
--- Comment #9 from ubizjak at gmail dot com 2008-02-07 20:52 ---
Related to PR33992 ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34720
--- Comment #18 from ubizjak at gmail dot com 2008-02-07 20:47 ---
(In reply to comment #17)
> P2 - this should not block the release (it's not that profiledbootstrap was
> never
> broken in released compilers). It's also hard to analyze (no, I'm not on it,
&g
--- Comment #2 from ubizjak at gmail dot com 2008-02-07 15:44 ---
(In reply to comment #0)
> [EMAIL PROTECTED] testsuite]$ grep dg-options gcc.c-torture/execute/*.c
> gcc.c-torture/execute/pr7284-1.c:/* { dg-options "-std=c89" } */
> gcc.c-torture/execute/wchar_t-
--- Comment #19 from ubizjak at gmail dot com 2008-02-08 14:21 ---
The core of the problem is, that for profiled bootstrap, the call to
normalize() from do_multiply() is simply gone. Gone in the sense, that
normalize() is neither inlined at the call site, neither is called in
--- Comment #20 from ubizjak at gmail dot com 2008-02-08 20:15 ---
(In reply to comment #19)
> So, what upsets gcc's inliner/profiler/whatever to drop the call?
Correction, normalize() gets inlined together with lshift_significand(), but
there is something wrong with inlined
--- Comment #21 from ubizjak at gmail dot com 2008-02-08 20:25 ---
Following patch that forces inlining of normalize breaks normal bootstrap in
exactly the same way, so it looks that there is something wrong with inliner.
Index: real.c
501 - 600 of 6556 matches
Mail list logo
