bugGNU arch -- a revision control system - Bugs: bug #15915, MACHINE_ALIGNMENT miscalculated on...


bug #15915: MACHINE_ALIGNMENT miscalculated on PPC32

Submitter:  None
Submitted:  Mon 27 Feb 2006 02:10:29 PM UTC
Category:  tla Severity:  3 - Normal
Item Group:  bug Status:  Ready For Test
Privacy:  Public Open/Closed:  Open
Release:  1.3.4
Fixed Release:  1.3.5
Merge Request?:  None
Your Archive Name: 
Your Archive Location: 
Assigned to:  atai
* Mandatory Fields

Add a New Comment Rich Markup

Sun 29 Jun 2008 11:41:13 PM UTC, comment #5: 
Wed 22 Mar 2006 09:42:52 AM UTC, comment #4: 

in hackerlab

+  technique borrowed from
+ Computing Memory Alignment Restrictions
+     of Data Types in C and C++
+          by Tom Lokovic
 #undef TYPE
-  this = gcd(sizeof (SCALAR), sizeof (struct flux__align_ ## STRUCT)); \
+  this = ((sizeof(struct_ ## STRUCT) > sizeof(SCALAR)) ? \
+           sizeof(struct_ ## STRUCT) - sizeof(SCALAR) : sizeof(SCALAR)) ;\
   if (this > best) \
     best = this;

ready for test on 32-bit PowerPC.  Who can let me have access to such an environment?

Andy Tai <atai>
Group administrator
Fri 03 Mar 2006 01:53:53 PM UTC, comment #3: 

This issue was a bug in the Red Hat development glibc.  I think this can be closed now.

One suggestion from the RH bugzilla:

"BTW, sizeof (long double) is completely wrong thing to check when you check alignment, you need to check _alignof_ (long double).  On many architectures, some types have different alignment than their size, e.g. on sparc32 or s390 long double is 8 byte aligned, but 16 byte in size."

Josh Boyer <jwboyer>
Mon 27 Feb 2006 07:00:43 PM UTC, comment #2: 

Yes, the "fix" in the RH bugzilla is not a fix at all.  It simply allowed the package to build without any negative effects for Fedora Extras at this moment.  That is why I opened this bug to begin with :).

Josh Boyer <jwboyer>
Mon 27 Feb 2006 06:27:08 PM UTC, comment #1: 

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:

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:


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


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.


Tom Lord <tomlord>
Group Member
Mon 27 Feb 2006 02:10:29 PM UTC, original submission:  

The gen-alignment program that calculates the MACHINE_ALIGNMENT macro generates the wrong alignment on PPC32.  With the newest glibc, the ABI changed for PPC such that sizeof(long double) returns 16 instead of 8.  However, malloc only guarantees alignment for 2 sizeof(void ), which is still 8 bytes.

When attempting to build tla on PPC32, the unit-ar test fails because of this as it is checking for 16 byte alignment when it should be checking for 8 byte alignment.  See:


for more details.



(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


CC list is empty


There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

Only logged-in users can vote.


Follow 4 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2006-03-22 atai StatusNone Ready For Test
    Fixed Release 1.3.5
2006-03-20 atai Assigned toNone atai
2006-02-27 jwboyer Carbon-Copy- Added -email is unavailable-

Back to the top

Powered by Savane 3.13-4b48.
Corresponding source code