public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/24261]  New: gfortran ALLOCATE statement does not align objects on 16-byte boundary
@ 2005-10-07 16:54 mick at nag dot co dot uk
  2005-10-07 17:05 ` [Bug fortran/24261] " pinskia at gcc dot gnu dot org
                   ` (6 more replies)
  0 siblings, 7 replies; 8+ messages in thread
From: mick at nag dot co dot uk @ 2005-10-07 16:54 UTC (permalink / raw)
  To: gcc-bugs

When running gfortran on a 64-bit AMD Athlon64 Linux machine, the
Fortran ALLOCATE statement does not align pointers on 16-byte boundaries.
This means that allocated memory cannot be passed to assembly language
routines that rely on 16-byte alignment (e.g. assembly language using
SSE instructions like "movaps").

The demonstration below involves two files, the first one
a Fortran program name try.f which allocates an array x.
It calls a C function, shown in file sub.c, which returns the
address of x, and prints a message saying whether or not the
array is 16-byte aligned.

% gfortran -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/var/tmp/gfortran-20050916/irun
 --enable-languages=c,f95
Thread model: posix
gcc version 4.1.0 20050916 (experimental)

% cat try.f
      real, allocatable :: x(:)
      integer*8 address, p, sixteen
      external address
      sixteen = 16
      allocate (x(300000))
      p = address(x)
      write (*,99) 'Address of x = ', p
  99  format (1x,a,'0x',z16.16)
      if (mod(p,sixteen) .eq. 0) then
         write (*,*) 'x is aligned on a 16-byte boundary'
      else
         write (*,*) 'x is not aligned on a 16-byte boundary'
      end if
      end

% cat sub.c
unsigned long address_(void *x)
{
  return (unsigned long)x;
}

% gfortran try.f sub.c

% ./a.out
 Address of x = 0x00002AAAAB1CB028
 x is not aligned on a 16-byte boundary


-- 
           Summary: gfortran ALLOCATE statement does not align objects on
                    16-byte boundary
           Product: gcc
           Version: 4.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: mick at nag dot co dot uk


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


^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug fortran/24261] gfortran ALLOCATE statement does not align objects on 16-byte boundary
  2005-10-07 16:54 [Bug fortran/24261] New: gfortran ALLOCATE statement does not align objects on 16-byte boundary mick at nag dot co dot uk
@ 2005-10-07 17:05 ` pinskia at gcc dot gnu dot org
  2005-10-07 17:25 ` kargl at gcc dot gnu dot org
                   ` (5 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-10-07 17:05 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #1 from pinskia at gcc dot gnu dot org  2005-10-07 17:05 -------
Fixed by:
2005-10-01  Jakub Jelinek  <jakub@redhat.com>

        * runtime/memory.c (malloc_t): Remove.
        (GFC_MALLOC_MAGIC, HEADER_SIZE, DATA_POINTER, DATA_HEADER): Remove.
        (mem_root, runtime_cleanup, malloc_with_header): Remove.
        (internal_malloc_size): Use just get_mem if size != 0, return NULL
        otherwise.
        (internal_free): Just free if non-NULL.
        (internal_realloc_size): Remove debugging stuff.
        (allocate_size): Use malloc directly, remove debugging stuff.
        (deallocate): Use free directly, fix error message wording.


If it is not then it is a bug in glibc, complain to them.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.1.0


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


^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug fortran/24261] gfortran ALLOCATE statement does not align objects on 16-byte boundary
  2005-10-07 16:54 [Bug fortran/24261] New: gfortran ALLOCATE statement does not align objects on 16-byte boundary mick at nag dot co dot uk
  2005-10-07 17:05 ` [Bug fortran/24261] " pinskia at gcc dot gnu dot org
