https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77330
--- Comment #14 from joseph at codesourcery dot com ---
On Wed, 24 Aug 2016, bernd.edlinger at hotmail dot de wrote:
> glibc's malloc returns 128-bit aligned on x86-64-linux-gnu.
> but what does it return on windows?
glibc does not support Wind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77330
--- Comment #13 from joseph at codesourcery dot com ---
On Wed, 24 Aug 2016, bernd.edlinger at hotmail dot de wrote:
> It is only necessary if __float128 is declared a base type.
> But __m512 is no base type, right?
It's clear that __m512 shoul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77330
--- Comment #12 from Bernd Edlinger ---
glibc's malloc returns 128-bit aligned on x86-64-linux-gnu.
but what does it return on windows?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77330
--- Comment #11 from Bernd Edlinger ---
(In reply to jos...@codesourcery.com from comment #10)
> On Tue, 23 Aug 2016, bernd.edlinger at hotmail dot de wrote:
>
> > Yes, but isn't that an ABI decision?
>
> It's the sort of ABI decision that's fi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77330
--- Comment #10 from joseph at codesourcery dot com ---
On Tue, 23 Aug 2016, bernd.edlinger at hotmail dot de wrote:
> Yes, but isn't that an ABI decision?
It's the sort of ABI decision that's fixed after it's appeared in a
release (whereas ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77330
--- Comment #9 from Bernd Edlinger ---
(In reply to jos...@codesourcery.com from comment #8)
> On Tue, 23 Aug 2016, bernd.edlinger at hotmail dot de wrote:
>
> > gcc assumes that malloc, calloc, realloc, strdup, strndup
> > and anything with the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77330
--- Comment #8 from joseph at codesourcery dot com ---
On Tue, 23 Aug 2016, bernd.edlinger at hotmail dot de wrote:
> gcc assumes that malloc, calloc, realloc, strdup, strndup
> and anything with the __attribute__((__malloc__))
> returns a point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77330
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77330
--- Comment #6 from joseph at codesourcery dot com ---
On Tue, 23 Aug 2016, mikulas at artax dot karlin.mff.cuni.cz wrote:
> And if you add a new type __float256 with 32-byte alignment - does it mean
> that
> glibc suddenly starts being buggy,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77330
--- Comment #5 from mikulas at artax dot karlin.mff.cuni.cz ---
And if you add a new type __float256 with 32-byte alignment - does it mean that
glibc suddenly starts being buggy, because it couldn't anticipate what types
with what alignment will b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77330
--- Comment #4 from joseph at codesourcery dot com ---
When there isn't whole-implementation, including library, support for the
types as "basic types" (see the resolution to DR#445), you need to
consider them as some other kind of type, analog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77330
--- Comment #3 from mikulas at artax dot karlin.mff.cuni.cz ---
BTW. gcc thinks that with -m32, allocated memory is aligned to 4 bytes and with
-m64 and -mx32, allocated memory is aligned to 16 bytes. You can try to compile
this program into assem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77330
--- Comment #2 from mikulas at artax dot karlin.mff.cuni.cz ---
Glibc doesn't support types __float128 and decimal float. Only GCC does.
Glibc can't be responsible for decisions made by the GCC developers. Glibc has
been aliging allocated memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77330
--- Comment #1 from joseph at codesourcery dot com ---
I think this is a malloc bug: x86 malloc should produce 16-byte-aligned
results because the relevant TR / TS documents define _Decimal128 and
_Float128 in such a way that they are types for
14 matches
Mail list logo
