https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117695
--- Comment #6 from 王淳洋 <koule2333 at gmail dot com> ---
(In reply to Richard Biener from comment #5)
> (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.
Got it. thanks a lot.
