public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/55916] New: Alignment issues with real(16) on i686
@ 2013-01-09 11:47 jakub at gcc dot gnu.org
2013-01-09 11:55 ` [Bug fortran/55916] " rguenth at gcc dot gnu.org
` (10 more replies)
0 siblings, 11 replies; 12+ messages in thread
From: jakub at gcc dot gnu.org @ 2013-01-09 11:47 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55916
Bug #: 55916
Summary: Alignment issues with real(16) on i686
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: jakub@gcc.gnu.org
The following testcase with -m32 -msse4 -g -O3 -fno-inline may segfault
(depending on whether malloc returns just 8-byte or 16-byte aligned pointer).
real(16), allocatable :: aaaa(:)
real(16) :: x(10)
integer :: i,n=10
allocate(aaaa(n))
do i = 1,n
aaaa(i) = 8.0
enddo
call foo (aaaa)
deallocate(aaaa)
contains
subroutine foo (aaaa)
real(16), allocatable :: aaaa(:)
aaaa(1) = aaaa(1) + 1
end subroutine
end
The problem is that __float128 aka real(16) has alignment 128 bits, but on
i686-linux malloc only guarantees 64 bit alignment (2 * sizeof (void *) byte
alignment). As __float128 is outside of the scope of C/C++, this is not a bug
on the C library side.
Guess for real(16) allocatables or any allocatables that require alignment
bigger than that of standard types Fortran should use posix_memalign (or
perhaps some libgfortran wrapper) that will be passed not just the size to
allocate, but also required alignment.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/55916] Alignment issues with real(16) on i686
2013-01-09 11:47 [Bug fortran/55916] New: Alignment issues with real(16) on i686 jakub at gcc dot gnu.org
@ 2013-01-09 11:55 ` rguenth at gcc dot gnu.org
2013-01-09 12:26 ` glisse at gcc dot gnu.org
` (9 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-01-09 11:55 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55916
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |wrong-code
Status|UNCONFIRMED |NEW
Last reconfirmed| |2013-01-09
Ever Confirmed|0 |1
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> 2013-01-09 11:55:09 UTC ---
Or inline the re-alignment code (and allocate one more element). That will
allow for the most optimization opportunities.
posix_memalign unfortunately has a weird enough interface that we can't
easily extract alignment for the pointer.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/55916] Alignment issues with real(16) on i686
2013-01-09 11:47 [Bug fortran/55916] New: Alignment issues with real(16) on i686 jakub at gcc dot gnu.org
2013-01-09 11:55 ` [Bug fortran/55916] " rguenth at gcc dot gnu.org
@ 2013-01-09 12:26 ` glisse at gcc dot gnu.org
2013-01-09 13:31 ` rguenth at gcc dot gnu.org
` (8 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: glisse at gcc dot gnu.org @ 2013-01-09 12:26 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55916
Marc Glisse <glisse at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |glisse at gcc dot gnu.org
--- Comment #2 from Marc Glisse <glisse at gcc dot gnu.org> 2013-01-09 12:25:43 UTC ---
(In reply to comment #1)
> posix_memalign unfortunately has a weird enough interface that we can't
> easily extract alignment for the pointer.
Is it just because it outputs through a pointer? Are aligned_alloc, memalign
and others easier then?
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/55916] Alignment issues with real(16) on i686
2013-01-09 11:47 [Bug fortran/55916] New: Alignment issues with real(16) on i686 jakub at gcc dot gnu.org
2013-01-09 11:55 ` [Bug fortran/55916] " rguenth at gcc dot gnu.org
2013-01-09 12:26 ` glisse at gcc dot gnu.org
@ 2013-01-09 13:31 ` rguenth at gcc dot gnu.org
2013-01-09 13:38 ` rguenth at gcc dot gnu.org
` (7 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-01-09 13:31 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55916
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> 2013-01-09 13:30:27 UTC ---
(In reply to comment #2)
> (In reply to comment #1)
> > posix_memalign unfortunately has a weird enough interface that we can't
> > easily extract alignment for the pointer.
>
> Is it just because it outputs through a pointer? Are aligned_alloc, memalign
> and others easier then?
Yes.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/55916] Alignment issues with real(16) on i686
2013-01-09 11:47 [Bug fortran/55916] New: Alignment issues with real(16) on i686 jakub at gcc dot gnu.org
` (2 preceding siblings ...)
2013-01-09 13:31 ` rguenth at gcc dot gnu.org
@ 2013-01-09 13:38 ` rguenth at gcc dot gnu.org
2013-01-09 16:10 ` pinskia at gcc dot gnu.org
` (6 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-01-09 13:38 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55916
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> 2013-01-09 13:38:12 UTC ---
(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > posix_memalign unfortunately has a weird enough interface that we can't
> > > easily extract alignment for the pointer.
> >
> > Is it just because it outputs through a pointer? Are aligned_alloc, memalign
> > and others easier then?
>
> Yes.
We can of course apply the same trick as we do for sincos - transform it to
({ void *tem; int ret;
tem = __builtin_gcc_posix_memalign (&res, alignment, size);
*memptr = tem;
ret; })
and then expand it to RTL as posix_memalign using another memory temporary ...
The issue with such return is that we cannot see all possible uses of the
return-by-reference value which is easy to do if it is the actual return
value.
Possibly an alloc_align attribute would be useful as well.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/55916] Alignment issues with real(16) on i686
2013-01-09 11:47 [Bug fortran/55916] New: Alignment issues with real(16) on i686 jakub at gcc dot gnu.org
` (3 preceding siblings ...)
2013-01-09 13:38 ` rguenth at gcc dot gnu.org
@ 2013-01-09 16:10 ` pinskia at gcc dot gnu.org
2013-01-09 20:57 ` joseph at codesourcery dot com
` (5 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: pinskia at gcc dot gnu.org @ 2013-01-09 16:10 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55916
--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> 2013-01-09 16:09:25 UTC ---
> As __float128 is outside of the scope of C/C++, this is not a bug on the C library side.
It might be outside the scope of C/C++ but doesn't C99 allow some
implementation defined types?
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/55916] Alignment issues with real(16) on i686
2013-01-09 11:47 [Bug fortran/55916] New: Alignment issues with real(16) on i686 jakub at gcc dot gnu.org
` (4 preceding siblings ...)
2013-01-09 16:10 ` pinskia at gcc dot gnu.org
@ 2013-01-09 20:57 ` joseph at codesourcery dot com
2014-02-07 8:03 ` ubizjak at gmail dot com
` (4 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: joseph at codesourcery dot com @ 2013-01-09 20:57 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55916
--- Comment #6 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2013-01-09 20:57:13 UTC ---
On Wed, 9 Jan 2013, pinskia at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55916
>
> --- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> 2013-01-09 16:09:25 UTC ---
> > As __float128 is outside of the scope of C/C++, this is not a bug on the C library side.
>
> It might be outside the scope of C/C++ but doesn't C99 allow some
> implementation defined types?
C99 has no concept of types with extended alignment requirements. I've
commented before on how __int128 needs to be thought of as a "sui generis
extended type" not "extended integer type" because while it has some of
the properties of an integer type, it's wider than intmax_t which forms
part of the C library ABI so isn't that easy to change to make 128 bits.
I suppose in fact such a sui generis extended type also isn't strictly an
object type (just acts like one) in order to follow the "suitably aligned
so that it may be assigned to a pointer to any type of object and then
used to access such an object or an array of such objects in the space
allocated" in C99.
For C11 the wording is different - "suitably aligned so that it may be
assigned to a pointer to any type of object with a fundamental alignment
requirement and then used to access such an object or an array of such
objects in the space allocated". Fundamental alignments are defined in
6.2.8#2 "A fundamental alignment is represented by an alignment less than
or equal to the greatest alignment supported by the implementation in all
contexts, which is equal to _Alignof (max_align_t).". Extended alignments
are defined in the following paragraph (but over-aligned types aren't
actually possible within the C11 syntax because the syntax for structure
and union elements omits to include the possibility of _Alignas
specifications).
The meaning of "supported by the implementation in all contexts" isn't
exactly clear. One might guess that it includes at least static objects,
stack objects and malloc.
Nothing actually seems to say what alignments are required to be supported
by the implementation in all contexts. 6.2.8#4 says "Valid alignments
include only those values returned by an _Alignof expression for
fundamental types, plus an additional implementation-defined set of
values, which may be empty.", but (a) "Valid" may not mean "supported in
all contexts" and (b) as noted recently on comp.std.c, the C standard has
no definition of "fundamental type", although it does define "basic type".
The DFP specification, at least, defines DFP types in a way that would
make them basic types (by text that would be inserted in the C standard to
describe DFP), which certainly suggests that malloc should return memory
suitably aligned for them. I imagine that when the IEEE 754-2008 bindings
reach the point of defining _Float128, the same will apply there.
I'm sure 32-bit powerpc glibc users will be glad if x86 people work out
how to increase malloc alignment to 16-byte without breaking existing
emacs binaries, since it's a longstanding problem
<http://sourceware.org/bugzilla/show_bug.cgi?id=6527> that malloc there
returns memory insufficiently aligned for long double.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/55916] Alignment issues with real(16) on i686
2013-01-09 11:47 [Bug fortran/55916] New: Alignment issues with real(16) on i686 jakub at gcc dot gnu.org
` (5 preceding siblings ...)
2013-01-09 20:57 ` joseph at codesourcery dot com
@ 2014-02-07 8:03 ` ubizjak at gmail dot com
2014-02-08 15:04 ` jouko.orava at iki dot fi
` (3 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: ubizjak at gmail dot com @ 2014-02-07 8:03 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55916
Uroš Bizjak <ubizjak at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |thatcadguy at gmail dot com
--- Comment #7 from Uroš Bizjak <ubizjak at gmail dot com> ---
*** Bug 60088 has been marked as a duplicate of this bug. ***
>From gcc-bugs-return-442937-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Feb 07 08:03:42 2014
Return-Path: <gcc-bugs-return-442937-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 23352 invoked by alias); 7 Feb 2014 08:03:42 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 23284 invoked by uid 48); 7 Feb 2014 08:03:39 -0000
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/60088] Segfault when using quad precision and -march=native on gfortran
Date: Fri, 07 Feb 2014 08:03:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.7.3
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ubizjak at gmail dot com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status resolution
Message-ID: <bug-60088-4-0ecka14zFW@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60088-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60088-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-02/txt/msg00694.txt.bz2
Content-length: 489
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60088
Uroš Bizjak <ubizjak at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |RESOLVED
Resolution|--- |DUPLICATE
--- Comment #22 from Uroš Bizjak <ubizjak at gmail dot com> ---
*** This bug has been marked as a duplicate of bug 55916 ***
>From gcc-bugs-return-442939-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Feb 07 08:34:05 2014
Return-Path: <gcc-bugs-return-442939-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 5395 invoked by alias); 7 Feb 2014 08:34:04 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 5349 invoked by uid 48); 7 Feb 2014 08:34:00 -0000
From: "izamyatin at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/59984] OpenMP and Cilk Plus SIMD pragma makes loop incorrect
Date: Fri, 07 Feb 2014 08:34:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: openmp
X-Bugzilla-Severity: normal
X-Bugzilla-Who: izamyatin at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-59984-4-lZX6hiyO7p@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59984-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59984-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-02/txt/msg00696.txt.bz2
Content-length: 1403
http://gcc.gnu.org/bugzilla/show_bug.cgi?idY984
--- Comment #4 from Igor Zamyatin <izamyatin at gmail dot com> ---
vect details show that v1.0_14 = v1 and v2.1_15 = v2 are treated as invariants:
test.c:24:14: note: ------>vectorizing statement: v1.0_14 = v1;
test.c:24:14: note: transform statement.
test.c:24:14: note: transform load. ncopies = 1
test.c:24:14: note: create vector_type-pointer variable to type: vector(4) int
vectorizing a pointer ref: v1
test.c:24:14: note: created vectp_v1.11_40
test.c:24:14: note: add new stmt: vect_v1.12_37 = MEM[(int *)vectp_v1.10_39];
test.c:24:14: note: hoisting out of the vectorized loop: v1.0_14 = v1;
test.c:24:14: note: created new init_stmt: vect_cst_.13_7 = {v1.0_8, v1.0_8,
v1.0_8, v1.0_8};
test.c:24:14: note: ------>vectorizing statement: v2.1_15 = v2;
test.c:24:14: note: transform statement.
test.c:24:14: note: transform load. ncopies = 1
test.c:24:14: note: create vector_type-pointer variable to type: vector(4) int
vectorizing a pointer ref: v2
test.c:24:14: note: created vectp_v2.15_1
test.c:24:14: note: add new stmt: vect_v2.16_60 = MEM[(int *)vectp_v2.14_58];
test.c:24:14: note: hoisting out of the vectorized loop: v2.1_15 = v2;
test.c:24:14: note: created new init_stmt: vect_cst_.17_62 = {v2.1_61, v2.1_61,
v2.1_61, v2.1_61};
Step for both loads determined as 0. Seems support for such case should be
explicitly added
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/55916] Alignment issues with real(16) on i686
2013-01-09 11:47 [Bug fortran/55916] New: Alignment issues with real(16) on i686 jakub at gcc dot gnu.org
` (6 preceding siblings ...)
2014-02-07 8:03 ` ubizjak at gmail dot com
@ 2014-02-08 15:04 ` jouko.orava at iki dot fi
2014-02-08 15:11 ` dominiq at lps dot ens.fr
` (2 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: jouko.orava at iki dot fi @ 2014-02-08 15:04 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55916
Jouko Orava <jouko.orava at iki dot fi> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jouko.orava at iki dot fi
--- Comment #8 from Jouko Orava <jouko.orava at iki dot fi> ---
These issues affect probably all versions of gfortran,
but I have verified this occurs with 4.6.4, 4.7.3, 4.8.1,
and trunk revision 207606.
It does seem unlikely that GNU libc malloc() will ever be
modified to return sufficiently aligned pointers for vector
types (or for long double on 32-bit ppc).
I have a patch under testing against trunk that modifies
libgfortran internal xmalloc() and xcalloc() calls, as well
as the intrinsic malloc() calls, to use GNU libc specific
memalign() call. I will attach it as soon as I verify it
works correctly.
If using memalign() is not acceptable, say so.
The reason for using memalign() instead of posix_memalign()
is that my (limited!) testing indicates that using memalign()
has the least overhead. posix_memalign() has relatively larger
overhead, possibly due to its call mechanism.
aligned_alloc() is not a real possibility for now, because
it was only added to glibc-2.16 (summer 2012). Computing clusters
often have older libc versions, and requiring glibc-2.16 and newer
would stop binaries compiled on newer gfortran versions from working.
(And binaries are often compiled on newer compilers.)
GCC generated code seems to assume malloc() returns a pointer aligned
to at least __BIGGEST_ALIGNMENT__. Therefore marking the allocation
functions with the malloc attribute (or perhaps with malloc and alloc_size)
should be sufficient for GNU Fortran.
(I shall also do some experiments with __builtin_assume_aligned() to see
if there is any impact to the generated code, but I don't see any
reason there should be. The compilation units are separate; AFAICT
GCC must determine the pointer alignment from the pointer type only.
That also matches current behaviour, and is the reason this bug exists.)
Obviously, memalign() is obsolete, but I see the performance
outweighing that here. After all, removing memalign()
in a future glibc would be seen as petty, considering how tenderly
emacs users have been treated; tolerating bugs for years, in order to
not break existing emacs state dumps.
My hardware selection is very limited, but if someone wishes to test the
possibilities on other hardware, I'd be happy to clean up my benchmarking code.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/55916] Alignment issues with real(16) on i686
2013-01-09 11:47 [Bug fortran/55916] New: Alignment issues with real(16) on i686 jakub at gcc dot gnu.org
` (7 preceding siblings ...)
2014-02-08 15:04 ` jouko.orava at iki dot fi
@ 2014-02-08 15:11 ` dominiq at lps dot ens.fr
2014-02-08 18:25 ` jouko.orava at iki dot fi
2014-02-08 23:51 ` jouko.orava at iki dot fi
10 siblings, 0 replies; 12+ messages in thread
From: dominiq at lps dot ens.fr @ 2014-02-08 15:11 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55916
--- Comment #9 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> My hardware selection is very limited, but if someone wishes to test the
> possibilities on other hardware, I'd be happy to clean up my benchmarking code.
I can do the testing on darwin (intel d10 and d13, ppc d9).
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/55916] Alignment issues with real(16) on i686
2013-01-09 11:47 [Bug fortran/55916] New: Alignment issues with real(16) on i686 jakub at gcc dot gnu.org
` (8 preceding siblings ...)
2014-02-08 15:11 ` dominiq at lps dot ens.fr
@ 2014-02-08 18:25 ` jouko.orava at iki dot fi
2014-02-08 23:51 ` jouko.orava at iki dot fi
10 siblings, 0 replies; 12+ messages in thread
From: jouko.orava at iki dot fi @ 2014-02-08 18:25 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55916
--- Comment #10 from Jouko Orava <jouko.orava at iki dot fi> ---
(In reply to Dominique d'Humieres from comment #9)
> I can do the testing on darwin (intel d10 and d13, ppc d9).
That would be very much appreciated.
I've put a tarball and some background info on my web page at
http://www.helsinki.fi/~joorava/memory/
Simply put, on my machine, 64-bit code has very little slowdown
if memalign() (or even posix_memalign()) is used instead of malloc().
Compiling 32-bit code, both memalign() and posix_memalign() incur
a 2x to 4x more CPU time, with posix_memalign() having a more or less
fixed overhead compared to memalign().
As I mention on the web page, I only wrote this to have a reason
to select a specific function. To me, the results indicate memalign()
is the second-best choice (best being "fixing" malloc()).
If you find any errors, or have results I may add to the above page
(whether or not they contradict mine), I'd be happy to include your
notes there.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/55916] Alignment issues with real(16) on i686
2013-01-09 11:47 [Bug fortran/55916] New: Alignment issues with real(16) on i686 jakub at gcc dot gnu.org
` (9 preceding siblings ...)
2014-02-08 18:25 ` jouko.orava at iki dot fi
@ 2014-02-08 23:51 ` jouko.orava at iki dot fi
10 siblings, 0 replies; 12+ messages in thread
From: jouko.orava at iki dot fi @ 2014-02-08 23:51 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55916
--- Comment #11 from Jouko Orava <jouko.orava at iki dot fi> ---
Just in case there are users who encounter this bug report,
here is the single-file workaround. Save the following as
nosegfault.c, and follow the instructions in the comments.
It can be compiled into a shared library used e.g. via LD_PRELOAD,
or into an object file and linked directly to a C or GNU Fortran
program, to fix the issue.
(It is trivial, so I consider it to be either uncopyrightable,
or if it is copyrightable, in the public domain.
It should still be smart enough to work on all architectures,
as long as GCC's __BIGGEST_ALIGNMENT__ is reliable.)
_______________________________________________________________________
#include <stdlib.h>
#include <string.h>
#include <malloc.h>
#include <errno.h>
/* Compile to a dynamic library:
* gcc $FLAGS -fPIC -shared nosegfault.c \
* -Wl,-soname,libnosefault.so -o libnosegfault.so
* Install the dynamic library at e.g. /usr/local/lib/,
* sudo install -m 0644 libnosegfault.so /usr/local/lib/
* and you can use it via e.g.
* env LD_PRELOAD=/usr/local/lib/libnosegfault.so COMMAND [ ARGS .. ]
*
* Compile this into an object file:
* gcc $FLAGS -c nosegfault.c
* compile your application, adding
* nosegfault.o
* to the build or final linking command; for example,
* gfortran $FLAGS .... nosegfault.o -o program
*
* $FLAGS may be empty, or contain your preferred optimization flags.
* If you are compiling 32-bit code, remember to include -m32 in it.
*
* If you compile static binaries, use a copy of the libc.a file
* (mentioned in the error if you try to compile with the object file
* statically), with malloc, calloc, __libc_malloc, and __libc_calloc
* replaced by the objects in this file, using e.g. 'ar'.
*/
#if __BIGGEST_ALIGNMENT__ <= 8
# error "You don't need this, or your compiler options are wrong."
#elif __BIGGEST_ALIGNMENT__ <= 16
# define ALIGNMENT 16
#elif __BIGGEST_ALIGNMENT__ <= 32
# define ALIGNMENT 32
#elif __BIGGEST_ALIGNMENT__ <= 64
# define ALIGNMENT 64
#else
# error "Your architecture has insane alignment requirements."
#endif
void *malloc(size_t size)
{
return memalign(ALIGNMENT, size);
}
void *__libc_malloc(size_t size)
{
return memalign(ALIGNMENT, size);
}
void *calloc(size_t count, size_t size)
{
if (!count || !size) {
return NULL;
} else {
const size_t n = size * count;
if ((size_t)(n / size) == count) {
void *p = memalign(ALIGNMENT, n);
if (!p)
return NULL;
memset(p, 0, n);
return p;
}
errno = ENOMEM;
return NULL;
}
}
void *__libc_calloc(size_t count, size_t size)
{
if (!count || !size) {
return NULL;
} else {
const size_t n = size * count;
if ((size_t)(n / size) == count) {
void *p = memalign(ALIGNMENT, n);
if (!p)
return NULL;
memset(p, 0, n);
return p;
}
errno = ENOMEM;
return NULL;
}
}
/* The End. */
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2014-02-08 23:51 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-01-09 11:47 [Bug fortran/55916] New: Alignment issues with real(16) on i686 jakub at gcc dot gnu.org
2013-01-09 11:55 ` [Bug fortran/55916] " rguenth at gcc dot gnu.org
2013-01-09 12:26 ` glisse at gcc dot gnu.org
2013-01-09 13:31 ` rguenth at gcc dot gnu.org
2013-01-09 13:38 ` rguenth at gcc dot gnu.org
2013-01-09 16:10 ` pinskia at gcc dot gnu.org
2013-01-09 20:57 ` joseph at codesourcery dot com
2014-02-07 8:03 ` ubizjak at gmail dot com
2014-02-08 15:04 ` jouko.orava at iki dot fi
2014-02-08 15:11 ` dominiq at lps dot ens.fr
2014-02-08 18:25 ` jouko.orava at iki dot fi
2014-02-08 23:51 ` jouko.orava at iki dot fi
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).