On 12/3/18 9:25 AM, Jakub Jelinek wrote: > Hi! > > Here is a fix for the testcase, so that it doesn't FAIL pretty much > everywhere. > > On Fri, Nov 30, 2018 at 04:07:31PM -0700, Jeff Law wrote: >>> PR middle-end/64242 >>> * gcc.c-torture/execute/pr64242.c: New test. >> THanks for tracking this down. I'd like to have this run through my >> next testing cycle, so I went ahead and installed it for you. > > What I've tested: > 1) x86_64-linux {-m32,-m64} - without the testcase patch, the testcase FAILs > without or with the builtins.c change; with the testcase patch and > witout the builtins.c change, there is > FAIL: gcc.c-torture/execute/pr64242.c -O2 execution test > FAIL: gcc.c-torture/execute/pr64242.c -O3 -g execution test > FAIL: gcc.c-torture/execute/pr64242.c -Os execution test > for -m32 and no FAILs for -m64, with the builtins.c change the tests > passes on both -m32 and -m64 > 2) powerpc64-linux {-m32,-m64} - without the testcase patch, the testcase > FAILs without and with the builtins.c change for -m32. With the testcase > patch and without the builtins.c change, there is > FAIL: gcc.c-torture/execute/pr64242.c -O0 execution test > FAIL: gcc.c-torture/execute/pr64242.c -O1 execution test > FAIL: gcc.c-torture/execute/pr64242.c -O2 execution test > FAIL: gcc.c-torture/execute/pr64242.c -O3 -g execution test > FAIL: gcc.c-torture/execute/pr64242.c -Os execution test > for -m32 and > FAIL: gcc.c-torture/execute/pr64242.c -O0 execution test > FAIL: gcc.c-torture/execute/pr64242.c -O1 execution test > for -m64, with the builtins.c change everything passes > 3) aarch64-linux - both without and with the testcase patch, the > testcase FAILs without the builtins.c change and passes with it > > Ok for trunk? > > 2018-12-03 Jakub Jelinek <ja...@redhat.com> > > PR middle-end/64242 > * gcc.c-torture/execute/pr64242.c (foo, bar): New functions. > (p): Make it void *volatile instead of volatile void *. > (q): New variable. > (main): Add a dummy 32-byte aligned variable and escape its address. > Don't require that the two __builtin_alloca (0) calls return the > same address, just require that their difference is smaller than > 1024 bytes. Yea, my tester fell over the new test on multiple targets. THanks for fixing it up.
OK jeff