On January 20, 2021 6:52:11 PM GMT+01:00, Andrew MacLeod <amacl...@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
