Re: Ping Re: Make max_align_t respect _Float128 [version 3]

On 09/19/2016 09:58 AM, Joseph Myers wrote: Ping. This patch is pending review. OK. I never like adding more conditionals to stddef.h, but it's likely unavoidable in this case. jeff

Re: Ping Re: Make max_align_t respect _Float128 [version 3]

On 09/19/2016 08:58 AM, Joseph Myers wrote: Ping. This patch is pending review. Thanks, the patch looks good to me. It should be safe for the uses of max_align_t that I know of (e.g., Emacs).

Ping Re: Make max_align_t respect _Float128 [version 3]

Ping. This patch is pending review. -- Joseph S. Myers jos...@codesourcery.com

Re: Make max_align_t respect _Float128 [version 2]

On 09/08/16 11:35, Florian Weimer wrote: > On 09/07/2016 08:32 PM, Bernd Edlinger wrote: >> interesting. I just tried the test case from PR 77330 with _Decimal128. >> result: _Decimal128 did *not* trap with gcc4.8.4, but it does trap with >> gcc-7.0.0. > > Recent GCC versions rely on struct pointe

Re: Make max_align_t respect _Float128 [version 2]

On 09/08/2016 04:56 AM, Mark Wielaard wrote: I don't think there is anything valgrind can do to detect that compw really only depends on d[0] if the result is false. valgrind (with the default --partial-loads-ok=yes) could and should do the same thing with cmpw that it already does with cmpl. T

Re: Make max_align_t respect _Float128 [version 2]

On 09/08/2016 02:26 PM, Bernd Schmidt wrote: On 09/08/2016 01:21 AM, Paul Eggert wrote: Sure, attached. On Fedora 24 x86-64 (GCC 6.1.1 20160621, valgrind 3.11.0), when I compile with "gcc -O2 flexouch.c" and run with "valgrind ./a.out", valgrind complains "Invalid read of size 2". This is becau

Re: Make max_align_t respect _Float128 [version 2]

On 09/08/2016 01:21 AM, Paul Eggert wrote: Sure, attached. On Fedora 24 x86-64 (GCC 6.1.1 20160621, valgrind 3.11.0), when I compile with "gcc -O2 flexouch.c" and run with "valgrind ./a.out", valgrind complains "Invalid read of size 2". This is because GCC compiles "p->d[0] == 2 && p->d[1] == 3"

Re: Make max_align_t respect _Float128 [version 2]

On 09/08/2016 01:56 PM, Mark Wielaard wrote: On Wed, Sep 07, 2016 at 04:21:29PM -0700, Paul Eggert wrote: On 09/07/2016 04:52 AM, Mark Wielaard wrote: If valgrind believes the memory isn't in valid memory then it will complain about an invalid access. But if the memory is accessible but uninit

Re: Make max_align_t respect _Float128 [version 2]

Hi, I added Julian to the CC who will probably correct any mistakes I make. Or even might know a simple way to make valgrind detect this idiom. On Wed, Sep 07, 2016 at 04:21:29PM -0700, Paul Eggert wrote: > On 09/07/2016 04:52 AM, Mark Wielaard wrote: > > If valgrind believes the > > memory isn't

Re: Make max_align_t respect _Float128 [version 2]

On 09/07/2016 08:32 PM, Bernd Edlinger wrote: interesting. I just tried the test case from PR 77330 with _Decimal128. result: _Decimal128 did *not* trap with gcc4.8.4, but it does trap with gcc-7.0.0. Recent GCC versions rely on struct pointer alignment for struct member access, older version

Re: Make max_align_t respect _Float128 [version 2]

On 09/07/2016 07:45 PM, Joseph Myers wrote: On Wed, 7 Sep 2016, Florian Weimer wrote: The existence of such a cut-off constant appears useful, but it's not clear if it should be tied to the fundamental alignment (especially, as this discussion shows, the fundamental alignment will be somewhat i

Re: Make max_align_t respect _Float128 [version 2]

On 09/07/2016 04:52 AM, Mark Wielaard wrote: If valgrind believes the memory isn't in valid memory then it will complain about an invalid access. But if the memory is accessible but uninitialised then it will just track the undefinedness complain later if such a value is used. I think the forme

