| Message ID | 59cb3869-3edc-fc80-8b00-815d91e0ff1f@redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | trapv question | expand |
On January 20, 2021 6:52:11 PM GMT+01:00, Andrew MacLeod <amacleod@redhat.com> wrote: >Im looking at the testcase gcc.dg/torture/ftrapv-2.c > >int i = 0x7fffffff; > >int main(void) >{ > pid_t child = fork (); > int status = 0; > if (child == 0) > { > volatile int x = i + 1 < i; > exit (0); > } > > >THis is failing with the new relational work... and I'm looking to >understand whether I should be doing something different, or whether >its >the testcase that is flawed. > >The IL produced is > i.0_1 = i; > _2 = i.0_1 + 1; > _4 = i.0_1 > _2; > _5 = (int) _4; > x ={v} _5; > exit (0); > > >What happens is that since _2 and i.0_1 are signed, and an overflow >would therefore trap, we determines that _2 = i.0_1 + 1; which >implies that _2 > i.0_1 >EVRP then visits the next statement, > _4 = i.0_1 > _2; >and promptly determines that _4 can never be true, and replaces it with > >0. Which then makes the rest of the block dead, and it gets optimized >to > x ={v} 0; > exit (0); > >And then the test case fails because it uses -ftrapv and expects there >to be a trap and it was removed.... > > >IT can all be disabled by not registering that relationship when >flag_trapv is set... my question is whether that is the correct >solution >tho... > >It seems to me it might just be the testcase is assuming that the >addition can not be removed and now that it can be, perhaps a >modification to the test case is more appropriate? something like >simply incrementing i? Yeah, the testcase is flawed since the value of I + 1 is not required. >diff --git a/gcc/testsuite/gcc.dg/torture/ftrapv-2.c >b/gcc/testsuite/gcc.dg/torture/ftrapv-2.c >index 75e464fe557..5824c2fdbb7 100644 >--- a/gcc/testsuite/gcc.dg/torture/ftrapv-2.c >+++ b/gcc/testsuite/gcc.dg/torture/ftrapv-2.c >@@ -20,7 +20,7 @@ int main(void) > int status = 0; > if (child == 0) > { >- volatile int x = i + 1 < i; >+ i = i + 1; But i should then be volatile which should make it LTO proof as well. Otherwise this looks OK. Richard. > exit (0); > } > else if (child == -1) > > >Is that the right thing to do? > >THanks >Andrew
diff --git a/gcc/testsuite/gcc.dg/torture/ftrapv-2.c b/gcc/testsuite/gcc.dg/torture/ftrapv-2.c index 75e464fe557..5824c2fdbb7 100644 --- a/gcc/testsuite/gcc.dg/torture/ftrapv-2.c +++ b/gcc/testsuite/gcc.dg/torture/ftrapv-2.c @@ -20,7 +20,7 @@ int main(void) int status = 0; if (child == 0) { - volatile int x = i + 1 < i; + i = i + 1; exit (0); } else if (child == -1)
Im looking at the testcase gcc.dg/torture/ftrapv-2.c int i = 0x7fffffff; int main(void) { pid_t child = fork (); int status = 0; if (child == 0) { volatile int x = i + 1 < i; exit (0); } THis is failing with the new relational work... and I'm looking to understand whether I should be doing something different, or whether its the testcase that is flawed. The IL produced is i.0_1 = i; _2 = i.0_1 + 1; _4 = i.0_1 > _2; _5 = (int) _4; x ={v} _5; exit (0); What happens is that since _2 and i.0_1 are signed, and an overflow would therefore trap, we determines that _2 = i.0_1 + 1; which implies that _2 > i.0_1 EVRP then visits the next statement, _4 = i.0_1 > _2; and promptly determines that _4 can never be true, and replaces it with 0. Which then makes the rest of the block dead, and it gets optimized to x ={v} 0; exit (0); And then the test case fails because it uses -ftrapv and expects there to be a trap and it was removed.... IT can all be disabled by not registering that relationship when flag_trapv is set... my question is whether that is the correct solution tho... It seems to me it might just be the testcase is assuming that the addition can not be removed and now that it can be, perhaps a modification to the test case is more appropriate? something like simply incrementing i? Is that the right thing to do? THanks Andrew