--- Comment #8 from pinskia at gcc dot gnu dot org 2005-10-27 00:50 ---
For 4.2, this should be fixed on the tree level by load PRE.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23488
--- Comment #7 from steven at gcc dot gnu dot org 2005-10-07 21:21 ---
I don't have time to work on these (new job), so unassigning.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Additional Comments From steven at gcc dot gnu dot org 2005-08-20
00:54 ---
I'm going to look at this a bit more...
--
What|Removed |Added
AssignedTo|unassigned
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-08-19 23:37 ---
It's strange that the load(*) does not get optimized, given that it's in the
same BB as the store that precedes it...
movl%eax, result.1282
(*)movlresult.1282, %eax
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-19
23:31 ---
(In reply to comment #3)
> I am surprised that gcse.c load PRE can't already handle this situation. Is
> something broken, or is it really just not able to handle this? What does
> the
> RTL look like w
--- Additional Comments From steven at gcc dot gnu dot org 2005-08-19
23:26 ---
I am surprised that gcse.c load PRE can't already handle this situation. Is
something broken, or is it really just not able to handle this? What does the
RTL look like when we are in GCSE?
--
htt
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-19
22:35 ---
Further reduced testcase:
int
xtermEnvEncoding(void)
{
static int result;
if (result == 0)
result = 2;
return result;
}
Basicially the issue is that the if is emitted as cmp 0, result instead of w
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-19
21:50 ---
Confirmed. There are two issues here. First the regression was caused by:
2005-07-30 Jan Hubicka <[EMAIL PROTECTED]>
* expr.c (expand_expr_real_1): Do not load mem targets into register.
