https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47582
Tony changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Last reconfirmed|2017-07-22 00:00:00
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47582
Tony Poppleton changed:
What|Removed |Added
Last reconfirmed||2017-7-22
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47582
--- Comment #3 from Tony Poppleton ---
Ignore the last comment - hadn't spotted the "int" return value on main...
So the code is actually more correct than previous versions, and no change to
the status of this bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47582
--- Comment #2 from Tony Poppleton ---
Re-testing this with GCC 5.1, the code appears to be even less efficient, for
both cases;
DM1:
.LFB0:
.cfi_startproc
movss b(%rip), %xmm0
xorl%eax, %eax
movss %xmm0,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34653
--- Comment #9 from Tony Poppleton 2013-04-10
02:01:27 UTC ---
GCC 4.8.0 with -O2 produces something similar to the original, so the
regression noted in comment #7 and comment #8 is now resolved.
movzbl (%rdi), %eax
shr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47521
--- Comment #7 from Tony Poppleton 2013-04-10
01:51:36 UTC ---
This appears to be fixed with GCC 4.8.0 and flag -O2. The asm code produced is
now exactly as Jeff said in comment #3:
.file "test.c"
.text
.p2al
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47477
--- Comment #13 from Tony Poppleton
2013-04-10 01:44:18 UTC ---
The test case appears to be fixed in GCC 4.8.0, compiling with just -S and -O3,
the asm
output is now a much simpler:
.file "test.c"
.text
.p2al
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35926
--- Comment #8 from Tony Poppleton 2013-04-10
01:42:20 UTC ---
This appears to be fixed in GCC 4.8.0, compiling with just -S and -O3, the asm
output is now a much simpler:
.file "test.c"
.text
.p2align 4,,15
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47521
--- Comment #5 from Tony Poppleton 2011-02-03
14:16:01 UTC ---
As a quick test, would this be fixed by re-ordering the register file to move
eax above edx?
If so, then another possible fix to this would be to effectively re-run the RA
pass multi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47582
Summary: Combine chains of movl into movq
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: rtl-optimization
AssignedTo: u
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47581
Summary: [4.6 regression] Unnecessary adjustments to stack
pointer
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34653
Tony Poppleton changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47555
--- Comment #6 from Tony Poppleton 2011-02-01
14:45:28 UTC ---
Out of interest, could this parameter of 20 be automatically tuned based on the
available RAM?
For systems with a lot of RAM, it might make sense to increase the parameter
above 20 (
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35926
Tony Poppleton changed:
What|Removed |Added
Last reconfirmed|2008-12-28 06:57:47 |2011-02-01 13:13
Known to fail|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47521
Tony Poppleton changed:
What|Removed |Added
Summary|Unnecessary usage of edx|[Regression 4.4/4.5/4.6]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46235
--- Comment #4 from Tony Poppleton 2011-01-28
18:08:15 UTC ---
As a quick test, I commented out the block with the following comment in
fold-const.c:
/* If this is an EQ or NE comparison with zero and ARG0 is
(1 << foo) & bar, conv
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47521
Tony Poppleton changed:
What|Removed |Added
Known to work||4.3.5
Known to fail|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47521
Summary: Unnecessary usage of edx register
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: rtl-optimization
AssignedTo: unassi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46235
--- Comment #3 from Tony Poppleton 2011-01-28
17:02:50 UTC ---
Actually what I said above isn't correct - had it compiled down to "bt $4, %al"
then it would make sense to do that special case, but as it used "testb" it is
inconclusive.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46235
--- Comment #2 from Tony Poppleton 2011-01-28
16:55:48 UTC ---
Based on Richard's comment, I tried a modified version of the code replacing
the (1 << x) with just (16).
This shows that GCC (4.6 & 4.5.2) does perform an optimization similar to ll
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47477
--- Comment #5 from Tony Poppleton 2011-01-27
17:58:12 UTC ---
The modified testcase in comment #4 also fixes the original bug with redundent
push/pop of BX (as described in PR35926), so fixing this during tree
optimizations would be good.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35926
--- Comment #6 from Tony Poppleton 2011-01-27
16:55:26 UTC ---
For the record, the additional movl noticed above in GCC 4.6.0 has been
factored out into PR47477
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47477
Summary: [4.6 regression] Sub-optimal mov at end of method
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
A
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35926
--- Comment #5 from Tony Poppleton 2011-01-25
19:33:20 UTC ---
I can confirm this still exists on both GCC 4.5.1 and GCC 4.6.0 (20110115),
when compiling with -O3.
I did some basic investigation into the files produced by the --dump-tree-all
fla
24 matches
Mail list logo