Re: Make max_align_t respect _Float128 [version 2]

On Wed, 7 Sep 2016, Bernd Edlinger wrote: > Apparently the different -msse default setting made the situation worse. > I think that will not run on a pentium4 any more. I think that's x86_64-* defaulting to an x86_64 processor (which implies SSE2 support) even with -m32 (unless a --with-arch-32=

Re: Make max_align_t respect _Float128 [version 2]

On 09/07/16 22:04, Joseph Myers wrote: > On Wed, 7 Sep 2016, Bernd Edlinger wrote: > >> interesting. I just tried the test case from PR 77330 with _Decimal128. >> result: _Decimal128 did *not* trap with gcc4.8.4, but it does trap with >> gcc-7.0.0. > > I checked with GCC 4.3; __alignof__ (_Decimal

Re: Make max_align_t respect _Float128 [version 2]

On Wed, 7 Sep 2016, Bernd Edlinger wrote: > interesting. I just tried the test case from PR 77330 with _Decimal128. > result: _Decimal128 did *not* trap with gcc4.8.4, but it does trap with > gcc-7.0.0. I checked with GCC 4.3; __alignof__ (_Decimal128) was 16 back then. Whether particular code

Re: Make max_align_t respect _Float128 [version 2]

On Wed, 7 Sep 2016, Joseph Myers wrote: > On Wed, 7 Sep 2016, Florian Weimer wrote: > > > The existence of such a cut-off constant appears useful, but it's not clear if > > it should be tied to the fundamental alignment (especially, as this discussion > > shows, the fundamental alignment wil

Re: Make max_align_t respect _Float128 [version 2]

On Wed, 7 Sep 2016, Florian Weimer wrote: > The existence of such a cut-off constant appears useful, but it's not clear if > it should be tied to the fundamental alignment (especially, as this discussion > shows, the fundamental alignment will be somewhat in flux). I don't think it's in flux. I

Re: Make max_align_t respect _Float128 [version 2]

On Wed, Sep 07, 2016 at 11:15:34AM +0200, Florian Weimer wrote: > On 09/06/2016 11:31 PM, Paul Eggert wrote: > >On 09/06/2016 01:40 PM, Joseph Myers wrote: > >>Sounds like a defect in C11 to me - none of the examples of flexible > >>array > >>members anticipate needing to add to the size to allow f

Re: Make max_align_t respect _Float128 [version 2]

On 09/06/2016 11:31 PM, Paul Eggert wrote: On 09/06/2016 01:40 PM, Joseph Myers wrote: Sounds like a defect in C11 to me - none of the examples of flexible array members anticipate needing to add to the size to allow for tail padding with unknown alignment requirements. Yes, I would prefer cal

Re: Make max_align_t respect _Float128 [version 2]

On 09/06/2016 10:40 PM, Joseph Myers wrote: On Tue, 6 Sep 2016, Paul Eggert wrote: One way to correct the code is to increase malloc's argument up to a multiple of alignof(max_align_t). (One cannot portably use alignof(struct s) due to Sounds like a defect in C11 to me - none of the examples

Re: Make max_align_t respect _Float128 [version 2]

On 09/06/2016 11:23 AM, Richard Biener wrote: The question then is, how can we make max_align_t more useful? If it is supposed to reflect a malloc property, it cannot be a compile-time constant because we don't know at compile time which malloc is going to be used (malloc has to remain interpos

Re: Make max_align_t respect _Float128 [version 2]

On Tue, 6 Sep 2016, Jason Merrill wrote: > The reason I care is that C++17 aligned new (wg21.link/p0035) > specifies that for types that require more alignment than the usual > operator new provides, the new-expression instead calls an operator > new with an explicit alignment parameter. MALLOC_A

Re: Make max_align_t respect _Float128 [version 2]

On Tue, Sep 6, 2016 at 5:03 PM, Joseph Myers wrote: > On Tue, 6 Sep 2016, Jason Merrill wrote: > >> On Tue, Sep 6, 2016 at 11:16 AM, Joseph Myers >> wrote: >> > GCC is supposed to support all mallocs that produce results aligned to at >> > least MALLOC_ABI_ALIGNMENT (which may be smaller than th

Re: Make max_align_t respect _Float128 [version 2]

On 09/06/2016 01:40 PM, Joseph Myers wrote: Sounds like a defect in C11 to me - none of the examples of flexible array members anticipate needing to add to the size to allow for tail padding with unknown alignment requirements. Yes, I would prefer calling it a defect, as most code I've seen de

Re: Make max_align_t respect _Float128 [version 2]

On Tue, 6 Sep 2016, Jason Merrill wrote: > On Tue, Sep 6, 2016 at 11:16 AM, Joseph Myers wrote: > > GCC is supposed to support all mallocs that produce results aligned to at > > least MALLOC_ABI_ALIGNMENT (which may be smaller than the alignment of > > max_align_t). > > I've just been running in

Re: Make max_align_t respect _Float128 [version 2]

On Tue, Sep 6, 2016 at 11:16 AM, Joseph Myers wrote: > GCC is supposed to support all mallocs that produce results aligned to at > least MALLOC_ABI_ALIGNMENT (which may be smaller than the alignment of > max_align_t). I've just been running into problems with MALLOC_ABI_ALIGNMENT being smaller th

Re: Make max_align_t respect _Float128 [version 2]

On Tue, 6 Sep 2016, Bernd Edlinger wrote: > I think that for _Float128 to become a fundamental data type, > it is *not* sufficient that gcc supports it alone, because glibc > needs to support also all the necessary math library functions. No, the definition of basic types for a freestanding imple

Re: Make max_align_t respect _Float128 [version 2]

On Tue, 6 Sep 2016, Paul Eggert wrote: > One way to correct the code is to increase malloc's argument up to a multiple > of alignof(max_align_t). (One cannot portably use alignof(struct s) due to Sounds like a defect in C11 to me - none of the examples of flexible array members anticipate needin

Re: Make max_align_t respect _Float128 [version 2]

Hi, I'd like to share some of my thoughts about the max_align_t, if you don't mind. I think that for _Float128 to become a fundamental data type, it is *not* sufficient that gcc supports it alone, because glibc needs to support also all the necessary math library functions. When that is done, gl

Re: Make max_align_t respect _Float128 [version 2]

On 09/06/2016 08:16 AM, Joseph Myers wrote: I don't think there's any such requirement in the case of flexible array members; if you use malloc to allocate a structure with a flexible array member, you can access as many trailing array elements as would fit within the allocated size, whether or n

Re: Make max_align_t respect _Float128 [version 2]

On Tue, 6 Sep 2016, Florian Weimer wrote: > So that's what ties the two things together. I still don't like what's > implied in PR1, that all object sizes have to be multiples of the > fundamental alignment. I don't think there's any such requirement in the case of flexible array members; i

Re: Make max_align_t respect _Float128 [version 2]

On 09/06/2016 01:25 PM, Joseph Myers wrote: On Tue, 6 Sep 2016, Florian Weimer wrote: Why aren't there any users? The standard isn't very clear what the value of _Alignof (max_align_t) actually means. Does the phrase “all contexts” include pointers returned malloc? Even if the requested size

Re: Make max_align_t respect _Float128 [version 2]

On 09/06/2016 01:59 PM, Bernd Schmidt wrote: On 09/06/2016 11:11 AM, Florian Weimer wrote: I think this change is only safe because nothing relies on it. max_align_t is a committee invention with no actual users. I tried to verify that and ran grep over all the packages in /usr/portage/distfi

Re: Make max_align_t respect _Float128 [version 2]

On 09/06/2016 11:11 AM, Florian Weimer wrote: I think this change is only safe because nothing relies on it. max_align_t is a committee invention with no actual users. I tried to verify that and ran grep over all the packages in /usr/portage/distfiles. That did get a number of matches, fairly

Re: Make max_align_t respect _Float128 [version 2]

On Tue, 6 Sep 2016, Florian Weimer wrote: > Why aren't there any users? The standard isn't very clear what the value of > _Alignof (max_align_t) actually means. Does the phrase “all contexts” include > pointers returned malloc? Even if the requested size is smaller than the > fundamental alignm

Re: Make max_align_t respect _Float128 [version 2]

On Tue, 6 Sep 2016, Richard Biener wrote: > > On 32-bit x86, max_align_t is currently 8-byte aligned, but > > _Decimal128 and _Float128 are 16-byte aligned, so the alignment of > > max_align_t needs to increase to meet the standard requirements for > > these types. > > As doubles on 32bit x86 are

Re: Make max_align_t respect _Float128 [version 2]

On Tue, Sep 6, 2016 at 11:11 AM, Florian Weimer wrote: > On 09/05/2016 07:06 PM, Joseph Myers wrote: > >> Such an increase is of course an ABI change, but a reasonably safe >> one, in that max_align_t doesn't tend to appear in library interfaces >> (rather, it's something to use when writing alloc

Re: Make max_align_t respect _Float128 [version 2]

On 09/05/2016 07:06 PM, Joseph Myers wrote: Such an increase is of course an ABI change, but a reasonably safe one, in that max_align_t doesn't tend to appear in library interfaces (rather, it's something to use when writing allocators and similar code; most matches found on codesearch.debian.ne

Re: Make max_align_t respect _Float128 [version 2]

On Mon, Sep 5, 2016 at 7:06 PM, Joseph Myers wrote: > [Patch version 2 adds an update to cxx_fundamental_alignment_p.] > > The _FloatN, _FloatNx, _DecimalN and _DecimalNx types are specified in > such a way that they are basic types, meaning that max_align_t must be > at least as aligned as those

Ping Re: Make max_align_t respect _Float128

Ping. This patch is pending review (with either __i386__ or __SIZEOF_FLOAT128__, although __i386__ is safest in that it minimizes the cases where there is any ABI change at all even in the size of the type). -- Joseph S. Myers jos...

Re: Make max_align_t respect _Float128

On Mon, 29 Aug 2016, Marek Polacek wrote: > On Fri, Aug 26, 2016 at 02:51:38PM -0700, Paul Eggert wrote: > > > Well, the patch could use __SIZEOF_FLOAT128__ just as well as __i386__ > > > (the effect would be an extra union member > > > > s/union/struct/. Though I've always wondered why it is a s

Re: Make max_align_t respect _Float128

On Fri, Aug 26, 2016 at 02:51:38PM -0700, Paul Eggert wrote: > > Well, the patch could use __SIZEOF_FLOAT128__ just as well as __i386__ > > (the effect would be an extra union member > > s/union/struct/. Though I've always wondered why it is a struct and not a > union. Maybe change it to union whi

Re: Make max_align_t respect _Float128

On Fri, 26 Aug 2016, Florian Weimer wrote: > The crucial question is whether GCC will start assuming that pointers returned > by malloc (or attribute-malloc functions) have such an alignment. That seems > impossible. GCC's assumptions about the alignment of pointers returned by malloc are more

Re: Make max_align_t respect _Float128

On 08/26/2016 02:45 PM, Florian Weimer wrote: In the end, max_align_t is ignored by allocators, and applications cannot rely on it as a result. Hmm, well, in that case I suppose I should change Emacs to ignore max_align_t as well. Thanks for the heads-up.

Re: Make max_align_t respect _Float128

On 08/26/2016 01:54 PM, Joseph Myers wrote: Such an increase is of course an ABI change, but a reasonably safe one, in that max_align_t doesn't tend to appear in library interfaces (rather, it's something to use when writing allocators and similar code; It should be fine, though I would like to

Re: Make max_align_t respect _Float128

On 08/26/2016 10:54 PM, Joseph Myers wrote: Such an increase is of course an ABI change, but a reasonably safe one, in that max_align_t doesn't tend to appear in library interfaces (rather, it's something to use when writing allocators and similar code; most matches found on codesearch.debian.net

Re: Make max_align_t respect _Float128

On Fri, 26 Aug 2016, Marc Glisse wrote: > On Fri, 26 Aug 2016, Joseph Myers wrote: > > > And since __float128 is architecture-specific, there > > isn't a preprocessor conditional that means "__float128 is available" > > That's what __SIZEOF_FLOAT128__ was supposed to be for. I didn't add it to >

Re: Make max_align_t respect _Float128

On Fri, 26 Aug 2016, Joseph Myers wrote: And since __float128 is architecture-specific, there isn't a preprocessor conditional that means "__float128 is available" That's what __SIZEOF_FLOAT128__ was supposed to be for. I didn't add it to itanium because zombies, and it looks like powerpc did