Summary: | [4.8 Regression] New libstdc++ test failures | ||
---|---|---|---|
Product: | gcc | Reporter: | H.J. Lu <hjl.tools> |
Component: | testsuite | Assignee: | Paolo Carlini <paolo.carlini> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | areg.melikadamyan, chris, hp, rguenth |
Priority: | P3 | ||
Version: | 4.8.0 | ||
Target Milestone: | 4.7.1 | ||
Host: | Target: | ||
Build: | Known to work: | ||
Known to fail: | Last reconfirmed: | 2012-04-20 00:00:00 |
Description
H.J. Lu
2012-04-19 17:25:30 UTC
Noticed the mem_check.cc ones (not the constexpr-2.cc one) for cris-elf too, 186591:186599. Confirmed. It is caused by revision 186592: http://gcc.gnu.org/ml/gcc-cvs/2012-04/msg00543.html I belive those are likely out-of-bound accesses in the testcases. Chris, can you have a look to the mem_check tests? Yes, will check. While I haven't yet got a recent copy of gcc trunk compiled, it does indeed look like an out-of-bounds error, but just a 'testsuite' problem. At the top of both mem_check tests as a 'const int A[]' array with 29 elements, which we read 30 elements of. If doesn't matter what the extra element is, we just want an array of any 30 integers, which is why this hasn't caused problems before. Oops, thanks a lot Chris!! I'll do the change. Looking at the output of -fdump-tree-all, it looks like the compiler optimises the loop which accesses an array out of bounds to: while(true); Is this expected behaviour? That seems like terrible output for every situation... Author: paolo Date: Mon Apr 23 11:17:28 2012 New Revision: 186701 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186701 Log: 2012-04-23 Chris Jefferson <chris@bubblescope.net> PR testsuite/53046 * testsuite/25_algorithms/stable_partition/mem_check.cc: Fix size of array A. * testsuite/25_algorithms/stable_sort/mem_check.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/25_algorithms/stable_partition/mem_check.cc trunk/libstdc++-v3/testsuite/25_algorithms/stable_sort/mem_check.cc Done. (Chris, if you are interested in discussing optimizer issues, please move the discussion to the mailing list!) (In reply to comment #9) > Looking at the output of -fdump-tree-all, it looks like the compiler optimises > the loop which accesses an array out of bounds to: > > while(true); > > Is this expected behaviour? That seems like terrible output for every > situation... It's similar to other cases where undefined behavior leads to the GIGO principle. Other cases being a simple integer overflow inside a loop (not even necessarily the loop induction variable itself). Author: paolo Date: Mon Apr 23 15:24:44 2012 New Revision: 186713 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186713 Log: 2012-04-23 Chris Jefferson <chris@bubblescope.net> PR testsuite/53046 * testsuite/25_algorithms/stable_partition/mem_check.cc: Fix size of array A. * testsuite/25_algorithms/stable_sort/mem_check.cc: Likewise. Modified: branches/gcc-4_7-branch/libstdc++-v3/ChangeLog branches/gcc-4_7-branch/libstdc++-v3/testsuite/25_algorithms/stable_partition/mem_check.cc branches/gcc-4_7-branch/libstdc++-v3/testsuite/25_algorithms/stable_sort/mem_check.cc |