https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104763
--- Comment #8 from 。 <570070308 at qq dot com> ---
(In reply to Richard Biener from comment #7)
> Note that the case of an endless loop is somewhat special since the store
> is dead there since there is no way to reach a load from that point with
> C standard methods. So one could also argue the optimization is valid
> and this bug is invalid.
>
> How did you end up with this case?
I agree with this bug is invaild.
I do something on memory 0xb8000, this is because the 0xb8000 is the video
memory, and can display on screen.
However gcc don't know it, and I think it doesn't need to know it. Gcc can
simply think that all the writing/reading on memory is useless, unless the
writing/reading on memory will affect subsequent function calls or the function
return. This way gcc can better optimize the code.
According to this, the while(1){} will never return or call a function, so gcc
can think that all the writing/reading on 0xb8000 before while(1){} is useless.
A way to tell gcc that writing/reading on 0xb8000 will make an impact is to
change `*i` to `*(volatile size_t *)i`, and it really work.
So I think:
test.c:
```
void move_up()
{
for ( size_t* i=(size_t *)(0xb8000+160*24); ; )
{
*i=0x0700070007000700;
if ( i == (size_t *)(0xb8000+160*24)+2 )
{
break;
}
++i;
}
while (1){}
}
```
compile to
```
move_up:
jmp move_up
```
and test.c:
```
void move_up()
{
for ( size_t* i=(size_t *)(0xb8000+160*24); ; )
{
*(volatile size_t *)i=0x0700070007000700;
if ( i == (size_t *)(0xb8000+160*24)+2 )
{
break;
}
++i;
}
while (1){}
}
```
compile to:
```
move_up:
movabsq $504410854964332288, %rax
movq %rax, 757504
movq %rax, 757512
movq %rax, 757520
.L2:
jmp .L2
```
is the best.
