[Bug c++/21387] New: Unaligned writes on MIPSEL systems after typecast

[Bug c++/21387] New: Unaligned writes on MIPSEL systems after typecast

[maarten at contemplated dot nl]

See code below. After type-casting, the compiler incorrectly assumes that
'a.unaligned_int' is aligned on a word boundary. On a MIPSEL system (here a
Cobalt RaQ 2) a 'sw' assembler instruction is generated to store the value in
memory, resulting in a 'Segmentation fault'. Changing the 'sw' instruction to
'swl', the problem is solved.


#include <stdint.h>

#pragma pack(1)
typedef struct  {
        int8_t  byte;
        int32_t unaligned_int;
        } test_unaligned;
#pragma pack()

int main(int argc, char *argv[]) {
        test_unaligned a;

        *((int32_t *) a.unaligned_int) = 0x123456;

        return(0);
        }

-- 
           Summary: Unaligned writes on MIPSEL systems after typecast
           Product: gcc
           Version: 3.3.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: maarten at contemplated dot nl
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: mipsel-netbsd2.0
  GCC host triplet: mipsel-netbsd2.0
GCC target triplet: mipsel-netbsd2.0


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

[Bug target/21387] Unaligned writes on MIPSEL systems after typecast

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-04 19:10 -------
I think this is invalid because the standard talks about alignment and types.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c++                         |target


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

[Bug target/21387] Unaligned writes on MIPSEL systems after typecast

[rsandifo at gcc dot gnu dot org]

------- Additional Comments From rsandifo at gcc dot gnu dot org  2005-05-05 07:11 -------
I'm confused by this report.  You use:

    *((int32_t *) a.unaligned_int) = 0x123456;

which reads the value of a.unaligned_int, casts it from an integer
to a pointer, and then dereferences the pointer.  Why do you expect
the store to be unaligned?  There's no reason to assume that,
just because the address was stored in an unaligned location,
the thing it points to is also unaligned.

Did you mean to write &a.aligned_int instead?  If so, then like
Andrew says, that's invalid.  You can't access an unaligned object
(a.unaligned_int) as though it had an aligned type (int32_t).

Richard

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rsandifo at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |WAITING


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

[Bug target/21387] Unaligned writes on MIPSEL systems after typecast

[maarten at contemplated dot nl]

------- Additional Comments From maarten at contemplated dot nl  2005-05-05 11:49 -------
(In reply to comment #2)

You are completely right, the code above merely demonstrates what happens when
one writes to an illegal address. The correct version,

*((int32_t *) &a.unaligned_int32) = 0x123456;

does work. Sorry, result of 'compressing' the problem.

My 'unaligned write' problem is, however, still there. I stumbled over it when
trying to compile code where copying of 16 bytes (in a char array) was
implemented as two reads and writes of int64_t. The problem occurs when
typecasting char arrays to integer types, see modified example:

1: 

#include <stdint.h>

int main(int argc, char *argv[]) {
        char x[100];

        *((int32_t *) ((char *) (x))) = 0x123456;           // ok
        *((int32_t *) ((char *) (x+4))) = 0x123456;         // ok
        *((int32_t *) ((char *) (x+1))) = 0x123456;         // fails

        return(0);
        }

2: (more related to original)

#include <stdint.h>

#pragma pack(1)
typedef struct  {
        int8_t  byte;                       // removing this byte, code executes
        char unaligned_int32[4];
        } test_unaligned;
#pragma pack()

int main(int argc, char *argv[]) {
        test_unaligned a;

        *((int32_t *) a.unaligned_int32) = 0x123456;    // fails
 
        return(0);
        }



-- 


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

[Bug target/21387] Unaligned writes on MIPSEL systems after typecast

[maarten at contemplated dot nl]

------- Additional Comments From maarten at contemplated dot nl  2005-05-05 11:56 -------
(In reply to comment #2)

Reading your reply further, I understand that the behavior I observere is
correct and related to the fact that the 'int32_t' type is assumed to be aligned. 

It is not a bug then, but merely a bit of a problem for me. Is there a typecast
to tell the compiler that the adress references an unaligned integer, i.e.
something like int32_unaligned_t?

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |SUSPENDED


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

[Bug target/21387] Unaligned writes on MIPSEL systems after typecast

[rsandifo at gcc dot gnu dot org]

------- Additional Comments From rsandifo at gcc dot gnu dot org  2005-05-05 12:01 -------
> Reading your reply further, I understand that the behavior I observere is
> correct and related to the fact that the 'int32_t' type is assumed to be
> aligned.

Right.

> It is not a bug then, but merely a bit of a problem for me. Is there a
> typecast to tell the compiler that the adress references an unaligned
> integer, i.e. something like int32_unaligned_t?

'Fraid not.  The "packed" attribute can't be applied to scalars
(and would in any case interfere a bit with the type system).
I think the best you can do is define a packed struct containing
a single int32_t field.  Yes, it will clutter the code a bit,
but it will be type-safe.

Richard


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|SUSPENDED                   |RESOLVED
         Resolution|                            |INVALID


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