This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ACATS c380004

    what I don't understand is: why does it need to allocate so much
    memory?  I've looked through the test and at first glance it looks
    perfectly harmless.  

You're getting well beyond my knowlege of Ada, but let me try and I'll
ask Ed Schonberg to correct and clarify any errors I make.  Ed: please
Cc to

    What is more, gcc at the pre-ssa tag allocates only mild amounts of
    memory, does not try to access unallocated memory (according to
    valgrind), and passes the test.  This seems to indicate that vast
    quantities of memory are not needed.  Is it really succeeding by
    accident as you seem to suggest?

Yes.  Try it on a 64-bit machine sometime and see what it tries to allocate.

Consider the following Ada code:

	type r1 (d: positive := 0) is record
	    f1: array (1..d) of integer;
	end record;

	type r2 is record f2: r1; end record;

	foo: r2;

Because R2 says to use the largest possible size of record R1 and the
bounds are the type Positive, that's an array whose bounds are 0 to 2**31-1,
which is quite large.  FOO is the same size.

In in this test, we have a similar construction except that the discriminant
is to a protected type, specifically,

        protected type Poe (D3 : Integer := F1) is
            entry E (D3 .. F1);    -- F1 evaluated
            function Is_Ok (D3 : Integer; E_First : Integer; E_Last : Integer)
                           return Boolean;
        end Poe;

Note that if E were an array, the lowest bound would be Integer'First,
which is -2**31.  So if we allocate an object of this type (which the
ACATS test does) and implement it as an array, we'd be allocating an
array of 2**31 elements.  That overflows.  And that's indeed the

What I'm told is that there's an alternate implementation of protected
types that doesn't require the formation of this array.  But since no
real program would ever likely do something like the above (the ACATS
tests *love* making arrays whose bounds are the lowest or largest
integer), the existing implementation is adequate, in practice, and
the only motivation to "fix" the implementation is this precise test.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]