https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70017
Bug ID: 70017
Summary: Ada: c52103x test failure on s390x
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
Assignee: unassigned at gcc dot gnu.org
Reporter: vogt at linux dot vnet.ibm.com
CC: ebotcazou at gcc dot gnu.org, krebbel at gcc dot gnu.org
Target Milestone: ---
Host: s390x
Target: s390x
My knowledge of Ada is practically zero, but I'm debugging a few Ada test
failures on s390x (gcc-4.7 or earlier).
-- snip --
,.,. C52103X ACATS 2.5 16-02-29 16:03:21
---- C52103X CHECK THAT IN ARRAY ASSIGNMENTS AND IN SLICE ASSIGNMENTS,
THE LENGTHS MUST MATCH; ALSO CHECK WHETHER
CONSTRAINT_ERROR OR STORAGE_ERROR ARE RAISED FOR LARGE
ARRAYS.
- C52103X NO CONSTRAINT_ERROR FOR TYPE WITH 'LENGTH = INTEGER'LAST +
3.
raised STORAGE_ERROR : System.Stack_Checking.Operations.Stack_Check: stack
over\
flow detected
FAIL: c52103x
-- snip --
This happens here:
-- snip --
TYPE TA42 IS ARRAY(
INTEGER RANGE IDENT_INT(-2)..IDENT_INT(INTEGER'LAST)
) OF BOOLEAN ;
...
OBJ_DCL: DECLARE -- THIS BLOCK DECLARES TWO BOOLEAN ARRAYS THAT
-- HAVE INTEGER'LAST + 3 COMPONENTS;
-- STORAGE_ERROR MAY BE RAISED.
ARR41 : TA41 ;
ARR42 : TA42 ;
-- snip --
This is a reduced test (that fails with ulimit -s 131072):
-- snip --
procedure c52103x is
begin
declare
type T is array(integer range -2..10000000) of boolean;
begin
declare
A : T;
begin
null;
end;
end;
end;
-- snip --
As far as I understand this code, it assumes that only the first few memory
pages of the array are allocated in the stack initially and the rest is
allocated when actually accessed. However, on s390x first a snippet of three
pages is allocated and checked, followed immediately by the rest of the array
plus another check that fails because the stack is too small for that:
-- snip --
_ada_c52103x:
stmg %r11,%r15,88(%r15)
larl %r13,.L4
aghi %r15,-168
lgr %r11,%r15
lgr %r1,%r15
aghi %r1,-12280 # <-- first three pages
lgr %r2,%r1
brasl %r14,_gnat_stack_check # <-- OK
lgr %r1,%r15
lgr %r12,%r1
lg %r1,.L5-.L4(%r13)
agr %r1,%r15 # <-- rest of array
lgr %r2,%r1
brasl %r14,_gnat_stack_check # <-- FAIL
...
.section .rodata
.align 8
.L4:
.L6:
.quad -10000008
.L5:
.quad -10012288
-- snip --
(Stack on s390x grows down.)
I've no idea whether this is the intended behaviour (i.e. the test case has a
bug) or not, and if not whether I should look for the bug in the s390x backend
or somewhere else.