@ 2005-10-07 17:25 ` kargl at gcc dot gnu dot org
  2005-10-11  9:26 ` mick at nag dot co dot uk
                   ` (4 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: kargl at gcc dot gnu dot org @ 2005-10-07 17:25 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #2 from kargl at gcc dot gnu dot org  2005-10-07 17:25 -------
On amd64-*-freebsd with Jakub's patch, I get
troutmask:sgk[206] gfc41 -static -o z try.f sub.c 
troutmask:sgk[207] ./z
 Address of x = 0x0000000000554000
 x is aligned on a 16-byte boundary


-- 


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


^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug fortran/24261] gfortran ALLOCATE statement does not align objects on 16-byte boundary
  2005-10-07 16:54 [Bug fortran/24261] New: gfortran ALLOCATE statement does not align objects on 16-byte boundary mick at nag dot co dot uk
  2005-10-07 17:05 ` [Bug fortran/24261] " pinskia at gcc dot gnu dot org
  2005-10-07 17:25 ` kargl at gcc dot gnu dot org
@ 2005-10-11  9:26 ` mick at nag dot co dot uk
  2005-10-11 11:19 ` pinskia at gcc dot gnu dot org
                   ` (3 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: mick at nag dot co dot uk @ 2005-10-11  9:26 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #3 from mick at nag dot co dot uk  2005-10-11 09:26 -------
Thanks - the problem is now fixed in 64-bit compilations. However, if I compile
try.f and sub.c with the -m32 flag, I still get memory allocated on 8-byte
boundaries rather than 16-byte. As Andrew said, this is down to the way
glibc malloc behaves. I see that the glibc folks have discussed this
before, also in relation to the use of SSE instructions, but don't intend
to change the way malloc works:

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

After reading that discussion it's not entirely clear to me why there is
so much objection to 16-byte alignment, but whatever, it leaves me in the
position of having lots of SSE assembly code that I can only use from Fortran
by kludges like this:

   allocate(workspace(1000))
   if (is_on_16_byte_boundary(workspace)) then
     call assembly_routine(workspace)
   else if (is_on_8_byte_boundary(workspace)) then
     call assembly_routine(workspace(3))
   end if

Personally I think that the malloc in glibc should align to 16 bytes, but given
that it sounds like that's not likely to happen, another way might be for
gfortran to use memalign instead of malloc in its ALLOCATE routine.


-- 

mick at nag dot co dot uk changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|FIXED                       |


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


^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug fortran/24261] gfortran ALLOCATE statement does not align objects on 16-byte boundary
  2005-10-07 16:54 [Bug fortran/24261] New: gfortran ALLOCATE statement does not align objects on 16-byte boundary mick at nag dot co dot uk
                   ` (2 preceding siblings ...)
  2005-10-11  9:26 ` mick at nag dot co dot uk
@ 2005-10-11 11:19 ` pinskia at gcc dot gnu dot org
  2007-02-01 23:00 ` stevenj at alum dot mit dot edu
                   ` (2 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-10-11 11:19 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #4 from pinskia at gcc dot gnu dot org  2005-10-11 11:19 -------
This is really a glibc bug and needs to be fixed.  The C standard says that
malloc allocates that the right alignment so this is a glibc bug.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED


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


^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug fortran/24261] gfortran ALLOCATE statement does not align objects on 16-byte boundary
  2005-10-07 16:54 [Bug fortran/24261] New: gfortran ALLOCATE statement does not align objects on 16-byte boundary mick at nag dot co dot uk
                   ` (3 preceding siblings ...)
  2005-10-11 11:19 ` pinskia at gcc dot gnu dot org
@ 2007-02-01 23:00 ` stevenj at alum dot mit dot edu
  2007-02-01 23:04 ` pinskia at gcc dot gnu dot org
  2007-02-02  2:06 ` stevenj at alum dot mit dot edu
  6 siblings, 0 replies; 8+ messages in thread
