public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/15795] No way to teach operator new anything about alignment requirements
[not found] <bug-15795-4@http.gcc.gnu.org/bugzilla/>
@ 2021-10-29 1:01 ` pinskia at gcc dot gnu.org
2021-10-30 10:39 ` redi at gcc dot gnu.org
1 sibling, 0 replies; 33+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-10-29 1:01 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|WONTFIX |MOVED
--- Comment #44 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Just a quick note on this one, C++17 fixed this issue all together with C++20
requiring allocators also to handle the alignment. So changing this to moved
really. Also GCC 11 defaults to C++17.
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug c++/15795] No way to teach operator new anything about alignment requirements
[not found] <bug-15795-4@http.gcc.gnu.org/bugzilla/>
2021-10-29 1:01 ` [Bug c++/15795] No way to teach operator new anything about alignment requirements pinskia at gcc dot gnu.org
@ 2021-10-30 10:39 ` redi at gcc dot gnu.org
1 sibling, 0 replies; 33+ messages in thread
From: redi at gcc dot gnu.org @ 2021-10-30 10:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795
--- Comment #45 from Jonathan Wakely <redi at gcc dot gnu.org> ---
C++17 added support for dynamic allocation of over-aligned types, and requires
std::allocator to use it. User-defined allocators are not required to support
over-aligned types.
Before C++17 it was implementation-defined whether std:allocator supports them.
When using GCC they are supported when -faligned-new is used (which is the
default for C++17 and can be enabled for earlier modes if needed).
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug c++/15795] No way to teach operator new anything about alignment requirements
[not found] <bug-15795-6844@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2008-11-20 16:45 ` hjl dot tools at gmail dot com
@ 2008-12-09 17:56 ` rguenth at gcc dot gnu dot org
5 siblings, 0 replies; 33+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2008-12-09 17:56 UTC (permalink / raw)
To: gcc-bugs
------- Comment #42 from rguenth at gcc dot gnu dot org 2008-12-09 17:43 -------
*** Bug 38455 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tim at klingt dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug c++/15795] No way to teach operator new anything about alignment requirements
[not found] <bug-15795-6844@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2008-11-11 6:25 ` David dot Monniaux at imag dot fr
@ 2008-11-20 16:45 ` hjl dot tools at gmail dot com
2008-12-09 17:56 ` rguenth at gcc dot gnu dot org
5 siblings, 0 replies; 33+ messages in thread
From: hjl dot tools at gmail dot com @ 2008-11-20 16:45 UTC (permalink / raw)
To: gcc-bugs
------- Comment #41 from hjl dot tools at gmail dot com 2008-11-20 16:44 -------
You may want to take a look at PR 36159.
--
hjl dot tools at gmail dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hjl dot tools at gmail dot
| |com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug c++/15795] No way to teach operator new anything about alignment requirements
[not found] <bug-15795-6844@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2008-11-10 22:35 ` pinskia at gcc dot gnu dot org
@ 2008-11-11 6:25 ` David dot Monniaux at imag dot fr
2008-11-20 16:45 ` hjl dot tools at gmail dot com
2008-12-09 17:56 ` rguenth at gcc dot gnu dot org
5 siblings, 0 replies; 33+ messages in thread
From: David dot Monniaux at imag dot fr @ 2008-11-11 6:25 UTC (permalink / raw)
To: gcc-bugs
------- Comment #40 from David dot Monniaux at imag dot fr 2008-11-11 06:24 -------
Yes, at least the manual should be updated to reflect this non-obvious
behavior.
Possible fixes for the programmer:
1) Overload operators new. new[] for a class wrapping the vector datatypes. It
works as long as you allocate memory through explicit new, however it fails for
buffers allocated by STL's default allocator.
2) Overload the allocators for a wrapper class and select a specific allocator
for STL arrays etc. of that class. Haven't tried that yet.
3) Replace the global ::new and ::new[] by something calling memalign instead
of malloc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug c++/15795] No way to teach operator new anything about alignment requirements
[not found] <bug-15795-6844@http.gcc.gnu.org/bugzilla/>
2006-10-10 4:54 ` mrs at apple dot com
2006-11-12 15:33 ` timday at bottlenose dot demon dot co dot uk
@ 2008-11-10 22:35 ` pinskia at gcc dot gnu dot org
2008-11-11 6:25 ` David dot Monniaux at imag dot fr
` (2 subsequent siblings)
5 siblings, 0 replies; 33+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2008-11-10 22:35 UTC (permalink / raw)
To: gcc-bugs
------- Comment #39 from pinskia at gcc dot gnu dot org 2008-11-10 22:33 -------
*** Bug 38063 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |David dot Monniaux at imag
| |dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug c++/15795] No way to teach operator new anything about alignment requirements
[not found] <bug-15795-6844@http.gcc.gnu.org/bugzilla/>
2006-10-10 4:54 ` mrs at apple dot com
@ 2006-11-12 15:33 ` timday at bottlenose dot demon dot co dot uk
2008-11-10 22:35 ` pinskia at gcc dot gnu dot org
` (3 subsequent siblings)
5 siblings, 0 replies; 33+ messages in thread
From: timday at bottlenose dot demon dot co dot uk @ 2006-11-12 15:33 UTC (permalink / raw)
To: gcc-bugs
------- Comment #38 from timday at bottlenose dot demon dot co dot uk 2006-11-12 15:33 -------
Gah: just spent several hours trying to figure out why my malloced __v4sf
weren't 16 byte aligned before I stumbled on this thread. Would be nice if the
info gcc "Using vector instructions through built-in functions" section
contained a big warning about the issue.
--
timday at bottlenose dot demon dot co dot uk changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |timday at bottlenose dot
| |demon dot co dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug c++/15795] No way to teach operator new anything about alignment requirements
[not found] <bug-15795-6844@http.gcc.gnu.org/bugzilla/>
@ 2006-10-10 4:54 ` mrs at apple dot com
2006-11-12 15:33 ` timday at bottlenose dot demon dot co dot uk
` (4 subsequent siblings)
5 siblings, 0 replies; 33+ messages in thread
From: mrs at apple dot com @ 2006-10-10 4:54 UTC (permalink / raw)
To: gcc-bugs
------- Comment #37 from mrs at apple dot com 2006-10-10 04:54 -------
Additionally, you can petition ISO/C++ to provide a more elegant solution for
you.
VxWorks also does 16-byte alignment on ppc (for altivec) as I recall.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug c++/15795] No way to teach operator new anything about alignment requirements
2004-06-03 14:36 [Bug c++/15795] New: Strange bug / incorrect code generation with SSE ma1flfs at bath dot ac dot uk
` (23 preceding siblings ...)
2004-07-15 4:33 ` pinskia at gcc dot gnu dot org
@ 2005-01-13 23:21 ` pinskia at gcc dot gnu dot org
24 siblings, 0 replies; 33+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-01-13 23:21 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-13 23:20 -------
*** Bug 19432 has been marked as a duplicate of this bug. ***
--
What |Removed |Added
----------------------------------------------------------------------------
CC| |Pferdebert at west dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug c++/15795] No way to teach operator new anything about alignment requirements
2004-06-03 14:36 [Bug c++/15795] New: Strange bug / incorrect code generation with SSE ma1flfs at bath dot ac dot uk
` (22 preceding siblings ...)
2004-06-08 20:45 ` bangerth at dealii dot org
@ 2004-07-15 4:33 ` pinskia at gcc dot gnu dot org
2005-01-13 23:21 ` pinskia at gcc dot gnu dot org
24 siblings, 0 replies; 33+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-07-15 4:33 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pinskia at gcc dot gnu dot org 2004-07-15 04:33 -------
I should note that malloc on Mac OS X always returns 16 byte aligned (for altivec, even though some
CPUs it runs on does not have altivec).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug c++/15795] No way to teach operator new anything about alignment requirements
2004-06-03 14:36 [Bug c++/15795] New: Strange bug / incorrect code generation with SSE ma1flfs at bath dot ac dot uk
` (21 preceding siblings ...)
2004-06-08 20:34 ` jakub at gcc dot gnu dot org
@ 2004-06-08 20:45 ` bangerth at dealii dot org
2004-07-15 4:33 ` pinskia at gcc dot gnu dot org
2005-01-13 23:21 ` pinskia at gcc dot gnu dot org
24 siblings, 0 replies; 33+ messages in thread
From: bangerth at dealii dot org @ 2004-06-08 20:45 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From bangerth at dealii dot org 2004-06-08 20:45 -------
The SFINAE ('substitution failure is not an error') thing would have been
something along these lines:
---------------------
#include <new>
template <bool C, typename T> struct SFINAE;
template <typename T> struct SFINAE<true,T>
{
typedef T type;
};
template <typename T> struct Alignment
{
static const size_t alignment = __alignof (T);
};
// allocate types with alignment less than or equal to 8 bytes
template <typename T>
typename SFINAE<(Alignment<T>::alignment<=8), void *>::type
operator new (size_t sz, Alignment<T>)
{
return malloc (sz);
}
// allocate types with alignment or more than 8 bytes
template <typename T>
typename SFINAE<(Alignment<T>::alignment>8), void *>::type
operator new (size_t sz, Alignment<T>)
{
return posix_memalign (sz);
}
------------------------
Since the SFINAE structure is only declared for a true first
argument, substition of the return type of the two operators
only succeeds if the condition is true. Thus,
new(Alignment<double>) double;
calls the first version, while
new(Alignment<__m128>) __m128;
would call the second version. However, this switch could of course
also be placed in the code of a (single) function, and be statically
optimized away by the compiler as it knows the alignment at compile
time.
The fact that above code snippet doesn't compile (even if all the
functions we call were declared) is a separate matter for which I
have just filed a separate PR.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug c++/15795] No way to teach operator new anything about alignment requirements
2004-06-03 14:36 [Bug c++/15795] New: Strange bug / incorrect code generation with SSE ma1flfs at bath dot ac dot uk
` (20 preceding siblings ...)
2004-06-08 20:26 ` ma1flfs at bath dot ac dot uk
@ 2004-06-08 20:34 ` jakub at gcc dot gnu dot org
2004-06-08 20:45 ` bangerth at dealii dot org
` (2 subsequent siblings)
24 siblings, 0 replies; 33+ messages in thread
From: jakub at gcc dot gnu dot org @ 2004-06-08 20:34 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From jakub at gcc dot gnu dot org 2004-06-08 20:33 -------
Yeah, I was about to ask what other OSes do.
From
http://216.239.59.104/search?q=cache:itStYuxiBbQJ:www.ddj.com/dotnetbook/chapters/chapter15.pdf+malloc+alignment+SSE&hl=en&ie=UTF-8 and a bunch of other docs
google found me it seems MSFT is returning 8 byte aligned objects from malloc
like glibc and there are special interfaces for bigger alignment -
_aligned_malloc, _aligned_realloc, and _aligned_free (like posix_memalign in
POSIX). On Solaris for 32-bit programs things are also 8 byte aligned only,
eventhough there is an instruction which requires 64 byte alignment.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug c++/15795] No way to teach operator new anything about alignment requirements
2004-06-03 14:36 [Bug c++/15795] New: Strange bug / incorrect code generation with SSE ma1flfs at bath dot ac dot uk
` (19 preceding siblings ...)
2004-06-08 20:06 ` jason at redhat dot com
@ 2004-06-08 20:26 ` ma1flfs at bath dot ac dot uk
2004-06-08 20:34 ` jakub at gcc dot gnu dot org
` (3 subsequent siblings)
24 siblings, 0 replies; 33+ messages in thread
From: ma1flfs at bath dot ac dot uk @ 2004-06-08 20:26 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From ma1flfs at bath dot ac dot uk 2004-06-08 20:26 -------
Subject: Re: No way to teach operator new anything about alignment requirements
On Tuesday 08 June 2004 20:06, jason at redhat dot com wrote:
> > That's my point. Doing this would suck very much... And is sometimes not
> > possible. Think template classes, STL or Qt are good examples.
>
> Feel free to propose an alternative solution.
Ok, sorry for that, I am just incredible annoyed by this "feature"...
I think I will patch my glibc sometime late, and see if it works, and how
severe the penalties really are.
Wolfgang Bangerth wrote:
> In other words, the ball is back in our field. Anyone got ideas as to what
> to do? How do other compilers do this?
I got a friend to compile the program from comment #11 on windoze with visual
studio .net. It segfaults as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug c++/15795] No way to teach operator new anything about alignment requirements
2004-06-03 14:36 [Bug c++/15795] New: Strange bug / incorrect code generation with SSE ma1flfs at bath dot ac dot uk
` (18 preceding siblings ...)
2004-06-08 20:04 ` jason at redhat dot com
@ 2004-06-08 20:06 ` jason at redhat dot com
2004-06-08 20:26 ` ma1flfs at bath dot ac dot uk
` (4 subsequent siblings)
24 siblings, 0 replies; 33+ messages in thread
From: jason at redhat dot com @ 2004-06-08 20:06 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From jason at redhat dot com 2004-06-08 20:06 -------
Subject: Re: No way to teach operator new anything about
alignment requirements
On 8 Jun 2004 19:27:26 -0000, "ma1flfs at bath dot ac dot uk" <gcc-bugzilla@gcc.gnu.org> wrote:
> On Tuesday 08 June 2004 19:04, jason at redhat dot com wrote:
>> Because you also need to override operator new for Foo, and any other type
>> which requires alignment greater than that provided by malloc.
>
> That's my point. Doing this would suck very much... And is sometimes not
> possible. Think template classes, STL or Qt are good examples.
Feel free to propose an alternative solution.
Jason
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug c++/15795] No way to teach operator new anything about alignment requirements
2004-06-03 14:36 [Bug c++/15795] New: Strange bug / incorrect code generation with SSE ma1flfs at bath dot ac dot uk
` (17 preceding siblings ...)
2004-06-08 19:27 ` ma1flfs at bath dot ac dot uk
@ 2004-06-08 20:04 ` jason at redhat dot com
2004-06-08 20:06 ` jason at redhat dot com
` (5 subsequent siblings)
24 siblings, 0 replies; 33+ messages in thread
From: jason at redhat dot com @ 2004-06-08 20:04 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From jason at redhat dot com 2004-06-08 20:04 -------
Subject: Re: No way to teach operator new anything about
alignment requirements
On 8 Jun 2004 19:25:27 -0000, "bangerth at dealii dot org" <gcc-bugzilla@gcc.gnu.org> wrote:
> I we are to provide a workaround, I think that the signature you
> propose, i.e.
> operator new (size_t size, enum align_tag, size_t align);
> may not be a good idea, the second and third argument being an integer. This
> is just way too common and asking for trouble.
I don't think it would actually be a problem, since enums are distinct
types. But I understand your concern, since they do promote to integers,
and I'm not opposed to using a struct instead.
> Having something like
> template <int> struct Alignment {};
> template <int N> operator new (size_t, Alignment<N>);
Or
template <typename T> struct Alignment
{
static const size_t alignment = __alignof (T);
};
template <typename T> inline void *
operator new (size_t size, Alignment<T> align)
{
return align_new (size, align.alignment);
}
...
new (Alignment<Vector4>) Vector4[200];
Yes, that seems like a cleaner syntax for explicit placement new.
> may also be a neat possibility if we use SFINAE to provide
> template <int N>
> typename SFINAE<(N<=STD_ALIGNMENT),void*> operator new (size_t,Alignment<T>)
> and the opposite case as two overloads, and let the compiler pick which
> one it wants to call. This way we can switch at compile time which allocation
> function shall be called. But I think I'm carried away... ;-)
I'm not familiar with SFINAE.
Jason
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug c++/15795] No way to teach operator new anything about alignment requirements
2004-06-03 14:36 [Bug c++/15795] New: Strange bug / incorrect code generation with SSE ma1flfs at bath dot ac dot uk
` (16 preceding siblings ...)
2004-06-08 19:25 ` bangerth at dealii dot org
@ 2004-06-08 19:27 ` ma1flfs at bath dot ac dot uk
2004-06-08 20:04 ` jason at redhat dot com
` (6 subsequent siblings)
24 siblings, 0 replies; 33+ messages in thread
From: ma1flfs at bath dot ac dot uk @ 2004-06-08 19:27 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From ma1flfs at bath dot ac dot uk 2004-06-08 19:27 -------
Subject: Re: No way to teach operator new anything about alignment requirements
On Tuesday 08 June 2004 19:04, jason at redhat dot com wrote:
> Because you also need to override operator new for Foo, and any other type
> which requires alignment greater than that provided by malloc.
That's my point. Doing this would suck very much... And is sometimes not
possible. Think template classes, STL or Qt are good examples.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug c++/15795] No way to teach operator new anything about alignment requirements
2004-06-03 14:36 [Bug c++/15795] New: Strange bug / incorrect code generation with SSE ma1flfs at bath dot ac dot uk
` (15 preceding siblings ...)
2004-06-08 19:04 ` jason at redhat dot com
@ 2004-06-08 19:25 ` bangerth at dealii dot org
2004-06-08 19:27 ` ma1flfs at bath dot ac dot uk
` (7 subsequent siblings)
24 siblings, 0 replies; 33+ messages in thread
From: bangerth at dealii dot org @ 2004-06-08 19:25 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From bangerth at dealii dot org 2004-06-08 19:25 -------
I we are to provide a workaround, I think that the signature you
propose, i.e.
operator new (size_t size, enum align_tag, size_t align);
may not be a good idea, the second and third argument being an integer. This
is just way too common and asking for trouble. Why not
struct AlignTag {
AlignTag (int alignment);
//...
};
operator new (size_t, AlignTag)
and convert
new Vector4[200];
into
new (__gnu_cxx::AlignTag(__alignof (Vector4)) Vector4[200];
Having something like
template <int> struct Alignment {};
template <int N> operator new (size_t, Alignment<N>);
may also be a neat possibility if we use SFINAE to provide
template <int N>
typename SFINAE<(N<=STD_ALIGNMENT),void*> operator new (size_t,Alignment<T>)
and the opposite case as two overloads, and let the compiler pick which
one it wants to call. This way we can switch at compile time which allocation
function shall be called. But I think I'm carried away... ;-)
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug c++/15795] No way to teach operator new anything about alignment requirements
2004-06-03 14:36 [Bug c++/15795] New: Strange bug / incorrect code generation with SSE ma1flfs at bath dot ac dot uk
` (14 preceding siblings ...)
2004-06-08 18:45 ` ma1flfs at bath dot ac dot uk
@ 2004-06-08 19:04 ` jason at redhat dot com
2004-06-08 19:25 ` bangerth at dealii dot org
` (8 subsequent siblings)
24 siblings, 0 replies; 33+ messages in thread
From: jason at redhat dot com @ 2004-06-08 19:04 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From jason at redhat dot com 2004-06-08 19:04 -------
Subject: Re: No way to teach operator new anything about
alignment requirements
On 8 Jun 2004 18:45:04 -0000, "ma1flfs at bath dot ac dot uk" <gcc-bugzilla@gcc.gnu.org> wrote:
> Well, the workaround is a good idea in general, however, this program still
> segfaults...
Because you also need to override operator new for Foo, and any other type
which requires alignment greater than that provided by malloc.
Jason
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug c++/15795] No way to teach operator new anything about alignment requirements
2004-06-03 14:36 [Bug c++/15795] New: Strange bug / incorrect code generation with SSE ma1flfs at bath dot ac dot uk
` (13 preceding siblings ...)
2004-06-08 18:39 ` jason at redhat dot com
@ 2004-06-08 18:45 ` ma1flfs at bath dot ac dot uk
2004-06-08 19:04 ` jason at redhat dot com
` (9 subsequent siblings)
24 siblings, 0 replies; 33+ messages in thread
From: ma1flfs at bath dot ac dot uk @ 2004-06-08 18:45 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From ma1flfs at bath dot ac dot uk 2004-06-08 18:45 -------
Well, the workaround is a good idea in general, however, this program still
segfaults...
#define _XOPEN_SOURCE 600
#include <xmmintrin.h>
#include <stdio.h>
#include <stdlib.h>
class Vector4
{
public:
__m128 vec;
Vector4()
{
vec = _mm_setzero_ps();
}
void *operator new (unsigned int s)
{
void *p;
posix_memalign(&p, 16, s);
return p;
}
void *operator new[] (unsigned int s)
{
return operator new (s);
}
};
class Foo
{
public:
Vector4 b;
Foo() {}
};
int main(int argc, char **argv)
{
Foo *f = new Foo[200*200];
delete f;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug c++/15795] No way to teach operator new anything about alignment requirements
2004-06-03 14:36 [Bug c++/15795] New: Strange bug / incorrect code generation with SSE ma1flfs at bath dot ac dot uk
` (12 preceding siblings ...)
2004-06-08 18:05 ` jason at redhat dot com
@ 2004-06-08 18:39 ` jason at redhat dot com
2004-06-08 18:45 ` ma1flfs at bath dot ac dot uk
` (10 subsequent siblings)
24 siblings, 0 replies; 33+ messages in thread
From: jason at redhat dot com @ 2004-06-08 18:39 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From jason at redhat dot com 2004-06-08 18:39 -------
Subject: Re: No way to teach operator new anything about
alignment requirements
It would be possible for the compiler to implement this workaround
transparently, as an extension; i.e. if the new'd type has alignment
greater than MALLOC_ALIGN, use something like
operator new (size_t size, enum align_tag, size_t align);
i.e. translate
new Vector4[200];
into
new (__gnu_cxx::aligned, __alignof (Vector4)) Vector4[200];
But this would interact badly with overriding the default operator new.
I think that if glibc is unwilling to change the default alignment for
malloc, it doesn't make any sense for libstdc++ to change it in operator
new. The above workaround stands a good chance of breaking things if
implemented transparently.
So I think that the way to fix this problem is for users to implement the
workaround, possibly relying on the above operator new signature, to be
provided by libstdc++. Vector4::operator new would then be simplified to
void *operator new (size_t size)
{
return operator new (size, __gnu_cxx::aligned, __alignof (Vector4));
}
Thoughts?
Jason
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug c++/15795] No way to teach operator new anything about alignment requirements
2004-06-03 14:36 [Bug c++/15795] New: Strange bug / incorrect code generation with SSE ma1flfs at bath dot ac dot uk
` (11 preceding siblings ...)
2004-06-08 18:04 ` jason at gcc dot gnu dot org
@ 2004-06-08 18:05 ` jason at redhat dot com
2004-06-08 18:39 ` jason at redhat dot com
` (11 subsequent siblings)
24 siblings, 0 replies; 33+ messages in thread
From: jason at redhat dot com @ 2004-06-08 18:05 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From jason at redhat dot com 2004-06-08 18:05 -------
Subject: Re: No way to teach operator new anything about
alignment requirements
And again, without the extra whitespace (sorry):
#include <xmmintrin.h>
#include <stdio.h>
#include <stdlib.h>
#include <new>
class Vector4
{
public:
Vector4() { vec = _mm_setzero_ps(); }
void *operator new (size_t);
void *operator new[] (size_t size) { return operator new (size); }
__m128 vec;
};
void *Vector4::operator new (size_t size)
{
void *p;
int r = posix_memalign (&p, __alignof (Vector4), size);
if (r)
throw std::bad_alloc ();
return p;
}
int main(int argc, char **argv)
{
Vector4 *foo = new Vector4[200*200];
delete foo;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug c++/15795] No way to teach operator new anything about alignment requirements
2004-06-03 14:36 [Bug c++/15795] New: Strange bug / incorrect code generation with SSE ma1flfs at bath dot ac dot uk
` (10 preceding siblings ...)
2004-06-08 17:43 ` bangerth at dealii dot org
@ 2004-06-08 18:04 ` jason at gcc dot gnu dot org
2004-06-08 18:05 ` jason at redhat dot com
` (12 subsequent siblings)
24 siblings, 0 replies; 33+ messages in thread
From: jason at gcc dot gnu dot org @ 2004-06-08 18:04 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From jason at gcc dot gnu dot org 2004-06-08 18:04 -------
Here is a more elegant workaround:
#include <xmmintrin.h>
#include <stdio.h>
#include <stdlib.h>
#include <new>
class Vector4
{
public:
Vector4() { vec = _mm_setzero_ps(); }
void *operator new (size_t);
void *operator new[] (size_t size) { return operator new (size); }
__m128 vec;
};
void *Vector4::operator new (size_t size)
{
void *p;
int r = posix_memalign (&p, __alignof (Vector4), size);
if (r)
throw std::bad_alloc ();
return p;
}
int main(int argc, char **argv)
{
Vector4 *foo = new Vector4[200*200];
delete foo;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug c++/15795] No way to teach operator new anything about alignment requirements
2004-06-03 14:36 [Bug c++/15795] New: Strange bug / incorrect code generation with SSE ma1flfs at bath dot ac dot uk
` (9 preceding siblings ...)
2004-06-08 16:43 ` nathan at gcc dot gnu dot org
@ 2004-06-08 17:43 ` bangerth at dealii dot org
2004-06-08 18:04 ` jason at gcc dot gnu dot org
` (13 subsequent siblings)
24 siblings, 0 replies; 33+ messages in thread
From: bangerth at dealii dot org @ 2004-06-08 17:43 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From bangerth at dealii dot org 2004-06-08 17:43 -------
I think their argument is that the compiler knows about the alignment
of a type and should make use of this. Now, operator new is
in libstdc++ and presumably calls malloc directly, so that's a little
more complicated (operator new only gets passed a size, no alignment,
so we can't play games with __alignof__), but there may still be ways.
My feeling is that glibc should fix this, not the compiler. For the moment
we seem to be at an impasse, though :-(
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug c++/15795] No way to teach operator new anything about alignment requirements
2004-06-03 14:36 [Bug c++/15795] New: Strange bug / incorrect code generation with SSE ma1flfs at bath dot ac dot uk
` (8 preceding siblings ...)
2004-06-08 15:56 ` bangerth at dealii dot org
@ 2004-06-08 16:43 ` nathan at gcc dot gnu dot org
2004-06-08 17:43 ` bangerth at dealii dot org
` (14 subsequent siblings)
24 siblings, 0 replies; 33+ messages in thread
From: nathan at gcc dot gnu dot org @ 2004-06-08 16:43 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From nathan at gcc dot gnu dot org 2004-06-08 16:43 -------
if the glibc folks are unwilling to support a feature of the cpu, so be it. The
compiler can only work around that by pessimizing all allocations.
I understand glibc's reluctance to support arbitrary alignments, but alignments
imposed by the CPU are different. Those are system requirements, and glibc is
a system library, which should support them. BTW, there are many things in glibc
that are outside the C standard.
--
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |WONTFIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug c++/15795] No way to teach operator new anything about alignment requirements
2004-06-03 14:36 [Bug c++/15795] New: Strange bug / incorrect code generation with SSE ma1flfs at bath dot ac dot uk
` (7 preceding siblings ...)
2004-06-05 14:28 ` ma1flfs at bath dot ac dot uk
@ 2004-06-08 15:56 ` bangerth at dealii dot org
2004-06-08 16:43 ` nathan at gcc dot gnu dot org
` (15 subsequent siblings)
24 siblings, 0 replies; 33+ messages in thread
From: bangerth at dealii dot org @ 2004-06-08 15:56 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From bangerth at dealii dot org 2004-06-08 15:55 -------
The glibc people have decided that they will not change malloc to provide the
alignment requirements one would need for the case in this PR (see
http://sources.redhat.com/bugzilla/show_bug.cgi?id=206):
---------------------------
MALLOC_ALIGNMENT in glibc is really not going to change, it is a quality of
implementation, sure, by making it bigger the quality implementation would drop
a lot for most of the programs out there.
SSE types are certainly out of the scope of the C standard. GCC allows to create
objects with arbitrary alignment, not just __m128, but you can use say:
__attribute__((aligned (256))). With the same argumentation, you could request
that all malloc memory is 256 bytes aligned (or 4K or whatever you choose).
If you want to make C++ new working on these types, the compiler will simply
need to do its part and call some (non-standard) new operator with additional
alignment argument, which would in turn call posix_memalign, perhaps guarded with
some compiler option which will otherwise result in a compile time error if new
is used on types with too big alignment requirement.
--------------------------------
In other words, the ball is back in our field. Anyone got ideas as to what to do?
How do other compilers do this? (I just verified that icc 8.0 also segfaults on
the small testcase in comment #11, but maybe some compiler is more clever
there...)
W.
--
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at redhat dot com
Status|RESOLVED |UNCONFIRMED
Resolution|WONTFIX |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug c++/15795] No way to teach operator new anything about alignment requirements
2004-06-03 14:36 [Bug c++/15795] New: Strange bug / incorrect code generation with SSE ma1flfs at bath dot ac dot uk
` (6 preceding siblings ...)
2004-06-04 13:42 ` bangerth at dealii dot org
@ 2004-06-05 14:28 ` ma1flfs at bath dot ac dot uk
2004-06-08 15:56 ` bangerth at dealii dot org
` (16 subsequent siblings)
24 siblings, 0 replies; 33+ messages in thread
From: ma1flfs at bath dot ac dot uk @ 2004-06-05 14:28 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From ma1flfs at bath dot ac dot uk 2004-06-05 14:28 -------
I have submitted a glibc bug report for this.
http://sources.redhat.com/bugzilla/show_bug.cgi?id=206
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug c++/15795] No way to teach operator new anything about alignment requirements
2004-06-03 14:36 [Bug c++/15795] New: Strange bug / incorrect code generation with SSE ma1flfs at bath dot ac dot uk
` (5 preceding siblings ...)
2004-06-04 11:29 ` nathan at gcc dot gnu dot org
@ 2004-06-04 13:42 ` bangerth at dealii dot org
2004-06-05 14:28 ` ma1flfs at bath dot ac dot uk
` (17 subsequent siblings)
24 siblings, 0 replies; 33+ messages in thread
From: bangerth at dealii dot org @ 2004-06-04 13:42 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From bangerth at dealii dot org 2004-06-04 13:42 -------
As for a workaround: you can of course overload operator new, and do
a trick like
struct Align16 {} align16;
// overload operator new to take an argument of type Align16
__m128 *p = new(align16) __m128;
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug c++/15795] No way to teach operator new anything about alignment requirements
2004-06-03 14:36 [Bug c++/15795] New: Strange bug / incorrect code generation with SSE ma1flfs at bath dot ac dot uk
` (4 preceding siblings ...)
2004-06-04 9:34 ` ma1flfs at bath dot ac dot uk
@ 2004-06-04 11:29 ` nathan at gcc dot gnu dot org
2004-06-04 13:42 ` bangerth at dealii dot org
` (18 subsequent siblings)
24 siblings, 0 replies; 33+ messages in thread
From: nathan at gcc dot gnu dot org @ 2004-06-04 11:29 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From nathan at gcc dot gnu dot org 2004-06-04 11:29 -------
Florian, malloc is supposed to know what the strictest alignment requirement is,
and DTRT whatever (after all, we use it for 'new int' which, on many systems,
must also be aligned). This is not a gcc bug, but a system library bug. It is
not sensible for GCC to go down the path of checking that each and every
syslib call conforms to the appropriate std.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug c++/15795] No way to teach operator new anything about alignment requirements
2004-06-03 14:36 [Bug c++/15795] New: Strange bug / incorrect code generation with SSE ma1flfs at bath dot ac dot uk
` (3 preceding siblings ...)
2004-06-04 0:15 ` bangerth at dealii dot org
@ 2004-06-04 9:34 ` ma1flfs at bath dot ac dot uk
2004-06-04 11:29 ` nathan at gcc dot gnu dot org
` (19 subsequent siblings)
24 siblings, 0 replies; 33+ messages in thread
From: ma1flfs at bath dot ac dot uk @ 2004-06-04 9:34 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From ma1flfs at bath dot ac dot uk 2004-06-04 09:33 -------
Disclaimer: I don't know that much about gcc, but I have some ideas anyway.
As far as I can see there are two issues:
Issue 1)
__m128 *foo = new __m128;
I don't think there is any excuse for this, it's just plain wrong that it
doesn't work. __m128 is an intrinsic gcc is supposed to support. One thing
about this intrinsic is that it's 128 bits long, the other, equally important
is that it is aligned to a 16 byte boundary.
If using malloc() to allocate that *foo, I would kindof expect failure, as
malloc returns void* and thus does not know anything about what it allocates.
however, new is a c++ keyword, i.e. part of c++. It should know what the hell
it is allocating.
In this case we ask it to allocate an object of type __m128. It DOES NOT
allocate an object of type __m128. It just allocates something that is long
enough.
Issue 2)
class {
float a;
__m128 b;
} Foo;
This is not that hard either, as sizeof(Foo) = 32. It already works if
you allocate Foo on the stack. But the same problem as above remains.
If you don't want to "fix" new, how about a C++ extension, so that you can tell
new how to allocate objects...?
Or failing that, emit a warning, telling the confused user about this IMHO
weird behavior.
Cheers,
Florian
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug c++/15795] No way to teach operator new anything about alignment requirements
2004-06-03 14:36 [Bug c++/15795] New: Strange bug / incorrect code generation with SSE ma1flfs at bath dot ac dot uk
` (2 preceding siblings ...)
2004-06-03 23:02 ` jason at gcc dot gnu dot org
@ 2004-06-04 0:15 ` bangerth at dealii dot org
2004-06-04 9:34 ` ma1flfs at bath dot ac dot uk
` (20 subsequent siblings)
24 siblings, 0 replies; 33+ messages in thread
From: bangerth at dealii dot org @ 2004-06-04 0:15 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From bangerth at dealii dot org 2004-06-04 00:15 -------
Then someone definitely has to go bug the glibc people.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug c++/15795] No way to teach operator new anything about alignment requirements
2004-06-03 14:36 [Bug c++/15795] New: Strange bug / incorrect code generation with SSE ma1flfs at bath dot ac dot uk
2004-06-03 17:39 ` [Bug c++/15795] No way to teach operator new anything about alignment requirements bangerth at dealii dot org
2004-06-03 22:40 ` pinskia at gcc dot gnu dot org
@ 2004-06-03 23:02 ` jason at gcc dot gnu dot org
2004-06-04 0:15 ` bangerth at dealii dot org
` (21 subsequent siblings)
24 siblings, 0 replies; 33+ messages in thread
From: jason at gcc dot gnu dot org @ 2004-06-03 23:02 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From jason at gcc dot gnu dot org 2004-06-03 23:01 -------
Yes, the bug is in malloc.
>From C99 7.20.3, talking about malloc/realloc:
The pointer returned if the allocation succeeds is 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
(until the space is explicitly deallocated).
The rule for operator new is identical. In this case, the pointer returned by
malloc, and thence by operator new, is not suitably aligned for a vector, so the
program segfaults.
--
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |WONTFIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug c++/15795] No way to teach operator new anything about alignment requirements
2004-06-03 14:36 [Bug c++/15795] New: Strange bug / incorrect code generation with SSE ma1flfs at bath dot ac dot uk
2004-06-03 17:39 ` [Bug c++/15795] No way to teach operator new anything about alignment requirements bangerth at dealii dot org
@ 2004-06-03 22:40 ` pinskia at gcc dot gnu dot org
2004-06-03 23:02 ` jason at gcc dot gnu dot org
` (22 subsequent siblings)
24 siblings, 0 replies; 33+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-06-03 22:40 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pinskia at gcc dot gnu dot org 2004-06-03 22:39 -------
Isn't the agruments of new defined by the ABI?
If that is true then I still think this is an invalid bug.
--
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795
^ permalink raw reply [flat|nested] 33+ messages in thread
* [Bug c++/15795] No way to teach operator new anything about alignment requirements
2004-06-03 14:36 [Bug c++/15795] New: Strange bug / incorrect code generation with SSE ma1flfs at bath dot ac dot uk
@ 2004-06-03 17:39 ` bangerth at dealii dot org
2004-06-03 22:40 ` pinskia at gcc dot gnu dot org
` (23 subsequent siblings)
24 siblings, 0 replies; 33+ messages in thread
From: bangerth at dealii dot org @ 2004-06-03 17:39 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From bangerth at dealii dot org 2004-06-03 17:39 -------
Oh, I should have said that indeed on my system, the memory location
is 8-byte aligned, not 16-byte aligned. If I do make it 16-byte
aligned, for example with a hack like this
char *p = new char[10000];
__m128 * foo = (__m128*)(((int)(p+16))/16*16);
(for which I have no idea whether it is in accordance with aliasing rules),
then the program correctly succeeds. Nevertheless, I believe that gcc
should have some way of transmitting alignment requirements when it allocated
memory.
W.
--
What |Removed |Added
----------------------------------------------------------------------------
Summary|Strange bug / incorrect code|No way to teach operator new
|generation with SSE |anything about alignment
| |requirements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795
^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2021-10-30 10:39 UTC | newest]
Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <bug-15795-4@http.gcc.gnu.org/bugzilla/>
2021-10-29 1:01 ` [Bug c++/15795] No way to teach operator new anything about alignment requirements pinskia at gcc dot gnu.org
2021-10-30 10:39 ` redi at gcc dot gnu.org
[not found] <bug-15795-6844@http.gcc.gnu.org/bugzilla/>
2006-10-10 4:54 ` mrs at apple dot com
2006-11-12 15:33 ` timday at bottlenose dot demon dot co dot uk
2008-11-10 22:35 ` pinskia at gcc dot gnu dot org
2008-11-11 6:25 ` David dot Monniaux at imag dot fr
2008-11-20 16:45 ` hjl dot tools at gmail dot com
2008-12-09 17:56 ` rguenth at gcc dot gnu dot org
2004-06-03 14:36 [Bug c++/15795] New: Strange bug / incorrect code generation with SSE ma1flfs at bath dot ac dot uk
2004-06-03 17:39 ` [Bug c++/15795] No way to teach operator new anything about alignment requirements bangerth at dealii dot org
2004-06-03 22:40 ` pinskia at gcc dot gnu dot org
2004-06-03 23:02 ` jason at gcc dot gnu dot org
2004-06-04 0:15 ` bangerth at dealii dot org
2004-06-04 9:34 ` ma1flfs at bath dot ac dot uk
2004-06-04 11:29 ` nathan at gcc dot gnu dot org
2004-06-04 13:42 ` bangerth at dealii dot org
2004-06-05 14:28 ` ma1flfs at bath dot ac dot uk
2004-06-08 15:56 ` bangerth at dealii dot org
2004-06-08 16:43 ` nathan at gcc dot gnu dot org
2004-06-08 17:43 ` bangerth at dealii dot org
2004-06-08 18:04 ` jason at gcc dot gnu dot org
2004-06-08 18:05 ` jason at redhat dot com
2004-06-08 18:39 ` jason at redhat dot com
2004-06-08 18:45 ` ma1flfs at bath dot ac dot uk
2004-06-08 19:04 ` jason at redhat dot com
2004-06-08 19:25 ` bangerth at dealii dot org
2004-06-08 19:27 ` ma1flfs at bath dot ac dot uk
2004-06-08 20:04 ` jason at redhat dot com
2004-06-08 20:06 ` jason at redhat dot com
2004-06-08 20:26 ` ma1flfs at bath dot ac dot uk
2004-06-08 20:34 ` jakub at gcc dot gnu dot org
2004-06-08 20:45 ` bangerth at dealii dot org
2004-07-15 4:33 ` pinskia at gcc dot gnu dot org
2005-01-13 23:21 ` pinskia at gcc dot gnu dot org
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).