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=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=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=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=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
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 #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
--- 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=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=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=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=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=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
Summary|Unnecessary usage of edx|[Regression 4.4/4.5/4.6]
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=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=34653
Tony Poppleton changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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=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=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
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
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
--- 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,
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.
24 matches
Mail list logo