From: stevenj at alum dot mit dot edu @ 2007-02-01 23:00 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #5 from stevenj at alum dot mit dot edu  2007-02-01 23:00 -------
(In reply to comment #4)
> This is really a glibc bug and needs to be fixed.  The C standard says that
> malloc allocates that the right alignment so this is a glibc bug.

The C standard does not cover SIMD instructions, so it is not a violation of
the C standard for malloc to return 8-byte aligned memory (which works fine
with all standard C code).

Moreover, in C there is the memalign function if you want to allocate aligned
memory, whereas in Fortran you seem to be out of luck.  This is especially sad
since numerical code is the main application of Fortran, and SIMD instructions
are important for maximum numerical performance on all recent x86
architectures.

Note that xlf provides a -qipa=malloc16 flag to make allocations 16-byte
aligned; I haven't been able to find out what ifort does, but I'm sure it
either does 16-byte alignment of allocate by default or provides a flag, since
that's needed to call their own MKL libraries.

Moral: gfortran should either provide a compiler flag to make allocate 16-byte
aligned, or do it by default, or provide a non-standard allocate function.  You
can't push this problem off on glibc.


-- 

stevenj at alum dot mit dot edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |stevenj at alum dot mit dot
                   |                            |edu


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


^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug fortran/24261] gfortran ALLOCATE statement does not align objects on 16-byte boundary
  2005-10-07 16:54 [Bug fortran/24261] New: gfortran ALLOCATE statement does not align objects on 16-byte boundary mick at nag dot co dot uk
                   ` (4 preceding siblings ...)
  2007-02-01 23:00 ` stevenj at alum dot mit dot edu
@ 2007-02-01 23:04 ` pinskia at gcc dot gnu dot org
  2007-02-02  2:06 ` stevenj at alum dot mit dot edu
  6 siblings, 0 replies; 8+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2007-02-01 23:04 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #6 from pinskia at gcc dot gnu dot org  2007-02-01 23:04 -------
(In reply to comment #5)
> (In reply to comment #4)
> > This is really a glibc bug and needs to be fixed.  The C standard says that
> > malloc allocates that the right alignment so this is a glibc bug.
> 
> The C standard does not cover SIMD instructions, so it is not a violation of
> the C standard for malloc to return 8-byte aligned memory (which works fine
> with all standard C code).

Well the C standard mentions there can be non standard integer types so that
exists for x86_64, __int128_t which has normally aligned 16bytes so again this
is a bug in glibc.


-- 


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


^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug fortran/24261] gfortran ALLOCATE statement does not align objects on 16-byte boundary
  2005-10-07 16:54 [Bug fortran/24261] New: gfortran ALLOCATE statement does not align objects on 16-byte boundary mick at nag dot co dot uk
                   ` (5 preceding siblings ...)
  2007-02-01 23:04 ` pinskia at gcc dot gnu dot org
@ 2007-02-02  2:06 ` stevenj at alum dot mit dot edu
  6 siblings, 0 replies; 8+ messages in thread
From: stevenj at alum dot mit dot edu @ 2007-02-02  2:06 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #7 from stevenj at alum dot mit dot edu  2007-02-02 02:06 -------
> Well the C standard mentions there can be non standard integer types so that
> exists for x86_64, __int128_t which has normally aligned 16bytes so again this
> is a bug in glibc.

First, 16-byte alignment for SIMD instructions is needed on 32-bit x86 machines
as well, and also on 32-bit PowerPC (with AltiVec), and on both of these
__int128_t is not supported by gcc.

Second, as far as I can tell __int128_t works perfectly fine on 8-byte aligned
data (I just tried it with gcc 4.1, CoreDuo), nor can I find any documentation
that says it *must* be 16-byte aligned.  (This doesn't seem too surprising: if
you look at the generated assembly, it just uses a sequence of 64-bit int
instructions, which only require 8-byte alignment.)  What is the evidence that
8-byte alignment is a bug in malloc, then?


-- 


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


^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2007-02-02  2:06 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-10-07 16:54 [Bug fortran/24261] New: gfortran ALLOCATE statement does not align objects on 16-byte boundary mick at nag dot co dot uk
2005-10-07 17:05 ` [Bug fortran/24261] " pinskia at gcc dot gnu dot org
2005-10-07 17:25 ` kargl at gcc dot gnu dot org
2005-10-11  9:26 ` mick at nag dot co dot uk
2005-10-11 11:19 ` pinskia at gcc dot gnu dot org
2007-02-01 23:00 ` stevenj at alum dot mit dot edu
2007-02-01 23:04 ` pinskia at gcc dot gnu dot org
2007-02-02  2:06 ` stevenj at alum dot mit dot edu

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).