Created attachment 23895 [details] Reduced gfortran.dg/coarray_13.f90 exposing the failure This test previously passed, now it fails. Revision r171949 caused this regression. Since then it fails as follows: Running /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gfortran.dg/dg.exp ... ... FAIL: gfortran.dg/coarray_13.f90 -O2 execution test FAIL: gfortran.dg/coarray_13.f90 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/coarray_13.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/coarray_13.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/coarray_13.f90 -O3 -g execution test The messages in gfortran.log are similar: PASS: gfortran.dg/coarray_13.f90 -O2 (test for excess errors) core: 4 byte write to unmapped address 0x10190 at 0x146 program stopped with signal 11. Author/committer of suspect revision CC:ed. Looking into this, I see badness in the form of a modified test-case. Multiple tests for new (or greatly improved) functionality were apparently added to an existing test-case. While that worked for the tested platform, it didn't work for cris-elf and I'd guess also some other unfortunate platform. So, because an existing test was modified rather than new tests added, it comes out as a regression. That's why existing test-cases should never be upgraded like that; they should be fixed only if they were actually wrong or just enough to maintain the intention of the test when gcc gets too smart. I'm adding a reduced test-case which fails at r172016; all but a single test and call to abort. Hopefully this is enough to spark some ideas as to the cause. I can assist with some target-specific testing; execution tracing etc. but note that the general instructions for building and running on a simulator toolchain apply to cris-elf. (For the record, at revision r171949 the tree was in a flux, with 52 regressions in total for cris-elf, but that's been resolved to this single regression at r172016. I tested r171943 (last regression-free revision before r171949) patched with the single commit of r171949; that combination also fails.)
Confirm on x86-64-Linux. In a way I am surprised that it does not crash there - but at least valgrind properly warns. The issue is: allocate(B(3)[-4:*]) call three_b(3,B) ... subroutine three_b(n,A) integer :: n integer :: A(-1:3,0:4,-2:5,-4:7)[n+2:n+5,n-1:*] ... A(1,1,1,1) = 42 Thus, one passes "B" which is a size 3 array as actual argument to a dummy array "A" which has the size 2400. (That's questionable usage, but still valid.) If one now accesses the element A(1,1,1,1) on effectively accesses array element B(144) which is not that healthy if B has only 3 elements.
Author: burnus Date: Wed Apr 6 18:32:27 2011 New Revision: 172061 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172061 Log: 2011-04-06 Tobias Burnus <burnus@net-b.de> PR fortran/18918 PR fortran/48477 * gfortran.dg/coarray_13.f90: Avoid out-of-bounds access. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/coarray_13.f90
Please confirm that it now works - and if so, please close the PR. Thanks for the report!
(In reply to comment #3) > Please confirm that it now works - and if so, please close the PR. My autotester is back to no regressions at r172064. Thanks for the quick turnaround!