https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117695
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
(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).
