Re: c/2894: Incorrect union padding on Linux/ARM port; other architectures correct

Re: c/2894: Incorrect union padding on Linux/ARM port; other architectures correct

[Neil Booth]

The following reply was made to PR c/2894; it has been noted by GNATS.

From: Neil Booth <neil@daikokuya.demon.co.uk>
To: jeffm@suse.com
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: c/2894: Incorrect union padding on Linux/ARM port; other architectures correct
Date: Tue, 22 May 2001 06:49:12 +0100

 jeffm@suse.com wrote:-
 
 > >Category:       c
 > >Synopsis:       Incorrect union padding on Linux/ARM port; other architectures correct
 
 Hi Jeff,
 
 The above 2 lines make it clear that this is not really a "c" category
 bug, but a target bug.  In future, please be more precise with the
 categorisation - it does save time.
 
 Thanks,
 
 Neil.

c/2894: Incorrect union padding on Linux/ARM port; other architectures correct

[jeffm]

>Number:         2894
>Category:       c
>Synopsis:       Incorrect union padding on Linux/ARM port; other architectures correct
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    unassigned
>State:          open
>Class:          wrong-code
>Submitter-Id:   net
>Arrival-Date:   Mon May 21 22:26:00 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     Jeff Mahoney <jeffm@suse.com>
>Release:        gcc version 2.95.2; gcc version 2.95.4 20010319 (Debian prerelease); gcc version 3.1 20010512 (experimental) (from netwinder.org)
>Organization:
>Environment:
Debian Linux [stable]
Intel StrongARM-1110 rev 6 (v4l)
Compaq iPAQ
>Description:
Incorrect union padding is produced on the Linux/ARM port. It seems that the alignment padding corrections are applied too early, so the size of the structure is incorrectly calculated, thus a structure is sized too large. This problem is surfacing in running ReiserFS on Linux/ARM, where incorrect sizes/offsets for on-disk structures are being generated. Linux/PPC, Linux/Intel, Solaris/Sparc, and Tru64/Alpha ports produce correct sizes/offsets. A simplified test case is attached.

See PR #2547 for somewhat related info.
>How-To-Repeat:
#include <stdio.h>
#include <linux/types.h>
struct test2
{
    __u32 v1;
    __u32 v2;
    __u64 v3;
    __u16 v4_5;
    __u16 v6;
    __u32 v7;
} __attribute__ ((__packed__));
 
struct test
{
    __u32 v1;
    __u32 v2;
    __u64 v3;
    union {
        __u16 v4;
        __u16 v5;
    } u;
    __u16 v6;
    __u32 v7;
} __attribute__ ((__packed__));

int
main( void )
{
    printf( "sizeof( struct test ) = %d\n", sizeof( struct test ) );
    printf( "sizeof( struct test2 ) = %d\n", sizeof( struct test2 ) );
}
Output for ARM:
sizeof( struct test ) = 26
sizeof( struct test2 ) = 24

(without __attribute__ ((__packed__)), sizeof( struct test ) = 28)

Output for other tested arches (see desc. for list):
sizeof( struct test ) = 24
sizeof( struct test2 ) = 24
(results are the same without __attribute__ ((__packed__)) )
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: