[Bug-gnu-arch] [bug #15915] MACHINE_ALIGNMENT miscalculated on PPC32

[Tom Lord]

Follow-up Comment #1, bug #15915 (project gnu-arch):

Wow.  I always knew that `gen-alignment' would eventually
come back and bite me somehow -- I just never knew exactly
how.  Now I do.

If I'm following the reports correctly, the real bug 
is in the invariant check.   The invariant check makes
a false assumption that the machine's strictest alignment
requirements are determined by the size of the largest
scalar type.

The macro MACHINE_ALIGNMENT is poorly named.  It should 
really be something like:
CONSERVATIVE_ESTIMATE_OF_MACHINE_ALIGNMENT

The primary use of MACHINE_ALIGNMENT is to safely wrap
`malloc' in an allocator that adds a header to allocated
memory.   `ar.c' is an example of such an allocator.
The user asks for N bytes.  We want a K byte header.
So we allocate:

   N + ALIGNMENT * ((K + ALIGNMENT - 1) / ALIGNMENT)

bytes, put the header at byte 0, and start the user data
at byte:

   ALIGNMENT * ((K + ALIGNMENT - 1) / ALIGNMENT)

The invariant that we are truly trying to maintain is that,
so long as `malloc' returns memory suitably aligned for anything,
so does our wrapper (such as the `ar' functions).

The actual invariant test in the code tests for a stricter 
condition that happens not to be true in this case.   It's
the invariant, not `gen-alignment', that is bogus.

A fix that showed up on the Red Hat bugzilla involved computing
MACHINE_ALIGNMENT differently.   That "fix" introduces a bug
(that may or may not actually effect existing architectures)
and should not be made.   It's the call to `invariant' that
contains the bug.

-t



    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?func=detailitem&item_id=15915>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/