Remove the paragraph about writing to the Free Software Foundation's
mailing address. The FSF has changed addresses in the past, and may do
so again. In 2021 this is not useful, let's rather have a bit less
boilerplate at the start of source files.
Change-Id: I8ba71ab9ccde4ba25151ecbeb2a323f706b57d43
This patch fixes MS failing to even see the network, and only RACHs of 1
zeroed byte being seen in GSMTAP.
The issue seems to only appear on some specific machines; others have
been running fine for weeks without this memset being an issue.
Fixes: 7a52e42ee0
Change-Id: I98ad885a5d71e7775973a4d881c0f1cd665ea711
There is no point in checking basic stuff ten thousand times per second
since the sizes never change, so it's enough to enable the
checks/assertions for unoptimized (debug) builds.
This significantly decreases branch mispredictions.
Change-Id: Iebd9e91b3c7f37f2dc646d3017c45139977e4d15
- Those are not used any where
- Those are not supported by the sse/neon accelerated versions
- And I see very little use cases for those.
Change-Id: Ic850269a0ed5d98c0ea68980afd31016ed555b48
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Original issue: In order to use SSE instructions, 16-byte aligned memory
chunks are needed, and C++ version < C++11 doesn't provide for a native
new/delete store. For that reason, memalign() must be used in the
implementation of convolve_h_alloc() for some buffers.
On the other side, The C++ code relies on C++ "new T[]" operator to
allocate a chunk of memory containing an array of class instances. As
classes are complex types, they cannot be allocated through C structures
(calling malloc). Experimentally can be seen too that it's unreliable
and the process will crash during startup if malloc() is used and then a
Complex<> deferred from it.
Previous implementation allowed for use of convolve_h_alloc or new[]
based on how the (signal)Vector is called, because then the buffer is
not going to be managed internally. But that's unreliable since resize()
calling resize() on it could use "delete" operator on a malloc'ed
buffer, and end up having a new new[] allocated buffer. It was also
found that some of the callers were actually leaking memory through ASan (because the
buffer is not managed by the Vector instance).
IMHO best option would be to rewrite all this code using C structures
and malloc/free exclusively, since it would make all this cod eeasier to
maintain.
But for now, let's extend the Vector class to allow specifying an
external alloc/free function and let the Vector instance take care of
the ownership of the buffer in all scenarios.
Change-Id: Ie484a4762a7f77fe1b105188ea03a6f025730b82
Take the chance to update some includes using files available in that
subdir to have them ina more uniform way.
Change-Id: Ibda3c54fd4dc3f6b845cc373f1a1e6b758c1ea82
Oliver Smith
Pau Espin
Eric Wild
Martin Hauke
Sylvain Munaut