https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117695
王淳洋 <koule2333 at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #7 from 王淳洋 <koule2333 at gmail dot com> ---
(In reply to 王淳洋 from comment #6)
> (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.
