Bug 59958 - alpha does not deal with non-aligned returns from malloc() when doing byte wise access
Summary: alpha does not deal with non-aligned returns from malloc() when doing byte wi...
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 4.8.3
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-01-27 13:32 UTC by Martin Husemann
Modified: 2014-01-29 13:51 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
generated assembler code (cc -O2 -S test.c) (665 bytes, text/plain)
2014-01-27 13:32 UTC, Martin Husemann
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Husemann 2014-01-27 13:32:34 UTC
Created attachment 31962 [details]
generated assembler code (cc -O2 -S test.c)

On NetBSD/alpha a call to malloc requesting a two byte allocation may return a pointer that is only 2-byte algined. We believe this to be within the C std spec (as alignemnt is good enough for all complete objects fitting in the allocated space).

However, gcc seems to assume return values from malloc to have higher alignment.

This test program:

--8<--
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char **argv)
{
        char *p;
        size_t i;

        for (i = 0; i < 24; i++) {
                p = malloc(2);
                printf("got %p\n", p);
                p[0] = 'A'; p[1] = 0;
                printf("stored string: %s\n", p);
        }

        return 0;
}
-->8--

shows the problem:

[..]
got 0x3fffdc02238
stored string: A
got 0x3fffdc0223a
pid 600 (a.out): unaligned access: va=0x3fffdc0223a pc=0x120000bc4 ra=0x120000bbc sp=0x1ffffdb08 op=ldl
pid 600 (a.out): unaligned access: va=0x3fffdc0223a pc=0x120000be4 ra=0x120000bbc sp=0x1ffffdb08 op=stl
stored string: A
got 0x3fffdc0223c
stored string: A
got 0x3fffdc0223e
pid 600 (a.out): unaligned access: va=0x3fffdc0223e pc=0x120000bc4 ra=0x120000bbc sp=0x1ffffdb08 op=ldl
pid 600 (a.out): unaligned access: va=0x3fffdc0223e pc=0x120000be4 ra=0x120000bbc sp=0x1ffffdb08 op=stl
stored string: A
got 0x3fffdc02240
[..]


This might be more of a problem with target alpha and the byte access code, compiling the test program with -mbwx does help (but not all alpha CPUs support that).

gcc version used:

> cc -v
Using built-in specs.
COLLECT_GCC=cc
Target: alpha--netbsd
Configured with: /usr/src7/tools/gcc/../../external/gpl3/gcc/dist/configure --target=alpha--netbsd --enable-long-long --enable-threads --with-bugurl=http://www.NetBSD.org/Misc/send-pr.html --with-pkgversion='NetBSD nb1 20120916' --with-system-zlib --enable-__cxa_atexit --with-mpc-lib=/var/obj/mknative/alpha/usr/src7/external/lgpl3/mpc/lib/libmpc --with-mpfr-lib=/var/obj/mknative/alpha/usr/src7/external/lgpl3/mpfr/lib/libmpfr --with-gmp-lib=/var/obj/mknative/alpha/usr/src7/external/lgpl3/gmp/lib/libgmp --with-mpc-include=/usr/src7/external/lgpl3/mpc/dist/src --with-mpfr-include=/usr/src7/external/lgpl3/mpfr/dist/src --with-gmp-include=/usr/src7/external/lgpl3/gmp/lib/libgmp/arch/alpha --enable-tls --disable-multilib --disable-symvers --disable-libstdcxx-pch --build=x86_64-unknown-netbsd6.0. --host=alpha--netbsd --with-sysroot=/var/obj/mknative/alpha/usr/src7/destdir.alpha
Thread model: posix
gcc version 4.8.3 (NetBSD nb1 20131213)
Comment 1 joseph@codesourcery.com 2014-01-27 18:40:03 UTC
The response to C90 DR#075 said memory from malloc must be suitably 
aligned for all types, not just those fitting in space of the given size, 
and nothing relevant has changed in the malloc specification in C99/C11 so 
it's reasonable to assume this still applies (for standard types, that is, 
not types using C11 _Alignof).

http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_075.html
Comment 2 Martin Husemann 2014-01-28 10:28:40 UTC
Is the alignment expected from malloc() configurable in gcc and/or different from the standard stack alignment?

A small test program along the lines of

  if ((uintptr_t)malloc(1) & mask) printf("yes\n") else printf("no\n");

and checking what gcc -O2 optimizes away for different masks seems to show that on alpha & 7 is optimized, while & 15 is not. This sounds good for alpha.

However, I get the same results for amd64 - where I would have expected the required alignement to be 16 byte. Is this a bug in our amd64 target configuration, or am I misundertanding something?
Comment 3 Andrew Pinski 2014-01-29 00:45:02 UTC
(In reply to Martin Husemann from comment #2)
> Is the alignment expected from malloc() configurable in gcc and/or different
> from the standard stack alignment?

Yes MALLOC_ABI_ALIGNMENT:
@defmac MALLOC_ABI_ALIGNMENT
Alignment, in bits, a C conformant malloc implementation has to
provide.  If not defined, the default value is @code{BITS_PER_WORD}.
@end defmac




> 
> A small test program along the lines of
> 
>   if ((uintptr_t)malloc(1) & mask) printf("yes\n") else printf("no\n");
> 
> and checking what gcc -O2 optimizes away for different masks seems to show
> that on alpha & 7 is optimized, while & 15 is not. This sounds good for
> alpha.
> 
> However, I get the same results for amd64 - where I would have expected the
> required alignement to be 16 byte. Is this a bug in our amd64 target
> configuration, or am I misundertanding something?

misunderstanding the default and most likely the history of this macro.
Comment 4 Richard Biener 2014-01-29 13:51:05 UTC
The original issue is invalid (bug in netbsd).