https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117695
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #4)
> (In reply to 王淳洋 from comment #3)
> > #include <signal.h>
> > #include <unistd.h>
> > #include <stdio.h>
> > #include <stdlib.h>
> > unsigned long Run_Index;
> > void report()
> > {
> > fprintf(stderr,"COUNT|%ld|1|lps\n", Run_Index);
> > exit(0);
> > }
> > int main (argc, argv)
> > int argc;
> > char *argv[];
> > {
> > int duration = atoi(argv[1]);
> > Run_Index = 0;
> > signal(SIGALRM, report);
> > alarm(duration);
> > int ans = 0;
> > for (Run_Index = 1; ; Run_Index++)
> > {
> > ans += Run_Index;
> > }
> > printf("%d\n", ans);
> > }
> >
> > I have written a shorter test to describe the situation I encountered. This
> > time it has nothing to do with LTO. gcc -O2 will eliminate the loop in
> > test.c, resulting in the loss of calculations related to Run_Index, even
> > though there is a use of Run_Index in the report function. I wonder if this
> > is reasonable?
>
> Well. GCC indeed doesn't consider a signal handler inspecting Run_Index
> which otherwise is known to be not accessed and thus the loop is optimized
> to
>
> for (;;) {}
>
> I think you'd have to mark Run_Index volatile for asynchronous inspection.
> Otherwise GCC would commit its value only when the program terminates
> (never).
Note that the 'asn += Run_Index' addition is still optimized away since
the printf isn't reachable and thus 'ans' is unused.
