Bug 53046

Summary: [4.8 Regression] New libstdc++ test failures
Product: gcc Reporter: H.J. Lu <hjl.tools>
Component: testsuiteAssignee: 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
On Linux/x86-64, revision 186596 gave

FAIL: 23_containers/bitset/operations/constexpr-2.cc (test for excess errors)
FAIL: 25_algorithms/stable_partition/mem_check.cc execution test
FAIL: 25_algorithms/stable_sort/mem_check.cc execution test

Revision 186588 is OK.
Comment 1 Hans-Peter Nilsson 2012-04-20 02:30:17 UTC
Noticed the mem_check.cc ones (not the constexpr-2.cc one) for cris-elf too, 186591:186599.
Comment 2 Richard Biener 2012-04-20 09:21:32 UTC
Confirmed.
Comment 3 H.J. Lu 2012-04-21 22:42:18 UTC
It is caused by revision 186592:

http://gcc.gnu.org/ml/gcc-cvs/2012-04/msg00543.html
Comment 4 Richard Biener 2012-04-23 09:17:10 UTC
I belive those are likely out-of-bound accesses in the testcases.
Comment 5 Paolo Carlini 2012-04-23 09:37:08 UTC
Chris, can you have a look to the mem_check tests?
Comment 6 Chris Jefferson 2012-04-23 09:44:11 UTC
Yes, will check.
Comment 7 Chris Jefferson 2012-04-23 09:57:12 UTC
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.
Comment 8 Paolo Carlini 2012-04-23 10:36:28 UTC
Oops, thanks a lot Chris!! I'll do the change.
Comment 9 Chris Jefferson 2012-04-23 10:54:57 UTC
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...
Comment 10 paolo@gcc.gnu.org 2012-04-23 11:17:34 UTC
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
Comment 11 Paolo Carlini 2012-04-23 11:20:26 UTC
Done.

(Chris, if you are interested in discussing optimizer issues, please move the discussion to the mailing list!)
Comment 12 Richard Biener 2012-04-23 11:42:28 UTC
(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).
Comment 13 paolo@gcc.gnu.org 2012-04-23 15:24:49 UTC
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