[Bug ada/50934] New: Allocated address for new controlled object is offset by 16 bytes

["simon at pushface dot org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50934

             Bug #: 50934
           Summary: Allocated address for new controlled object is offset
                    by 16 bytes
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: ada
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: simon@pushface.org


Created attachment 25674
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25674
Demonstrator

When I create a controlled type and an access type, the address returned by the
'new' is 16 bytes greater than the address determined within the allocator.

I've attached an example which shows this with limited controlled, but it also
happens with non-limited.

I originally reported this to AdaCore as [K916-011 public] with regard to
fixed-size storage pools on GNAT GPL 2011 on Mac OS X. Now, however,

* GCC 4.7.0 fails on Mac OS X with both fixed-size and global pools,
* GNAT GPL 2011 fails similarly on Debian 6 (32 bit),

so I've taken the liberty of marking the Severity as 'major'.

The attached code contains instrumented versions of the library allocators, and
should be compiled "gnatmake -a allocation_test.adb".

Running with
$ gcc -v
Using built-in specs.
COLLECT_GCC=/opt/gcc-4.7-180524/bin/gcc
COLLECT_LTO_WRAPPER=/opt/gcc-4.7-180524/libexec/gcc/x86_64-apple-darwin11/4.7.0/lto-wrapper
Target: x86_64-apple-darwin11
Configured with: ../gcc-trunk-svn/configure CC='gcc -D_FORTIFY_SOURCE=0'
--prefix=/opt/gcc-4.7-180524 --disable-multilib --enable-languages=c,ada
--build=x86_64-apple-darwin11
Thread model: posix
gcc version 4.7.0 20111026 (experimental) [trunk revision 180524] (GCC) 

I get

$ ./allocation_test --------------------------------------------------
Allocation from fixed-size pool
First_Free = 0
Pool_Size allocated 88 at      16#7FDD68400928#, The_Pool at     
16#7FDD68400928#
A ( 1) allocated at      16#7FDD68400938# or  140588913527096
First_Free = 0
Pool_Size allocated 88 at      16#7FDD68400970#, The_Pool at     
16#7FDD68400928#
A ( 2) allocated at      16#7FDD68400980# or  140588913527168
First_Free = 0
Pool_Size allocated 88 at      16#7FDD684009B8#, The_Pool at     
16#7FDD68400928#
A ( 3) allocated at      16#7FDD684009C8# or  140588913527240
First_Free = 0
Pool_Size allocated 88 at      16#7FDD68400A00#, The_Pool at     
16#7FDD68400928#
A ( 4) allocated at      16#7FDD68400A10# or  140588913527312
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa?    @h?(    @h?
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
@h?p    @h?
cccccccccccccccccccccccccccccccccccccccccccccccc?#??    @h?
dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd
--------------------------------------------------
Allocation from global pool
Pool_Global allocated 88 at  140588913527376
B ( 1) allocated at      16#7FDD68400A60# or  140588913527392
Pool_Global allocated 88 at  140588913527472
B ( 2) allocated at      16#7FDD68400AC0# or  140588913527488
Pool_Global allocated 88 at  140588913527568
B ( 3) allocated at      16#7FDD68400B20# or  140588913527584
Pool_Global allocated 88 at  140588913527664
B ( 4) allocated at      16#7FDD68400B80# or  140588913527680
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc
dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd
--------------------------------------------------

The corruption in the first section, the fixed-size storage pool, is obvious;
there should be 4 lines, each containing 64 'a's, 'b's etc. The reason is to be
seen in the trace output; for example, in the fixed-size section,

Pool_Size allocated 88 at      16#7FDD68400928#, The_Pool at     
16#7FDD68400928#
A ( 1) allocated at      16#7FDD68400928# or  140588913527096

the internally allocated address is 16#7FDD68400928# but the value seen by the
calling routine is 16#7FDD68400928#, 16#10# greater.

In the default section, the corruption is less obvious, presumably because
malloc() is allocating spare space anyway, but in the trace output

Pool_Global allocated 88 at  140588913527376
B ( 1) allocated at      16#7FDD68400A60# or  140588913527392

the internal and external addresses are again off by 16 (I had to use GNAT.IO
internally to avoid elaboration circularity).