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
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
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
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"
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
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
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
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
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
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=
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
[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 types.
On 32-bit x86, max_align_t is currently 8-byte aligned
37 matches
Mail list logo
